Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 04 Dec 2011
Offline Last Active Private

#5268196 Smooth outcomes/incomes in the game

Posted by GaldorPunk on 28 December 2015 - 08:53 AM

Command and Conquer and Supreme Commander for example have a "streaming" or "pay as you go" resource system where you can add units to the production queue without currently having the money to complete them, and the game automatically spends the money over time as long as the player has some. It's also the system I'm using in my game, it's more complicated to implement but there are some advantages to using it. The basic idea is that, unlike games like Starcraft or Age of Empires, you don't have to wait until you have the full value of the unit to tell the game to start building it. So in that example, if a unit costs 30 resources you can tell the game to start building it whether you have 0 or 25 or whatever and it will start building over time as long as the player has money to spend, which means you'll never have to wait for the player resources to hit a certain amount before starting production.


This is the basic form of the equation I use in the production building's update loop:

resourcesSpent = (buildingQueue[0].initialCost) * (timeStep/ (buildingQueue[0].buildTime));

if(resourcesSpent > player.totalResources)
  if(player.totalResources < 0)
    resourcesSpent = 0;
    resourcesSpent = player.totalResources;

buildingQueue[0].remainingCost -= resourcesSpent;
player.totalResources -= resourcesSpent;


resourcesSpent = amount of money this production building spends on producing stuff this update loop

buildingQueue[] = a list of data on units to build

buildingQueue[0].initialCost = the total cost of the unit (e.g. 30)

timeStep = how long it's been since the last update loop (probably something like 1/60th of a second)

buildingQueue[0].buildTime = how long the unit would take to build if we didn't run out of resources during building (used along with initialCost to determine the rate at which resources are spent)

player.totalResources = how many resources the player currently has

buildingQueue[0].remainingCost = initially the same as to initialCost, when this reaches 0, the unit is completed and removed from the queue


There's more to it, like dealing with integer rounding, evenly distributing resources when there's a low amount and multiple production buildings, but the above code is the main part.

#5245619 Real Time Strategy mechanics

Posted by GaldorPunk on 10 August 2015 - 07:02 PM

I don’t think there’s anything necessarily wrong with generic as long as it’s well done and not a complete clone of an existing game. That faction upgrade system sounds like it’s enough to offer a unique experience and make your game stand out from others in the genre, and there’s plenty more you can do with small mechanical decisions to make your game feel different from existing games. Whatever the theme or gimmicks, I think the best strategy is to focus on the fundamentals and just make a really solid RTS game.


One problem I see with the second one is that it sounds too much like rock/paper/scissors, not in the sense of having a combat triangle of counters, but that by separating the production and battle phases, players will have to blindly choose a tech path and hope that they picked the right one to counter the other player, since they’d have much more limited opportunities to switch builds after seeing what the enemy is doing. It sounds like it’d run the risk of being too much of a simplification of the genre, and that could turn off the core RTS gamers who would otherwise be the main audience.

#5220323 [RTS] How to encourage base-building without the game taking too long?

Posted by GaldorPunk on 30 March 2015 - 05:32 PM

Some ideas:


Have an early defender’s advantage that diminishes as the game progresses. You could for example make powerful base defenses that are cost effective against early units, but are weak against upgraded or higher tier units like artillery and aircraft. Tech progression is often on a different timeframe compared to regular production, that way players can’t just spend more money to unlock tech faster. While each player is waiting for the offensively useful techs, they’ll want to spend their remaining money on base building and defensive units.


Tie the economy to base building. Normally, you have to expand to more vulnerable locations to increase your income, but you could make it so resources are mainly found near your original base and/or make it so that your initial base can be significantly upgraded (adding on new modules to your refineries or something, maybe even get income from the total “population” of your base) to increase your income. This would encourage building a single large base and make it harder to harass the other player’s economy early on, but you’d still have to have some change in pace later on (like superweapons or the higher tier offensive units above) to make sure both players eventually have an incentive to attack.

#5143372 Saving Mechanic in RPGs

Posted by GaldorPunk on 30 March 2014 - 10:25 PM

I think the save altars are a legitimate way of doing it, as long as they are reasonably common in all areas of the world. Even with the save altars or towns, you can still kind of use a system of save anywhere, just make it so that when you load the file you keep all items and experience you earned up until the time you last saved, but your character would physically respawn at the nearest altar/town (if you can teleport to the altars anyway, this shouldn’t be game changing.) That way the player could still save at any time without really losing character related progress other than maybe the current dungeon being reset, but saving couldn't be used to cheat through multi-stage challenges along the lines of a jumping puzzle, where failing on any one part of the challenge is meant to send the player back to the beginning.


Depending on how your game works, it might also be possible that you could solve the save/load abusing problem simply by allowing players to save only when they’ve been out of combat for a short time, or only once they've cleared the current room/dungeon if that's a concept that makes sense in your game.

#5139754 Waypoint system problem XNA

