Posts Tagged ‘jeu’

Dynamical sound-design: the Artillery

For Win That War! we chose to work with the Wwise audio engine, which offers a greater autonomy to the sound designer.

Freed from technical constraints thanks to a tool such as Wwise, which brings a real flexibility of use and very intuitive tools for sound integration, all that remains is to be creative: recover the events of the game to play the sounds of the objects, of the atmosphere, the feedback, the music… and work the sound in its entirety to create a cohesion between all these sounds.

For this first article about Sound Design, we chose to talk about one unit in particular: the Artillery.
This is the 2nd part of the article about the Artillery animation, you can read it here.

artillery win that war

The Artillery is a vehicle which, in the game, plays several animations. To achieve the sound of the vehicle and stick to its animations, we divided it into five parts:

  1. Movement
  2. Artillery landing
  3. Cannon deployment
  4. Artillery shooting
  5. Artillery “take off”


Movement :


An engine sound is played when the vehicle is moving, two events allow the sound to start and stop.

These events are common to all of the vehicles of the game, they are linked to a switch in which the sounds of vehicles are located.

  • StartEngine
  • StopEngine

Wwise events


The “StartEngine” event plays the “EngineSounds” switch. The “EngineSounds” Switch contains all the sounds of all the vehicles. These sounds are named exactly the same both in the switch and in the code of the game, playing the sound corresponding to the right vehicle.


The “StopEngine” event mutes the sound of the vehicle played in the “EngineSounds” switch. The selected line (dark gray) corresponds to the action performed by Wwise on the selected object.

Wwise sequence


The “EngineSounds” switch on the main tab (and not the event tab) contains the vehicle movement sounds. By selecting the sequence of the Artillery, we enter the settings window.


Artillery landing:

At the very moment the vehicle sets into position on the ground, a sequence of sounds is played, triggered by a “code” event, which plays the sounds in Wwise.

This sequence consists in several sounds which are played one after the other, or overlap one another.

  • ArtilleryLand
  • ArtlleryLandRotation
  • ArtilleryDeploymentTurret

Wwise event


The « ArtilleryLand » event plays the Artillery landing sequence.

Wwise sequence


This “Container sequence” contains the different sounds constituting the landing action of the vehicle. The playlist, at the bottom right, allows you to decide in which order the sounds of the sequence are played



Cannon deployment: 


Following the landing of the Artillery, the cannon deploys. This sequence is launched by an event:

  • AtilleryDeploymentCanon

Wwise event


The “ArtilleryDeployement” event plays the sound of the cannon deployment. When the order of deployment of the gun is launched, an order to stop the landing sequence “ArtlleryLand” is sent from the same event, at the same time.

Wwise sequence




Artillery shooting:


Then, the time has come to fire…


Always driven by an event, a sequence mixes the shooting sound with a “metallic” recoil sound, and another for ammo reloading.

  • ArtilleryShoot
  • ArtilleryShootCanon
  • ArtilleryRecharge

Wwise event


Wwise sequence



Artillery “Take Off”:


Once the target has been destroyed, or by order of the player, the vehicle must be moved. A sound is played when it leaves its state of siege.

  • ArtilleryTakeOff

Wwise event


Wwise sequence



Each sound is created ahead, with an “audio sequencer” software, in which an animation video of the vehicle enables to tune the sounds to the image and to proceed to the editing of the recorded or collected sounds, as well as the processing. This creates a harmonious and credible mix (eq, filters, pitch, compression, reverb…)

Everythin is made as one piece, then cut to create several sounds. Then, these sounds are exported to Wwise and played in sequences as explained above.

In game, the different parts that make the final sound of the Artillery are played accordingly to the actions of the unit.

And this is how it looks and sounds in game, when you are playing:


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.

Step by Step #1 the Engineer

Moving on with our new blog sections, this time we decided to tease you with some new eye-candy. Down to the real talk, we’re taking you step by step through the process of implementing an asset, from conception to in-game integration.
To inaugurate this section, Michel the engineer bot is going to be our guinea pig.
A few months ago, this is how Michel used to look:

Miche Insane Unity Win That War RTS

Since Nico has recently joined the team, Michel got a little face lift. We kept the same feel but made him a little more bulky for some additional #galacticswag  (please, be sure to use this hashtag in strict moderation and keep it away from children).
If you’re in the process of creating game assets yourself, feel free to share and compare your own workflow down there in the comments. Here is our usual pipeline:





Model sheet.


3D model.


Well, now we’ll just have to put it in the game, and the good old Michel won’t exist anymore. Don’t be sad, on the inside, he’s still the same!


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).


One year already

So, yesterday was Insane Unity first anniversary.


When we first started the project, two and a half years ago, I already knew we would have a lot of work to do, I knew that would take time, and I knew it would be hard to make it real. But, well, we did it: now, Insane Unity team has grown, we’re 10 members, and when I think about all we got through from the start, I admit I’m kind of proud of us, and I’m thrilled. I’m thrilled because I realize that if you’re persevering enough, you actually can make your project comes true.

Yet, we must confess we don’t really have much good reasons to boast: we’re progressing on the game development but it’s not ready to be available on Steam…. yet.
Just one year. It makes me feel like Insane Unity is just a baby, thinking he has already did a lot since he born, but he still has everything to learn about life. And we still have lots of things to learn about being a “company”. Everyday we learn, everyday we do some self-analysis: are we going the right way?

