Posts Tagged ‘unités’

Unit balancing methodology

Game Designer saying: “when someone tells you that there is a problem in your design, 90% of the time he’s right. When he points out what you need to change to fix it, 90% of the time he’s wrong.”

In this first blog post about Game Design, we have chosen to focus on units balancing, a fundamental condition in real-time strategy game viability.
Balancing requires to identify with precision the cause and solution to a problem detected during a test session. Keep in mind that neither the cause nor the solution to a given problem are obvious, and the important thing is to always keep an overall view of the balance of the game when making an adjustment.

In order not to bring a disaster and make the game unplayable for a time, it’s important to keep some essential points in mind. Of course, since the following examples are directly taken from Win That War!, you’ll have to make some adjustments.

logo win that war

Balancing rules

  1. Always read the specs (specifications) of the units that are directly or indirectly related to a change. Remember the role of this unit in the strategic and economic balance of the game.
  2. There is always two sides to a deficiency or an excess in a stat (a parameter). Either the stats of this unit is too high, or the stat (of this unit or its opposite) which counterbalances it is too low. It’s essential to consider which side of the issue needs to be improved, all the while preserving the original intent of the gameplay dynamic and, above all, minimizing the imbalance caused on the game economy. Most of the time, this means picking the solution that would have the least possible impact on the rest of the system.
  3. Preserving the rewarding aspect of the use of an unit: its specificity, its imbalance in some particular situations (regulated and counterbalanced by other local imbalances in the other units’ stats and mechanics), its role in the economy and the possible strategy of a player, or rather the possible strategies.
  4. Finally, keeping an eye on the possible upcoming upgrades that would affect this unit: don’t nullify or OP-ify (Over-Power-ify. Don’t make it too strong) an upgrade when you affect a stat that might be subject to possible improvements for one of the factions. Some units are bound to be much more useful in a build of a particular faction. This is normal and advisable.


Case study – Units balancing in a RTS

Example: We find out that Bombers are way too weak compared to the AirKnocker, which devalues the use of surprise air-ground tactics and late game air-rush.


The question is: how to make this unit less efficient in this specific case, without going against the concept of use of this very unit, or any other one?

Here are some of the possible choices, as well as their impact on the game:

  • Changes such as improving the attack stats of the Bomber against the armor of the AirKnocker, making the Bomber harder to target or increasing the range of its bombs seem to be the best options at first sight, but would have a destabilizing impact on all air-ground fighting situations. These three options are then excluded.
  • Nerfing (reducing) the armor of the AirKnocker makes it more vulnerable to all ground units, which would be very frustrating since this unit is quite expensive and takes time to be produced. Moreover, this change would only take effect when the attacking player has a compo allowing him to reach AirKnockers through more powerful lines of units, which is the usual function of this unit. This means that the effective impact on the problem will be lower than the imbalance felt by the player as he watches his units get destroyed in one shot. That’s not a good idea, so this option is also excluded.
  • Increasing the price of the AirKnocker (as well as its required production time) to justify its power by its cost would make it a powerful and high-value unit to the player, which counterbalances its light armor and its visual appearance. Moreover, being the only anti-air specialized unit, it needs to be accessible, as beginner players would otherwise feel helpless when faced with air tactics. Well, we’ll exclude this one too.
  • Reducing the range or the fighting stats of the AirKnocker could be the solution, while keeping in mind the preservation of its specific role, its tactical viability and its difference compared with the use of anti-air turrets. A small change in several stats can subtly remove the problem by giving the unit a slightly awkward feeling. A medium or low cost unit shouldn’t have an “ace”, capable of anything kind of feeling, and making it less reactive while preserving its specialty is a very good option.


In most cases, (after a number of iterations), the existing balance of the stats of a given unit is correct and matches its role, and simultaneously scaling several stats by a small factor is enough to fix a defect or an excess of power.
As a general tip: Do not cancel what makes the unit special and fun, but rather work on related factors that reinforce its strengths and weaknesses while remaining consistent. Eg. making it easier or harder to use a feature.

