Posts Tagged ‘stratégie’

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.

screenshot001

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.

The decal system

A World without UI

Let’s imagine a RTS game where you’d play without an HUD, or even without a proper UI, just by clicking around with your mouse and learning by heart dozens of shortcuts. Pretty annoying, right ? You couldn’t tell how healthy is your army, assuming that you managed to create it, without a hint of which building is selected, and no construction menu. Think about all the stuffs you would miss.

That’s right, efficiently printing information on the screen is one of the main challenges in making a strategy game, and precisely the point I am actively working on. But let’s start with the beginning, before taking a look at what will come for you in the next releases. A lot of UI elements are already implemented in the game, like the tracking of the actions you programmed, by printing little circles on the floor, but how does it work ?

The decal system

Well those little indicators are called decals, and are wildly used in the large variety of games, from heraldry on a knight’s armor to a GPS arrow on the floor. The technique is inspired by real-life decalcomania, which is basically the art of printing a 2D image on a 3D surface, by pressing it and copying it on a support. What we want to do here is exactly the same, applying a texture on the terrain, but we have to do this in the most efficient way possible, since there can be a lot of decals, and they are refreshed every frame. (hint : we use the GPU for that).

Giving the example of the selection decal, let’s take a look at what we have to work with :

→ A texture of the pattern we want to print: cercle

→ The depth-map, giving the height of the terrain for every pixel on the screen: depthmap

→ The position where we want our decal to be, and the color we want it to have

Life is like a box of pixels

Now we are only a few steps away from the best UI ever.

First, we create a box around the given position, large enough to contain the full decal. To make this simple, we give it the maximum height of the terrain, and the size of our texture. This aims to reduce the number of pixels the shader will compute, since everything outside the box will simply get discarded.

Then, the challenge is to detect which part of the box is intersecting with the terrain, to know where to apply the texture. We do this by casting rays from the camera (in blue in the drawing) to every pixel of the box visible by the camera. There are three possible results:

  1. the ray enters and gets out of the box, intersecting the terrain after the box (top ray)
  2. the ray enters and doesn’t get out, intersecting the terrain (mid ray)
  3. the ray doesn’t even enter the box, intersecting the terrain before the box (bottom ray)

boite

Thanks to the depth map, we get the surface we want by the rays in the second case, and we can get the corresponding texture coordinates by projection.

However, the technique is not perfect, and we still compute a lot of pixels for nothing. The box is almost always way too big since we take the maximum height of the terrain. Actually, we consider a box, independently of the shape of the decals, which brings us to draw a lot of useless pixels. In the case of the selection decal, only the circle is used, so 80 % of the texture is transparent. With small decals it is not a problem, since drawing a small number of superfluous points has no impact on the performance, but when it comes to very large shape, such as printing the range of an artillery for example, we have to think another way.

An other problem is that the decal is relying on an input texture that is static. But we could need something computed dynamically from the game state, like an influence zone drawn by the whole army.

So yes, there are a lot of complications ahead, but don’t worry, you will hear from all of this very soon, in a future article.

Kranchy

A new website appears

Logo_WinThatWar

This week, we’ll just make do with a small announcement.
No big technology related blathering nor plenty of beautiful pictures today, but we promise to get back to that very soon.

Win That War! website grand opening!

Nope..today, we announce you that WinThatWar! website is now online. Universe, Roadmap, Team…some pages will need to be reworked later, so we could provide you more details about the game’s background little by little.

support devblog

Meanwhile, we hide a little surprise for you on the website. That’s not so much complicated to find, so you don’t need to train your 6th sense before visiting winthatwar.net !

Have a nice weekend, under the sun or in front of your computer, as you prefer.

About RTS engine determinism

Hi everyone!

This week I’ll write about a topic which may seems a little bit austere, but truth is that it can easily become quite fun: testing

How to test a game?

When we talk about test, it may refer to several things. In the case of WinThatWar!, we distinguish three test levels:

  • unit test
  • integration test
  • test in real conditions

Test in real conditions

Let’s start with the last one, it’s the simplest: the best way to test a game is obviously to play it. It allows you (and me also) to find out unexpected issues, not only bugs, but problem of use as well (ergonomy, feeling, gameplay possibilities…)
When you’re coding a game, you can’t stop telling yourself that you really need to improve it and you forget to play it “seriously”. That’s why, at Insane Unity, we schedule regular test sessions of WTW, that we intensified when the release is about to come out.

The problem is, after a while, we know the game really well, we play the same way again and again by force of habit, and because of that we’re becoming unable to hit the broad side of a barn. That’s why we are constantly looking for new users. Newbies allow us to easily find out ergonomy issues and to make a game which will really be easy to play. Talented RTS gamers allow us to estimate how hard to master is the game, and they bring out balancing issues and the efficiency level of the interface.