Moving from a 2 members team to a 10 members team actually involves to do self-analysis often: you must be able to accept criticism, from outside and from inside the team, to justify every choice you make puting your ego aside, to trust others and just hand down a lot of all these things you were used to be in charge of. By joining the team, every single new member brings with him some new ideas, as consistent as your own, and as “founders” we have to connect all these ideas, let everybody in the team knows they’re important and necessary, and to make the good choices for the game. We attempt to take this way, and trust me, that’s not that easy everyday. But, after all, designing and developing a game is mostly about humans relationships, isn’t it?

So, in the months to come, I swear you’ll see what this new team is able to do!



Goodbye, silence

Once upon a time, we were a small and quiet team sharing a tiny office, then it was 2016. This new year brings us some noise ! No, no, I’m not talking about those 10 team members in a fenzy of brain activity, no, I’m talking about the 20.000-sounds-man, Jpeg, our sound designer who’s now working with us at the studio.

After some days plinking on his keyboard (you know, the one made of long black and white keys) he’s just gone into an exile by himself, entered the solo mode in his own room. But, it hasn’t put a stop to his silent-breaker skill. At the contrary, since he’s working in his very own “sounds cavern”, he’s testing and testing again, creating and making again the sounds of explosion, circulation… We even surprised him hitting his own car to record a base to create an impact sound.

Well, you can listen at these new sounds by watching these short videos right below.


That’s still not the final version for everything you’re listening here. Anyway, for the ones interested to know what changed from december 15th, we made a small list right here:

  • Artillery
  • Airknocker
  • Laser
  • Shooting impact
  • Explosion
  • Missile
  • Ship background sound
  • In-game sounds polishing

A large part of those sound effets are created from “noises” recorded outside, in the real world. That’s why this strange creature who is the sound designer sometimes hits his own car or to bring back to the office some plastic bags full of  gravels. Well, of course, for some sound effects, it’s a bit more complicated: I don’t imagin Jpeg standing behind a plane which is taking off. That’s why he also uses online sound banks potential. And after that, come the time to mix, brutalise and twist all these sounds with the help of a sound processing software, then it’s integrated in the game with the help of Wwise.

And here is a present for you, you little snoop, a picture of the lair. Hope you’ll be back on next Friday for a bit special post !


Utopiales and Art to Play: November fairs

Putting aside our recent penchant for recruitment and furnitures assembly, we are still (yes, we do!) collecting all your feedbacks to improve the game. And game fairs, show, conventions are the best for us. Really, it’s amazing to meet you all, watch your reactions while you’re playing WinThatWar! and talk about it with you. And, in November, we were kinda lucky since we were present at the Utopiales and Art to Play, both of these fairs taking place in Nantes.

Just like last year, the Utopiales public was really… young. Anyway, he also was very enthusiastic, and from the beginning of the afternoon, the kids were just there, staying at our stand, helping out and teaching the new comers how to play WinThatWar! That was really great for us to see the youngers able to understand the game and how to play it. Sometimes, at the expense of the elders! Hold on, don’t get mad, “elders”, we know most of you will become some really badass strategists as soon as the game will offer more features and options.

Utopiales Insane Unity

We neither regret the Art to Play weekend. At the contrary! You were so many to stop by our stand, 14yo young women to 60yo grown men, testing the game and tormenting us with your countless and unusual questions (Actually we love that, it makes us look deeper into the game mechanics, so please don’t stop!), and also encouraging us. Well, we won’t lie, this weekend was exhausting (like really, it killed us. 5 days later we’re sleeping on the tables at the studio. I barely exaggerate, promise) but still, it was really rewarding. We wrote a lot of your feedbacks and ideas on our notepads. Plus, that was a good opportunity to see if you’d like the tokens/strategy icons, as it was a brand new feature in the game. Unless I’m mistaken, i think you liked it, and the map general view have seduced many (mini-map “are so 2014” anyway.).

In short, if we should summarize those 2 weekends:

  • The younger are the players, the rougher they play. They just spend their time building turrets.
  • We can easily welcome 13 players at the same time on our stand, even if it’s only 2 computers.
  • Trying to give some explanations about our game when Matthieu Sommet (SLG – a french famous youtuber) or Ganglion (J-rock band) are standing on the stage, about 10 meters far from you, can be a quite difficult excercise. That’s why we just gave up our vocal cords there.

Art to Play Insane Unity

Again, thank you to every single player who came to these conventions.

Recruitment season is over!

Hi everyone!

Do you know we missed you, like, a lot?!

We know, we were not very present on this blog lately, because, well, we didn’t have much news for you. But now, we can announce it : Recruitment season is over! Finally.

We’ve “lost” some time regarding the previsional Roadmap, but we didn’t think (when we wrote it) we would have to hire six more people til the end of 2015. Anyway, we finally made our choice, and soon, we’ll be able to come back to a normal working rhythm. Everybody is back in front of their computer screen : back to code, back to design, back to blog… and that’s a relief. It was necessary for us to make the team grows, so we could make the best game we’re able to create, for ourselves, and most of all, for you.

Why we spent so much time on this recruitment season, is because we did our best to answer every single application. We read every single resume and cover letter, we visited and evaluated every websites and books that have been sent to us, so we could choose the right people for this first game, but also for the future of Insane Unity. It wasn’t easy at all, we’re doubling our number, after all! The good is that, in less than a month now, the team will be complete. Our sound designer even join us next week. We’ll try to make you a small recap about all of this by the end of the month, and, we’ll introduce our “newbies”, for sure.

Until then, it you haven’t seen it yet, we produce a video trailer about Michel’s life. That’s all made from in-game screenshots.

We’ll be back next week for a review of the two fairs we were present at last month.

Have a nice weekend.

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.


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.


Return top