Posts Tagged ‘stratégies’

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.

Roadmap little changes

Hi people!

It’s been a long time I haven’t wrote anything on this blog. That’s why I take advantage of this post-return of summer holidays break to bring you some general news.

From movie the mummy found on tumblr

So! Insane Unity is doing well. Doom is still working on his network stack (which has quite progressed), and Philemon get back to a concept arts phase (which are also in a good way). Also… our two trainees abandoned us last week (sob).

Anyway, we’re still looking for financing and that takes a lot of time, but we’re doing our best to stick to our roadmap at the same time. And as you’ll see below, that was not as effective as we expected. Let’s see what we forecast for September:

  • HUD (tactical information)
  • Tutorial
  • Multiplayer over the Internet
  • Gameplay-guided music

Hum. Well, the HUD is functional, as you may already know if you receive our newsletter, but we’re waiting for Philemon to find a moment to draw some pretty strategy icons miniatures before we let you test it.

About the tutorial, we’re waiting to finish fixing every single interface issues. But, here is the point: Since I had loads of administrative tasks to handle these months, I barely made progress on the interface. Maybe I should buy a tie (just kidding). Even though, I found some times to work on the AI, and that’s the good news. Be patient, I’ll wrote a  post about that later.

Multiplayer over the Internet mode is working! Here is another good news, right? At least, one of us is doing his job, here: Doom. The connecting time between two players is just melting like an icecube on the top of an uranium battery, and the stack is getting stronger and  more and more efficient. Maybe Doom will also write a post about this in a couple weeks.

Last but not least, about the gameplay-guided music, we just have to integrate in the engine the loops CiD produced on Wwise.

I think I’ve nothing else to add. I just wanted to be honest with you and confess my mea culpa before sneakily going to modify the roadmap on WinThatWar! website.

Bye everyone, and thanks again for all your support.

Etham

the decal system part 2

You missed the part 1? Keep calm and click here.

Long distance decals

The problem with the artillery in the game is that you don’t have a clear idea of its possibilities. For example, you’d like to park it behind a mountain and target the enemy base, forcing him to bypass the relief and loose a precious time. However, since it is impossible to have the base and your artillery in the same screen, you cannot know how your artillery would react to such an order. In fact, if not at range, it will move right into the enemy base and be destroyed. The point is, when you start thinking strategically and not just a-clicking the enemy, you need critical information, such as the range of a unit.

Now technically, how should we do it ? We could make a decal from a texture, as we did with the selection circle, but that would be a really large area, mostly empty, so it may not be the best option. What we can do, is using the GPU to render vector art on the screen. I’ll explain it later, but if you want to know more about it you can check this chapter from GPU Gems 3 : http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html.

But, what is a vector art?

The most common way to consider an image on a computer is basically with a table of colours. When you create an image you have to define its size, which is the number of pixels it contains, and each one of these pixels will have a colour. So all you have to write in the file are the colours of the pixels in the right order, and the GPU will be able to print the image whenever you need it. However, this induces a small problem when it comes to scaling the image.

Picture yourself in a FPS, and in front of you is a brick wall. You are a few meters away from the wall, and can admire the beautiful brick texture the graphic designer created. However, as you get closer, this texture takes a bigger part of your screen, since it is larger, in pixels, than its original size. At this point the details of the texture are less accurate since the colour of a pixel is extended to 5 or 6 adjacent pixels. We could increase the size of the texture, but then the file would be two times bigger, and we want to avoid a heavy file that will take longer to load.


briques

The classic way to overcome this difficulty is vector art, used in the svg format that we need for large decals, such as ranges. The idea is to save a description of the image that doesn’t depend on its size in pixels. To do that we rather consider the curves that form the image, as “paths”. Each path is a command, a set of points, plus a colour and various options about fill, or stroke, or whatever you need, defined in the svg standard. But it will be easier with an example.

Please, draw me a triangle

Let’s make a simple triangle : all we have to do is draw three lines, with each end being the beginning of the next one. For instance,

M 0 0 L 0 100 L 100 0 Z.

This is what a path looks like, a set of letters that are commands to indicate a certain shape to draw. The numbers after it are the coordinates that describe this shape. M means “Move” the current point to this position. It represents the start of the shape, as if it was the position of a virtual mouse. Here we position this cursor in (0,0). L is the command for “Lineto”, that draws a line from the current point to the arguments. At this point we drew a line from (0,0) to (0,100) then from (0,100) to (100,0). Z is the command that closes the shape, by drawing a line to the start point. In this example the line joins (100,0) and (0,0).

triangle