Once again, I take this opportunity to thank you all, all the alpha-testers. If you weren’t there to help us improving the game, WinThatWar! would be of a much lower quality than it is today. That’s your game too!

IMG_20150523_121101

 

Unit test

Unit test responds to a very simple problem: not to go round and round in circles everytime you’re coding something, undoing what was already working.

Before comitting any change in the code, the developer have to execute tests that will check if every module’s basic fonctionnalities work well. For example, some path-finding tests check that two groups of units can cross without striking each other, some others exist to check that our maths library’s convertion functions produce the expected result, etc.

Generally speaking, a unit test is written BEFORE coding the function it will satisfy. It’s called TDD.  This is one of the fundamental practices of agile development. Unit tests are very useful to “re-factorize” the code, in other words to deeply overhaul it without changing its functionality, in order to get it ready for the add of a new feature, or to make it simpler and less subject to bugs.

If a dev ever commit a change that “broke” one of these tests (called regression), he received an e-mail from our buddy Tim (that’s the name of our integration server) that gently insults him, and keeps doing so as long as the problem isn’t solved.

 

Integration test

Finally, the integration test takes place between the two other kind of tests I just wrote about. While unit test limits itself to test a module, integration test consists, as the name suggests, on making all the modules working together.

At Insane Unity, that means make 4 AI playing in 2vs.2 every night. Here again, Tim is in charge. Forward, we’ll check that we meet the expected balancing (for example, that AI lvl 5 always beat AI lvl3 in less that 10min.) But, for now, we’re using these tests for two things:

  • check there is no crash during the game
  • make sure our simulation is desterminist

 

RTS engine determinism

Determinism, WTH is that? Once again IT engineer gibberish…actullay a program is called determinist if it provides the same result every time it’s launch with the same starting conditions. It may sounds a bit “dumb”, but that’s not that simple. When you launch a program twice in a row on a modern computer, that’s never exactly the same starting state. So, if you ask your computer to do several things at the same time, it can choses, on its own, to launch the tasks in a different order every single time.

So what? Is that really a serious problem? Yes! When two players launch a RTS game, the world state isn’t sent by the network: it would take too long. Instead, we just send every player’s commands. Starting with exactly the same initial situation, and if we apply the exact same order, at the very same time, every players actions, we manage to keep exactly the same state, the same “reality” on every device.
But here it is, if one of the computer choses to execute the operations in a different order, the reality of every player will start to split, and that where the troubles start.

The first  versions of WinThatWar! were massively using parallelism to take part of the molticore modern processors. We quickly realised theses kinds of optimizations didn’t get on well with the network mode of the game. If you want to explore further, you can read this excellent article about Age Of Empire.

So, from now on, everytime we use multithreading, we have to make sure the operations order have no impact on the final result. And how to be really sure about that? Of course, we asking Tim for help! I told you that Tim plays WinThatWar! every night, at a rate of ten per night. That’s not all: it plays every game twice in a row, starting from the same seed and checking that every step of the world simulation is exactly in the same situation during both of the two games.

From now on, if you test a LAN pre-version of WinThatWar! with some of your mates, and if you suffer a crash, be curious and go get the log.txt file to watch it’s written on it. Now, you should know what that “Simulation out of sync!” message means. 😉

Etham

Terrain rendering part 1: procedural generation

LibNoise, my dear LibNoise

The game will use a huge amount of terrain, something like 1/40000 of the Earth surface. Surprisingly, Tim has politely refused to model all the landscape by hand… By chance, I’ve used the very powerful libNoise library for another project in the past. After a few googlings, I found an excellent port of libNoise for XNA, called libNoise.XNA that totally fits my purposes for now. The 2 screenshots illustrate the magical world of coherent noise generators.

Voronoï noise generator

Ridged multifractal noise generator

Later, we will combine multiple noise generators and operators to generate, on demand, the game landscape. The more observant among you surely have noticed the teapot and the various displayed helpers… A good graphical project never starts without a teapot, so while I’m waiting for Tim to complete the player model, I use a teapot instead. I use the helpers to debug collision engine, but that is another story…

Welcome

Welcome to the blog of Insane Unity!

We are glad to open this website to show you our first steps towards real-life game development!  As you may know, Insane Unity is working on a MMO-RTS called Win That War!. But at the beginning of this blog we were still working on our first game project, so yeah, this post was MODIFIED (we’re not even ashamed! ).

So. We intend to use this blog to promote this game (Win That War!, remember this name) and, most of all, to explain how we did it. We wish you a lot of fun reading this!

The Insane Unity team.

Return top