Posted by GaldorPunk on 17 March 2014 - 12:06 PM

Looks like you’ve got a divide by 0 error where you’re dividing Direction.X and Direction.Y by Length, check to make sure Length isn’t zero before you calculate and apply the movement vector.

#5131734 RTS unit balance. Armour types?

Posted by GaldorPunk on 16 February 2014 - 10:38 AM

That sounds good, those damage/armor types would add depth and a sense of realism to the game. You definitely want big tank shells to be better against armored units than machine guns, and generally have the game match up to real world expectations.


The next question is how much of an effect you want the armor types to have; that is, how hard or soft the counter system will be. Realism would probably dictate a very hard counter system, where small arms would do next to nothing against tanks, but I think that tends to lead to less interesting gameplay.


The way I see it, the strength of the counter system is going to influence the player’s priorities in the game. Harder counters reward scouting, tech choices, and correct unit composition, while softer counters leave more room for micro to decide battles. Many games have a mix of harder and softer counters, but the overall balance really depends on what kind of RTS you want to make.

#5111513 Everything is fogged...

Posted by GaldorPunk on 23 November 2013 - 08:04 PM

Increase theEnd by a lot. The fog is applied in different amounts to whatever is between the start and end distances, so whatever is closer to the camera than .5 distance has no fog, halfway (.75 away) would have half fog, and whatever is farther than 1 unit of distance from the camera is completely in covered in fog.

#5110062 Adding support for Xbox 360 Controller (PC) a legal issue?

Posted by GaldorPunk on 17 November 2013 - 07:09 PM

Microsoft does also grant some free images of the controller and the buttons that you can use for games.




#5072151 Action RPG WASD Controls

Posted by GaldorPunk on 22 June 2013 - 10:16 PM