In the case of the AirKnocker, the range, the acceleration and the tracking speed were the three main factors we had to tweak to solve its relation problem with the Bomber, while maintaining the overall balance.

Since we don’t want you to get bored with Game Design, we’ll keep the topic of economic balance for another blog post.

Stand Up! #1

As we were spring cleaning the blog, we’ve decided to bring a few changes and to create new article categories so that we could write more often about various topics related to WinThatWar! and Insane Unity.

This article is kind of a crash test.

As you may know, we’re working using the SCRUM method, which consists in dividing the tasks into “sprints” that we chose to last two weeks to help us we can redefine the priorities as we go along.

Actually, if you’re a SCRUM’s enlightened, you know that it mostly consists in a gigantic white board covered with dozens of sticky notes and a “stand-up meeting” every morning to let everybody in the team know which task is completed or in progress. In our case, every two weeks, we take stock and build a new release of WinThatWar! so we can all test the new features.

From now on, we will be able to write this kind of articles and update you in (almost) real time.


We know that it’s really frustrating to have to suddenly leave a game for any reason. So we figured we could create the save/load system and it is now perfectly functional, but on solo mode only.

We’re currently setting up the planetary view. Well, for now, it’s still a prototype. A few days ago it was just a spherical skeleton drawn by some neon green laser on Doom’s computer, who may explain how he did it in an article further ahead. By then, we should reveal quite a few enhancements right after the next “sprint”.

vue planétaire


A brand new building will soon appear in the game: the relay antenna. What is this thing? Well, as the name suggests, it will be used to relay the “network” on a given zone. Without this wonderful invention, you’ll be able to build factories, but you won’t be able to switch it on which could be an issue, right? I only can suggest to do your best to protect your antennas.


As you know (or you will know by reading this article), we’ll be present at the London EGX Rezzed on 7-8-9 April. We already have published the poster and here is the flyer! Hope you’ll like it as much as we do.

flyer winthatwar

Regarding the artistic production for the game itself, no less than a dozen units and buildings have been designed the last couple months (left to right: buggy, tank, diplomat).


By the way, we’re working on the buggy’s 3D model and you’ll soon be able to create herds of them. They go just so fast!


Sound design isn’t outdone neither. We found a band, that’s now working with us on WinThatWar! original soundtrack, and we’re really excited about it. Plus, most of the sound effects have been reworked and the ambience sounds have been enriched, especially the “Space Ship” theme which, if you wear headphones, gives you more and more the feeling that you actually are in a cock-pit, guiding your robots armies.

To finish this article, remember that if you’re in London the next couple of days, we’ll be present at the EGX Rezzed where you could play a short demo or ask anything you want about the game to Etham and Perik! See you there (in the “Indie Room” area).


Procedural generation & P2P

Network, network aaaand network… yeah, I’m working on multi over Internet mod for some months now. But here it is, today I decided to take a rest and write a post about the backstage, for you!


RTS & Lock-stepping

In a multiplayer game, we use the network to synchronize the world’s state on all the computers. Every player has then the same representation of the map than the others. Following the example of all known RTS,  WinThatWar! network layer is based on an algorithm called lock-stepping.

The classical approach (in FPS for instance), is to synchronize the internal representation of every items of the game by relaying, via the network, the changes bring to the other players. In a RTS, we can get to hundreds, even thousands of items to synchronize at the same time. So, you would probably understand that’s not possible to send, 5 time a second, the exact location of every unit of the map to every player in the game. However, even the most frenzied korean Starcrafter doesn’t exceed more than 5 commands by second, so that’s 300 APM (actions per minute)… Ok that’s not so bad.

