Archive for the ‘Development Tools’ Category


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:


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:




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!


At your service – The user experience

Insane User Experience

Hello everyone!

Looking at this blog posts, we can easily realize we write a lot about programming, but not that much about game-design. One facet of the game-design consists in thinking the user interface (UI). But writing about UI these days is so outdated! Now, people talks about UX, and UX only. Actually, it’s about the user global experience of the game. We can find lots of theories and recommendations all over the Internet.

Factory build queue
Factory build queue

The insane UX process

I have a practical approach about it :

  1. I reasonably code the UI. I want it convenient, plain and understandable.
  2. I test it, you test it,
  3. I improve it.
  4. And so on. Back to step 2.
Energy and Sharp Crysal gauges
Energy and Sharp Crysal gauges


The best feedbacks we had so far were from players who tested the game during some fairs (Stunfest, Utopiales)…even if it often makes us start all over again.

Our approach of the Win That War! UI

Why should you have to double-click while a simple click is enough? Why should you have to move the mouse till the very bottom of your screen while the menu could come up in its middle? UI is all about giving the player a nice experience,  that’s why I try to remain faithful to those principles :

  • every clickable component (no matter if 2D or 3D) has to react on mouse-over
  • every change in the game has to be visually and easily identifiable…
  • …and every visual change has to be the exact reflection of the simulation (damages, building progression, etc.)
  • at one time, necessary information only have to be showed up depending of the situation
  • in order not to penalize the player, the action has to be restricted ( ONE click, ONE button, ONE mouse-move…)
  • the more common is an operation, the more it has to be simple to execute.
  • for every action, we’ve integrated visual and sound feedback to easily inform the player that this action was taken into consideration.

Well, well, well…written like this, it may sounds really easy to do, but actually it requires a lot of work…

Feedbacks building tank traps
Feedbacks building tank traps

Since my latest post about UI, we worked on the conception of a brand new animated SVG-based panel. The UI is entirely javascript-coded.  And I’m using only 3 external libraries :

Jquery (I mean…How I’m supposed to do without it?)

requirejs (To fill Javascript major gaps)

snap (To easily manipulate the SVG)




The new alpha version of Win That War! will be released soon, so you could test it and send us your feedbacks. Then “back to step 2”

Nodes “à la carte”

Hi everyone!

Let me introduce myself: my name is Rémi, intern at Insane Unity for 2 months. During this period, I developed the terrain editor of Win That War!.

As you may already know if you’ve read this first article by Doom, our maps are modeled by shaders using noise generators. This technique has the particularity to generate a infinite game space, simply by changing the value of the seed. Also, the use of shaders allow to harness the power of your (so expensive) graphics card.

The editor I was commissioned to create aims at making the creation of environments more enjoyable. Indeed, instead of typing dreadful lines of code, it provides an editable graph that describes the shape of the terrain with interconnected nodes. Especially, this should let Philemon create maps without risking a nervous breakdown.

World Generator Terrain Heightmap Node Graph

The graph is made of two parts:

  • the heightmap
  • the splatmap

The first describes the the relief of the map. It mainly uses noise generator nodes to form terrain layers that are combined to each other.

The second is a logical system that determines where to draw each texture depending on the terrain characteristics (e.g. snow on the peaks, grass on the plain).

The result is directly rendered in the editor. Then the designer feels free to import textures, modify the nodes parameters and have fun exploring the world of which he is the god. Once the work is finished, we simply export the template in to the game to have access to a new environment, which we can generate an infinite number of battlefields for you, players.

World Generator Terrain Heightmap Node Graph

You are now well informed. If like me you are drooling profusely while waiting to walk on these alien lands, you will have to wait a little (someone’s whispering in my ear that a multiplayer version will be released in early fall).

Now, I said “goodbye” to you because my internship ends this day. It was a pleasure.

Long live Insane Unity! Long live Win That War!


Return top