The cake is a lie

This post is not about the game Portal, sorry, it’s about baking cakes…

First, imagine that you want to make a cake like this one:

a cake rendered with Marmoset
You do a nice and highly detailed cake model. It’s perfect.

But it’s just one, and you’re really hungry. You want more cakes, lots of cakes!

Unfortunately, you can’t just put 1000 high resolution cakes in a scene. So, you have to learn how to bake.

A cake in my game

Indeed, in a video game, you expect a smooth rendering. Especially for action games, as racing games, you want a lot of images per second. To accomplish that you have to respect a polygon budget (also called polycount). Doing that, you will ensure to have a good framerate when you will run the game on your computer. If you don’t keep to that limitation you will (probably) suffer of latency.

The computing of a 3D scene into a 2D image takes time. But, naturally, you don’t want the player having to wait for it. So you have to make both (high and low poly) if you want a good result without affecting visual quality (theoretically).

The principle is: you just have to bake the high poly on the low poly. Seems simple, right ?

polycount difference between two 3d models

Okay, it’s not really a “baking” thing, it’s more a projection.

The volume informations are transferred from the high onto the low polygon mesh in the form of a texture (or map). This texture is made of 2D informations that the graphical engine will read to produce the real time rendering.

Remember, only the low polygon mesh is exported to the game (and its maps of course).

Here are a normal map and an ambient occlusion map:

Maps result of the baking You can see the result on a simple plane:

a flat cake

A comparison between the 2 models: baking on a volume is a bit harder than on a plane.

Comparison between 2 models.

As you can see you’ll lost some important details like the rounded border of the bottom of the cake. Your goal, as an artist, will ideally be to preserve the silhouette of your model.

The recipe

So far, that was just a cake. Now, here come the real thing and the serious business. I give you my own recipe.

Step 1) You create a High Poly.

HighPoly Mesh Colored

It’s an example of High Poly mesh (3 millions triangles) with false colors.

Step 2) You create a Low Poly.


Low Poly of a building

It’s an example of low polygon mesh (6,000 triangles).

Step 3) You try to adjust both to get a  perfect superposition (almost).

Superposition of both high and low polyIt should give you something like this.

Step 4) You can add a Cage to it (and visually hide the Low Poly).

Nicolas Cage

The Cage is used to properly define the projection between the high and the low.

Step 5) Explode everything!

Exploded Models

The point of this explosion is to avoid interpenetration and shadowing (ambient occlusion) between pieces.

And yes, the time has come for you to push a button and wait patiently for the result, wondering if you didn’t forget one step.


And here it is, all hot. You can get it out of the oven.

low poly with baked informations

There are still some imperfections to fix. Maybe a step six is needed. But it will be for the next time.

At the end, to achieve the creation of a good cake, you need to strictly follow the recipe knowing that the result is worth the efforts and time you spent on it. The better maps you get, the easier will be the texturing part. Especially if you are using a fast texturing solution like Substance Designer, that I have used to bake this asset. That’s why it’s a very sensitive part that will validate (or not) the modeling you did before.

So, the baking is no longer a secret for you.

Don’t hesitate to ask for help if you don’t get the result you were expecting.

See you next time.


If you want to learn more about baking:


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.


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.


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!


Easter bugs hunt

This air unit has some issue to fly. It's a bit shaking up there.

This air unit has some issue to fly. It’s a bit shaking up there.

Two newcomers

If you’re following us on social medias or if you subscribed to our newsletter, you may know that Insane Unity team has slightly grown during the last months. That’s why we move in a new office a couple of weeks ago.

These some additional square meters were actually necessary, since we welcomed two trainees in addition of the four employees we already were.  Kevin and Yannick respectively joined us in early February and early March and they’re helping with the game development, including integration of the new units and buildings. And sometimes, these integrations are a bit…unpredictables.

Not an easter-egg, just some unmanageable units

grosbomberweb3An easter-egg in a video game, if some of you need a reminder, is an hidden  feature…which often has no more ambition than to troll the player, and which sometimes may looks like a “bug”. GTA or Half-Life addicts, for example, are used to it.

The following gifs could have been some easter-eggs, but they’re not. They’re not some jokes we put into Win That War! These are only integration failed first tries. Don’t worry, it’s all fixed now and you could enjoy this new units in the next alpha release.

Anyway, we thought that our dev-blog might also be used to show you some tests states, and the necessary  mistakes which come with it. That’s why, today, we wanted to share the backstage with you.


The artillery decides that today it wants to be a spin top.

The artillery decides that today it wants to be a spin top.

Another spin top issue. This  bomber is going to feel sick soon.

Another spin top issue. This bomber is going to feel sick soon.

Here you can see an average sized turret. Then a giant sized turret ghost appears.

Here you can see an average sized turret. Then a giant sized turret ghost appears.







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″

WinThatWar! presentation pitch

A meeting for Rennes startups

We were Thursday, March 5, 2015, the winter breeze was whipping our faces … and yet, despite the cold, we went to the Pitchcamp, co-organized by Telecom Bretagne and “la Cantine Numérique rennaise”. If you  never have  heard of it, it is an opportunity for young companies, startups, to present their project in front of an heterogenous audience, all digital and technological innovations enthusiasts. That’s us. That’s totally us ! That’s why we did this presentation. This also gave us the opportunity to see what else is developed these days  in Rennes digital ecosystem. Once again, it was quite heterogeneous.

On the agenda: Some apps and connected devices  giving all kinds of  sports results and statistics. Long-distance social -drinking with friends. Softwares to help businesses to reach their customers or to detect online fraud.

 A video is worth a thousands words