To simplify, the lock-stepping will “cut” the game in 200ms turns. During that turn, we’ll record all the controls of the player: selection, moving orders, attack orders… At the end of the turn, theses controls will be send to all the other players while you’re waiting for their own. After a period of time, all the players finally get the list of  all the controls for this turn. This list is delivered to the game-logic (AI, Gfx, etc.) that will execute them (the controls). Then, the next turn begins. If the game-logic is determinist, which means it will always get to the same result for a given list of controls, the World state is exactly the same for every player. It’s called “Synchronous simulations”.

In facts, that’s a bit more complicated: we mask the network latency by simulating a n -1 turn, so we give time to the next turn controls to arrive before the end of the current turn simulation. Are you still following me? Anyway, in the case of games over Internet, we just make sure that these turns length of time vary depending on the players’ computers and network capacities.

This paper, wrote by Age of Empires creators, describe this principle very well.

At the end, the network part is quite simple. The true difficulty resides in the game-logic determinism. For a given list of controls, all the computers have to end in the exact same result.

Procedural generator & GPU

In the case of WTW, we chose to use procedural generation to produce our maps. We’ve actually got a tool that allows us to define varied maps styles, then our generator is able to create an infinity of variants of them. Well, we have to confess that’s still a bit experimental now, but we’re working on it!

For the sake of performance, the maps relief (heightmap) is generated by the graphics card with the help of Pixel Shader, at the very beginning of the match. That’s quick, and efficient.

Problem is there’s still some negligible differences between what results of two graphics cards made by a different constructor or so. Usually, it really is a tiny variation, in the range of 10e -5 or 10e -6 maybe (0,00.001 and 0,000.001 if you prefer). But here it is, that causes troubles in the synchronous simulations. For example, at Player 1’s, a tank could perfectly shoot the target, but at Player 2’s, the tank seems a bit upper on the map, and it can’t shoot. In short, that’s not synchronous anymore. And we do not like it this way.

P2P transfer & ECC

I the way to fix this problem, in LAN mode, the host was sending his own heightmap to all the player. This way, we ensured there was no display difference. But we can’t use this method  concerning the multiplayer over Internet mode. Our largest maps heightmaps is around 400Ko heavy. In the case of a 8 players game, the host would have to transfer 7x400Ko of data, knowing our Network technology is P2P based, and if, like me, you didn’t have choice and subscribed to an ADSL which don’t allow you to upload more than 100ko/s… it would take you 28 seconds just to transfer the map. And we all now, here, how these seconds can seem lengthy when you wait a game to be launch.

So, this is roughly how it works at Insane Unity: If 8 players join the game, the map is “cut” in 8 parts, and every player send his own eighth to the 7 others. So one player will upload only 350Ko (7x50Ko), which means 3.5s sending time.

Actually, the map is “cut” to be as efficient as possible for the processor cache, but in any case, it doesn’t change anything of the 8 parts things, since every player will send more or less the same volume of data.


The heightmap in Yellow, the cutting in Red.

But wait for it… that’s not the best!

I think that ECC (Error Correction Codes) are one of the most magical thing of informatics. The principle is to use an abstruse mathematical process: For one data bloc, a “parity” bloc is reckoned. The whole (data + parity) is relayed, then through a second abstruse process, we can firstly check that none of the data are damaged, and then fix the potential errors. Reed-Solomon codes (RS) might be the most used: CD, DVD, Blu-Ray… it even works when it’s scratched. And, if as mine, your ADSL is a 2,5km long interferences antenna, I think you might be happy that your residential gateway or router fix some of the errors.


RS bloc coding, n = total weight, k = playload (useful data), and 2t = parity. Through a 2t parity, you can fix up to t errors.

Well, let’s get back to our map. The heightmaps are almost the same for all the players. So, I’m using the RS to calculate a parity bloc, and that’s what players are exchanging through the Network. Then everyone can apply the error correction, and that’s how all the players will finally can have a perfectly identical map. Oh yeah, I almost forgot, parity bloc is obviously smaller than data bloc but you probably noticed that already. In our case, it’s RS(223,255), being 32 octets parity and 223 octets of data. Let me do the calculation for you: Now, the players just have to upload  50Ko each thanks to this method, which means an half a second transfer.  And that’s what we like!