We now have a triangle between the points (0,0), (0,100) and (100,0). We can add options like “fill: black” if we want to fill the shape in black, but basically that is how svg files work.

This way, we can always adapt the shape to how large our image appears on the screen, and then avoid the problem of resolution, but of course complex images can induce a lot of paths, so it is better to save it for something schematic, with only simple shapes.

Other commands (Q, C, A) are used to draw the Bezier curves that we will need for the large decals, and are a little more complex, as you will see in the next part. Yes, there will be a part 3! Wait for it.

STUNFEST 2015, a little more indies?

 

Back from the Stunfest

We missed you on that blog. Have you missed us?

As we told you on our social media or Newsletter, we knew that during the two past weeks we would be a bit busy getting ready for the Stunfest.

bannière stunfest

If you don’t know what Stunfest is, it’s THE video game festival in Brittany. 11 years ago, it was just about some fighting games holic meeting in a garage to share their passion. Now, more than 10.000 gamers and visitors are coming from the four corners of the World, and hundreds of players challenge themselves during fighting games tournaments. In 11 years, the Stunfest open itself to new vistas: musical games, retrogaming, concerts, conferences, speedruns and, of course, indie games!

Win That War, Stunfest, Insane Unity, RTS, strategy, Michel, video games, test, festival

Insane Unity team, after setting up.

That were you’d find us. Before we left the studio, we checked that everything was ok, no-one and nothing was missed, we turned off the computers and we were ready to set the stand up on thursday night. There is even more space than last year especially booked for indie devs. 35  indies were expected this year: that was a good opportunity for us to meet some familiar faces and to discover new games and new devs.

3 days of WinThatWar!

Friday morning, 9h30, the gates would be opened 30 minutes later. That was the right time to check one last time that everything was working the way we were expecting. We brought 2 computers, so the gamers could challenge their mates in 1vs1 game. The hosts also lent us a third computer that we used as a demo screen. Ok, we were ready. “Release the gamers!”

And that’s an awesome start for us: the first players came to our stand and started to test WinThatWar!, and some others, that already knew the game, were here to see how it’s progressing.

Win That War, Stunfest, Insane Unity, RTS, strategy, Michel, video games, test, festival Win That War, Stunfest, Insane Unity, RTS, strategy, Michel, video games, test, festival
Win That War, Stunfest, Insane Unity, RTS, strategy, Michel, video games, test, festival Win That War, Stunfest, Insane Unity, RTS, strategy, Michel, video games, test, festival

The most timid ones were getting in the fight against our AI level 1,  we had time to explain them the basics so they could play on their own after that. Some others came by with their buddies to challenge them, and finally the most audacious ones faced our AI lvl 5 to gave it a good beating. 5 of them survived, the others were brave…until the end.

In addition of beautiful meetings with gamers and indie devs, we also had the chance to discuss about our game’s concept and its evolutions to come with some other professionals from the amazing world of video games : columnists, editors, streamers and even Llewellys, big boss of Millenium, who was kind enough to come to our stand to meet us after we king of “grabbed” him on twitter. Oops!

Win That War, Stunfest, Insane Unity, RTS, strategy, Michel, video games, test, festival, llewelys, millenium

Llewellys with Etham, Insane Unity CEO

We sincerly thank all of those who have been testing our game during these 3 amazing days of Stunfest, thank you for all your supports, thank you for all your feedbacks, your ideas which will help us to improve WinThatWar! again and again. Your advices mean a lot to us.

Win That War, Stunfest, Insane Unity, RTS, strategy, Michel, video games, test, festival Win That War, Stunfest, Insane Unity, RTS, strategy, Michel, video games, test, festival Win That War, Stunfest, Insane Unity, RTS, strategy, Michel, video games, test, festival

It is no secret that this weekend was exhausting, but we’re already impatient and hope to be a part of the next edition, or to meet you on some other fairs/conventions. See you soon?

More pictures on Facebook.

Insane Unity team, still a bit jet-lagged.

Alpha 0.3 is available

Less conversation today, let’s go to the essential!
As you might already know, because you read this blog every week or you’re following us on our social medias, Win That War! evolved during the last monthes.
Air-units, generator, a new network stack, the pathfinding optimization… You have been flooded by illustrations and technical terms during weeks.

But finally, here it is! Win That War! Alpha 0.3 is now freely downloadable on IndieDb.

If you’ve got any issue downloading by this website, just let us know. We are currently waiting for some other download platforms to validate our game. So, we will send you the download link as soon as it will be available.

 