So, we just  landed in the middle of all of that, with our slides to tell them about video games, retro-futurism, and persistent universes. You dreamed about a clear and simple presentation of WinThatWar!? We hope this video will satisfy you.

Brand new generators

Let’s end the week (and the month) smoothly, and with some pictures. Philemon worked his fingers to the bones this month, and after the air units, we now can show you some of the buildings that will be integrated in the future. So, we have a lot of pretty things to show you, and today our brand new generator is in the spotlight.

Once upon a time : Tesla

Concept generator 2 Insane UnityAs every creation, this generator was born of a mix between some selected references and our artist’s imagination. This time, he kind of felt in love with a nice monument which quite inspired him.

If you’re a geek-person, or if you have an inquiring mind (even if you’re an electricity specialist or if you are well up in general knowledge…it’s ok, no judgement) you might already have heard the name of Nikola Tesla. Tesla was a great scientist and an very creative man. He is behind many discoveries and innovations in the wide world of electric energy.  But Hey, nor you nor us are on here for a History class, and you probably could find loads of information about that dear Nikola all over the Internet.

Well, why are we writing about that ? Actually, because the Las Vegas “Tesla fountain” commemorative monument was the main reference used by Philemon to design the Generator. You can take a look here and here. You might well notice some elements you’ll also find on the illustrations below.

And there was the Generator

Concept Generator Insane Unity
As you can imagine, our generator is used to…generate energy.  As a power (or nuclear) station, once built, this building produces energy that will be used by your other buildings and units. However, be careful not to overuse its power, otherwise BOOM !

3D generator Insane Unity

Wait…we didn’t noticed him, but Michel (our robot-engineer) is on this screenshot. You, little scamp!

Have a nice weekend.

Artificial Intelligence, part 4: Congestion

Here is the 4th part of my Win That War’s IA series. Today, I’ll write about flocking behavior.

Let’s start with a video. A tanks army is riding through a canyon. If you give a look to the left side of the video you can see that the units are lining up, which put them at the mercy of an ambush. It also takes a while before they finally cross the mountain. Now, the right side of the video. As you can see, the units take the canyon’s entire width, and quickly arrive to the other side.

This noticeable improvement is simply due to the use of a flocking algorithm.

Because of my early affection for the flowfield technique, which is notably used in Planetary Annihilation and Supreme Commander 2, until now I neglected this type of algorithm.  Actually, a well settled flowfield allows to go without using flocking: the units have a natural behavior, then the congestion and collision issues are efficiently solved.

But here is the thing: I figured that using the  flowfield generates two problems. First one is that it’s hard to optimize, and that Win That War! maps vastness involves a huge memory consumption. The second one is that the paths computed by the flowfield solver are approximative, and it’s a real issue when a robot has to go through a dense base, slaloming between hard-to-cross buildings.

So… I just threw  everything to get back to a more simple but efficient “Weighted A*” algorithm. IA code just got more “thin”, and the performances got better. But, you know, nothing is that easy, and with that kind of algorithm, we fall right back into congestion issues. That may be why you had a bad time crossing mountains with a big army in the Alpha 0.2 version.


That’s why I decided to add a flocking stage.

Your fingers are getting itchy and you want to try this by yourself? You’ll find a nice introducing method here.

In the end, the choice of a pathfinding algorithm really has a strong impact on the game, not only on  the bugs… Flocking makes the game a little more “nervous”, and units behavior seems different.

The future will tell us if we made a good choice.


Warning ! Air units deployment.

If you already played to our Alpha-Demo (If you don’t, jogtrot to this website : you know that, in Win That War!, there is some tanks, which drive…on the floor. Well, that was a good beginning, but not enough. If you would like to have a go at these damn tanks and engineers, you might need some air units. What a coincidence, that’s precisely what we are working on these days.

fighter bomber1

Concept arts, icons, place-holders, integration… and here they are, our very first bombers flying across the map. Actually, well, that wasn’t that easy. Those little flying guys had first decided that it would be funnier for them to become some kind of underground units. I mean, we had some issues integrating them at first, and the bombers were buried under the sand, showing only their cock-pit and vertical stabilizer. We just deleted the evidences about that. And everybody and every unit went back to their place, in the air or on the ground.


If you’re a lucky guy, you might experiment these firsts air units in Win That War! next release. Hope you’ll put it to good use.

Meanwhile, you now can have a quick overview of what is coming.


Pitch my game – Meeting at Epitech engineers’ school

January 21st, we were present at the 2nd edition of the Pitch my game BZH (understand Breizh – Britain) at Rennes’ Epitech school. We were there to introduce our game, Win That War! in front of about a hundred of persons, most of them also working in the Video Game industry : SNJV (National Video Games Association in France), 3 Hit Combo (Rennes’ crew organizing the Stunfest convention every year). And some other independent video games’ developers : Ballistic Frogs, Wako Factory and Triskell Interactive, among others.

This “around Video games” meeting gave us the opportunity to observe the public reaction towards our more or less technical presentation of Win That War! It appears that most people enjoyed it. Some of our colleagues really pleased us with kind encouraging comments and compliments. It feels good. Doing the presentation of a video game, or any creative work, when it still in progress, is always a challenge. It might be really clear for the artist or developer himself, but it’s always hard to explain to others. Fortunately, there is some videos of the event. Unfortunately, there is no english subtitles. If you want to watch it anyway (if you understand french, or if you just want to have a look at the slides & demo), here it is :

Don’t hesitate to contact us if you’ve got some questions about the game itself, we’ll try to answer it in a future blog post.


Return top