So, that’s my daily life at Insane Unity. Hope you enjoyed this post.


The blueprints system

“So you want our beautiful vehicles? You want to build and deploy them on still unknown and unexplored planets? Thanks to our Blueprints, you will be able to do all this.”
Wilmuth Trueman, CEO of Robotron Industry during the IWC (Interstellar War Conference)

Well that’s a quick recap but that’s the idea (But, in his defense, he had to do quick and catchy given the stakes of this conference). Don’t worry, we are going to explain you every little details you have to know about these much talked about blueprints.

But what is this blueprint thing?

Basically, blueprints are just plans which allow your factories to build the units you will have to deploy on the battlefield. On this precious piece of paper is written everything your factories will need to know: what they have to put where and which resources they’ll need to build it (It’s ok, you don’t have to care about it, your factories will do it by themselves).


But I rather warn you right now, at Robotron Industry they’re not really charitable. You will have to pay for your Blueprints, and let me tell you it will be expansive! In addition, these big industrialists have found the perfect trick for these blueprints, and to keep going richer and richer: They limited the number of uses! But fortunately for you, you will be able to buy contract extension for your favourites blueprint. Aren’t they sweet?

How will it be helpful to you? Oh really, you still don’t understand what is happening here? Well, don’t expect Robotron Industry to sell you anything else than the “basic” form of their precious blueprints at the beginning. Yes this means that you won’t have definitives versions of the blueprint when you buy it. You’ll be able to upgrade your vehicles but sadly you will have to pay even more if you want to have the more powerful units in the game. Yes: PAY, again and again! Son of a…of a defective rusty robots! Wait. It’s ok, isn’t it? You already knew we wouldn’t provide you plans to build mass destruction arms at the same price as a scout plan anyhow.

Don’t worry, Robotron industry have well planned all of this, the price of the upgrades you’ll add to your units will be scaled to their strength. And you can’t say that they don’t have a conscientiousness because if they sold you fully upgraded blueprints you won’t be able to construct the corresponding units anyway, because you would probably be lacking of needed resources. See? Eventually big industrialists are nice to you, they care about you, and your base (and your wallet of course).

Well let’s talk more about this famous upgrade system. So your basic units will be upgradables by two different ways: you can choose to specialize them in their primary role, or you can choose to add this unit another role which it is usually not able to fulfil.

Let’s imagine your tanks: You’re probably using them every day but you are a bit sceptical about their destruction abilities? You can transform them into really bulky ones with better armour-plating and bigger cannon in order to inflict more damages!

Or if you are more an adept of precision strike and fast attack, you could choose to upgrade to a tank that will be faster than ever, with a better radar range and with which you’ll be able to plan recognition.

Don’t forget Michel


Ah, I almost forgot! If it can make you feel better, you need to know that the Cartels you are working for will nicely provide you your first blueprints… well, not exactly. Actually, they will lend you some money so you can buy them (the blueprints, not the Cartels!). Which means that you have to think deeply on what you’re going to spend their money. Because let’s confess it would be awesome to have a laaarge amount of fighting units, but if you’ve got no engineer to build the factories which will be used to build your units, you won’t be able to build this army and we agree that would be a shame. So, please, choose wisely. Will you do that for me ?

Well, well, well. I think you know everything you have to know about these magnificent blueprints supplied by the marvellous Robotron Industry and I hope you will buy lots of them so you could crush your enemies and bring peace (’cause of course, you’re the good guy) into the whole galaxy and fortune to your Cartels.

Ah! And for the few sceptical in the back: No I don’t earn any from the sells of blueprints.

Hæternal (trainee @ Insane Unity)

Return top