If you played Alpha 0.2, here is a quick overview of what was modified/is new (You can read the full version of this release note on our IndieDB  game’s page)

  • Some events added : under attack & destroyed units, resources shortage
  • Use middle click to open radial menu and enqueue mode for mimic and attack-position
  • Air and aniti-air units place holders have been added you can now use them. So can the AI, so be careful.
  • By the way, you can now choose between 5 difficulty levels when you’re playing against AI.
  • Tank-traps and artillery have also been integrated.
  • And about network, we switched to our new stack.

If you have any questions or suggestions concerning the game, please feel free to send us a message or write a comment, we’ll respond to each demand.

Have a nice weekend!

PS: In the case you can’t find the hidden links in this post, here is the Download link : ALPHA 0.3

Shortcuts

You wanted it, you dreamed of it.
Well, maybe you didn’t… Anyway we did dreamed that you could test WinThatWar! without being driven to despair, no matter if you are a RTS-holic or not.

That’s why we (most Kevin) concocted a little cheat sheet for you, so you could play Win That War! with total peace of mind.

FinalShortCut

Of course, some of these shortcuts may still undergo some changes in the coming months . But for now , you can refer to it to test the Alpha 0.3 which will be released in a few days .
Don’t hesitate to leave a comment to tell us what you think about these shortcuts. Is it ok for you? Or are some of them not suitable?

To be informed of future releases before anybody else, don’t forget to sign up here: Beta test program

Have a nice weekend.

Missing ingredient

Today, what about a cooking class ?
No, no, ok , we were just kidding.

A post about video games’ main ingredients sounds better to you? We’re not pretending that we know a magic solution, if so we would already had released Win That War! for good and sold 3 millions of copies in only 2 weeks…I guess.

Well, let’s see. What did we not mention yet and which could make an important difference when you spend a lot of time playing a game ? We already wrote about game-design, game-logic, gameplay (and all these words starting with “game”), game engine, 3D, biomes, pathfinding… So what is it about today ?

Any idea ?

Untitled design (1)

Of course :
Music and sound effects.

Two freelances musicians are working on these.  Cid is in charge of the sound environment of the game, inspired by the mid-21st century ‘s musics with a little touch of “pizzazz” to make it more modern. And Jean-Phi creates sound effects : construction, destruction, explosion…he draws in various references to then produce sound elements that not only fit to Win That War! universe, but should also not get the player bored or bothered even after several hours playing the same game. A matter of balance.

Wwise

The technology used is called Wwise. It’s a fabulous tool which is “artist driven”. Basically that means programmers only have to put events in the code (like “a tank explodes”, “the menu closes”…) and the musicians can choose how to mix sounds together, based on these events, without having a line of code to write. This allows us to do spatial positioning 7.1, but also procedural music based on scores that combine with each others to fit the intensity of gameplay. And that’s really cool.

And finally, here is a little video for you.

Physics!

Hi everyone!

It’s been a while since the last time I wrote on this blog. But you might be happy to know I worked on our brand new network layer…which actually works pretty well. But shhh, it’s Top Secret for now! You could give it a try when we’ll release the next Alpha.

Physics simulation, alright…but why?

Last week, I refactored the physics engine. In this old post, as a bonus in the video, you already had a quick survey of the WTW physics simulation. But, well, let starts from the beginning…what’s the purpose of this ?

In video games, physics simulation gives some substance to the objects, it avoids permeation/interpenetration: tables are put on the floor,  characters are stopped by the walls etc. In Win That War!, there are lots and lots of vehicles moving together on a field. I first developed the engine for this purpose: handle thousands of vehicles controllers. No spectacular effects, dynamics or debris yet. All of those will come later on! I was greatly influenced by the excellent “Bullet“, which is an OpenSource library, in addition of being well-functioning.

Here is an overview of Insanity Physics functioning:

Insanity.Physics-Overview

First, you fill the physical scene with objects: obstacles and vehicle controllers. The simulation is iterative and runs 60 times per second. The AI (path-finding) gives  speed related orders to the vehicles. The first step consists of detecting collisions between objects, that is to say, finding contact points. Then, the “Contact Solver” will correct speeds to minimize interpenetration between objects. The cars brake to avoid crashing into each other. For each contact point, I apply an impulse to repel both objects. If a whole group collides, the solver converges to a state in which interpenetration is lowered to the minimum for each group member. After speeds are corrected, we can compute the new positions and we can move on to the next iteration.

The collision detection is the most complicated part of the simulation:

Insanity.Physics.Collision-Overview

 

 