Most MMORPGs use the WASD movement system with the number keys being the main action hotkeys (usually nearby keys like Q,E,R,T,F,G will be used for actions as well) and the mouse being used for aiming and targeting (and as an alternate steering method if you're holding down the right button.) It works well for those games, and there a lot of MMOs that have enough action in their combat systems that I would consider them to be "action" RPGs, for example: Guild Wars 2, Tera, Age of Conan, and DC Universe Online to name a few.

#5066577 Strategy Game - Unit Damage

Posted by GaldorPunk on 31 May 2013 - 08:08 PM

I have to wonder though, if the randomness is used such that you wouldn't notice it, is it really adding anything? Is doing a range of 20-26 damage much different from doing a flat 23 damage?


I think what I mean to say is that randomness can be something you notice on the short term, but over the full course of the game, it definitely shouldn’t be something that you can point to and say “I only lost because of bad luck.” Civilization for example is a game where randomness can play a big part in small battles, but since the games can last for many hours and include thousands of individual battles, the result should ultimately feel fair to the player.


I also think there’s ways that randomness itself can add to the experience, even without causing a noticeable amount of uncertainty. For example, in the game I’m making, all projectile weapons have a random targeting vector within a base accuracy range, which makes them less likely to hit units at max range or physically smaller units. (the counter system is largely based on accuracy, rate of fire, and unit size) The same effect could have been accomplished by simply decreasing a flat damage depending on the size or distance to the target, but with the random vectors you also get the emergent effect of discouraging clumped up units, since clumping tends to negate the penalty for low accuracy; even if it misses the intended target, a projectile will probably hit one of the units next to it.


The function of random damage itself, I think is mainly in either adding some uncertainty to the result of battles where none would otherwise exist (especially in a turn based game) or to get the player to pay closer attention to individual units in a slow paced tactical game. (e.g. the way you have to react to critical hits in an RPG with extra healing rather than simply saying something like “the boss does 50 dps and my potions heal 500 hp, so I’ll just click a healing pot once every 10 seconds.”)

#5065947 Strategy Game - Unit Damage

Posted by GaldorPunk on 29 May 2013 - 03:34 PM

I think it’s fine to have some amount of randomness as long as the player won’t feel like the random values are actually changing the outcome of the game. Ideally, your random calculations should have a low variance and a large sample size over the course of any battle, so they will average out to relatively constant values and the player won’t be able to blame a win/loss on high variation in the random damage. Generally, you don’t want the outcome of the game to come down to a small number of battles that are decided with a few rolls of unweighted dice where the result of the battle can very possibly be drastically different from the expected result.


There is also in my opinion a very different mindset in playing turn based games vs. playing real time games in that turn based games (Civilization, Risk, etc.) can get away with being a lot more reliant on random outcomes than real time strategy. In an RTS, the outcome of an evenly matched battle is primarily determined by who has the better micro, while in a turn based game, the concept of micro might not exist at the level of individual battles, so random damage can make the battle a little more interesting. The way most of these games are designed, they would be a lot less fun if the outcome of a battle was set in stone before it even began, so the random outcomes are essentially simulating the effect of micro between the two players. From a strategic perspective, this also essentially forces each player to overcommit to each engagement just as you would want to in a real time battle where the outcome is uncertain. You don’t want to go into a battle with a slightly larger army where you only have a 51% chance of victory, instead you would rather wait until you have a much larger army or better positioning, maybe with a 70% chance of winning.


I think random events can work as well, especially if there’s a chance for the player to respond to them. For example, if a unit trips and simply takes 2 points of damage that’s not too interesting, whereas if a unit trips and takes 2 extra turns to get up, that’s an opportunity for the player to make a new decision in how to mitigate or take advantage of the situation.

#5065404 Skill and experience

Posted by GaldorPunk on 27 May 2013 - 09:21 PM

I’ve been on a number of similarly sized amateur teams and the way I’ve usually done it is that the lead artist or programmer is primarily the one who sets the artistic or mechanical direction of the game and delegates specific tasks to other members of the team. Usually the most experienced and most skilled person is the lead, but this isn’t always the case. (That being said, unless someone clearly has much better leadership and management skills, it’s probably best to start out with the most skilled/experienced programmer or artist as the leader of their respective group.)


Even in a highly collaborative team, everyone is going to have a slightly different idea of how to do things, so the main responsibility of a leader is to decide on a single course and keep everyone else on track. The lead artist should have the greatest understanding of the overall art style of the game so he can make sure the other artists’ work fits together in the game, and the lead programmer should have the greatest understanding of the program’s architecture so he can coordinate other programmers working on smaller parts. This is also why it’s probably not a good idea to switch leaders in the middle of a project, except for extreme cases. If the new leader has a different idea for the art style or how the program should be structured, it can cause conflicts with all your previous work and really mess things up.

#5063129 Space race games.

Posted by GaldorPunk on 19 May 2013 - 08:39 PM

I’ve always liked the idea of using gravity to slingshot your ship and drift around planets without getting sucked in when it comes to space piloting games. Something like the Kessel Run from the Star Wars universe would be a really interesting course. (The idea is that the Kessel Run is a trade route that goes through a black hole cluster. The more cautious pilots go a long distance around to avoid getting sucked in, but if you’ve got a powerful ship and stick to the relatively safe paths, you can snake your way through the center, presumably shaving a lot of parsecs off the course length. The same could be done with any kind of course featuring planets, moons, or large asteroids.)


I also think that generally speaking, extremely realistic physics in terms of how the ship handles in outer space are often more frustrating than fun. It might be just me, but I like having some amount of "friction" to decelerate the ship when you're not running the engines and a steering system that isn't entirely based on side thrusters, just to make the handling easier and more like terrestrial racing games.

#5061055 What's the true worth of an initial game idea?

Posted by GaldorPunk on 11 May 2013 - 06:44 AM

Pretty much agree with a bunch of other replies, it isn't the initial big picture idea that's valuable, it's the thousands of small decisions that the designer makes during the course of development that determine how good the game is. The disdain for 'idea guys' in the indie community partially comes from the fact that with small teams you just can't afford to have one guy who only does design and can't program or make art. (Although I think the main reason is that most of the people who just say they want to design games don't really know what it takes to be a game designer and as a result aren't actually any good at it.)


Still, there's definitely a lot of value to having one or more person doing the work of a lead designer or art director. Sure, the initial concept isn't nearly as important or difficult to get right as the full implementation, but the overall direction and artistic vision of the game is important throughout the development process. It's a big advantage to have an interesting concept and a coherent vision of what the game is going to be, otherwise you run the risk of making a mismatch of conflicting ideas or churning out a technically proficient but generic and uninspired game.


Good idea + good implementation = good game

Bad idea + good implementation = playable but generic game

Good idea + bad implementation = wasted potential, "could have been good, but isn't"

Bad idea + bad implementation = worthless

#5048019 How should a Mini-Map work on infinite terrain?

Posted by GaldorPunk on 29 March 2013 - 10:06 AM

It seems there’s usually two different levels of detail in minimaps for games with really big worlds.


1) you can have a size limited minimap that’s in the corner of the screen or brought up as a semi-transparent overlay, which shows a relatively small area around the player’s current position. These could be created on the fly and should show dynamic data like other NPCs by just taking the chunks around the player, since the nearby terrain would presumably be loaded already. You’d probably want at least some amount of saved minimap data with the terrain data, either saving a minimap image that you can piece together for each chunk of terrain or at least saving the average color of each tile so you don’t have to recalculate it for every tile.


2) there is also often a “world map” which can be brought up fullscreen and pretty much prevents the player from moving or fighting while he’s looking at the map. (which wouldn't work if the terrain is procedural) The world maps pretty much have to be one or more pre-rendered images since they show data from the whole world – probably more data than you can pre-load in RAM. A lot of the time these are more stylized, as a 3D model like in Skyrim, or to look like worn parchment, e.g. http://www.the3rdage.net/item-111.