It is separated in two phases (Broad and Narrow). The Broad phase’s goal is to find potentially touching objects pairs. We approximate every object with a simple box to simplify tests. If two boxes cover each other, the objects might be colliding. This is the most time consuming part of the simulation. A “naive” Broad phase would consist of running every possible test, that means a million tests for 1000 objects (O(n²) complexity), which is too long. Many Broad phases algorithms do exist, especially  “Sweep and Prune” (SAP) which is used in most of physics engines.  Once potentially colliding pairs are found, the Narrow phase starts testing  if the real objects inside those boxes are actually colliding or not and find the potential contact spots. It is generally a group of algorithms. It is really easy to find the intersection between 2 spheres but when it comes to boxes and a field, something else is needed… that’s why I use XenoCollide for complex tests.

Finally, the engine’s last objective: geometrical requests. At any given time it is possible to cast a ray in the physical scene and check which objects it touches. This is generally used for a selection done by using a mouse. It is also possible to ask for everything that intersects with any convex shape. Concerning the missiles explosion, a sphere dedicated request is used.

To conclude, here is a video showing the physics’ debug drawing. As you can see it works pretty well, even with more than a thousand units!

In this video, you can easily see the broadphases boxes in red, the collision shapes in white (only sphere for the vehicles), and the terrain shape in yellow. To position the vehicles on the fields, we’re using ray casts which appear as red lines on the video, it’s also used to determine if the engineers are able to construct things. The debug display makes the video slowing down, that’s why you can see it jolts at the beginning.

That’s it for today!

Doom

XNA is dead… Long live SharpDX !

The rumor has been around for a while …. It is now official, XNA is dead, or soon will be, since it is to be retired on April 2014. Lots of regrets from indie game developers could be found on the net. “Those were the days !” … at least when it came to the high-level API in C# and its Content Pipeline system.

But do not worry, some solutions exist 😉 In our case, I chose to port to SharpDX, more specifically SharpDX toolkit, the high-level API based on DirectX 11. This API is yet not fully mature, but it is already efficient and has a very responsive community. Last time I had a problem, the author Alexandre Mutel provided me with a patch within the day.

It really is similar to XNA, but has the power of DirectX11, and is compatible with Windows 8 (including mobile version) and Visual Studio 2012. Of course it also works with older GPU classes : our new project WTW targets DirectX 10 cards.

The main drawback of SharpDX toolkit is the absence of the Content Pipeline. I solved the problem by using a custom MSBuild project and homemade MSBuild tasks to process the contents. I also use the lib Assimp for 3D models, and the effect compiler of SharpDX to process shaders. You can directly use DDS for the textures. As for the sounds, I don’t know, I haven’t searched yet: p

So basically, it means a little extra work, but it is worth the effort. Here is a screenshot of the new engine:

WTW_DX

Next : the video that fits, when the porting will be complete :)

Only fools never change their minds !

In these two posts, here and here, I spoke of my tests on the level of detail management when rendering terrain …

But first… Some time ago, Timous, our master of communication, scolded me on several of my articles, including an unpublished one (there seems to be censorship even here at IU :( ):

“Timous (to the wind): Tell me, Michel, your article on optimizing things, it is not bad …

Doom (very happy): Yeah?

Timous (glacial): But it’s just incomprehensible, you kidding me or what?

Doom (sheepishly): Um, bah it’s not that complicated …

Timous: There’s not even an intro, images are ugly, and my 11 years old little sister did not understand anything!

Doom: Bah this is an “Hardcore technical” article…

Timous: I don’t care, everybody must understand!”

So I will make some effort to introduce… this time 😛

In a 3D game, each image is calculated from a scene consisting of triangles. A graphics card can process and display a fixed number of triangles per second. The purpose of the management of level of detail (or LOD)  is to reduce the number of triangles to be processed in order to optimize the display time of each image (if it is not clear let me comment :D). In these two articles, I introduced the method of LOD that I had to use… Ultimately, I changed my mind and choose another method. This is what will remain, this time, in Robinson (is it a good for intro, Timmy?)

So I’ve implemented an algorithm called CDLOD for “Distance-Dependent Continuous Level of Detail Rendering for Heightmaps”, developed by a Filip Strugar. I’ll spare you the technical details that are very well explained by the author in this document… Here is a short demonstration video of my implementation for Robinson:

The more observant will have noticed the reduction in the number of triangle as they move away from the camera, and the progressive subdivision of the mesh. This algorithm is very fast and requires no pre-calculation, contrary to my initial algorithm. However, it has the disadvantage of ignoring the kind of terrain, resulting in a simplification of very poor quality on regular or geometric terrain. But as natural scenes are usually very irregular, this should not be a problem … Life is cool, does’nt it?

Return top