Posts Tagged ‘Insane Unity’

The conquest system in the MMO campaign

The MMO campaign in Win That War! consists in acquiring new planets on behalf of your mega-corporation. How does it work?

A planet is divided into several hundreds of territories, all randomly generated. Each of these territories can host up to 9 players – 3 from each mega-corporation – simultaneously.


At the start of the game, the planet is entirely virgin, since it has just been discovered. The domination is made territory after territory.

The conquest of a territory is based on the score of the established mega-corporations. This score is calculated, among other things, according to the value of the buildings in the bases of its players. To claim a territory, a mega-corporation must achieve a minimum score. Thanks to a system of relay antennas, which limits the expansion of a player’s bases, it is very difficult to acquire a territory alone, so cooperation between players is highly recommended.


When a territory is dominated by a mega-corporation, it takes its color in the planetary view. But it is still “contestable”.

When a territory dominated by a mega-corporation is entirely surrounded by other territories dominated by the same mega-corporation, it becomes a “locked” territory, and only the players belonging to that mega-corporation can access it. To collect resources, for example.


Finally, newly discovered planets will be exploitable for a limited time only. At the end of the allocated time, the Galactic Board, the highest body in Win That War!, will announce the victory of the mega-corporation owning the most territories on the planet.

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:


Animation of the Artillery

Artillery of WinThatWar!

Original : Fisher Body craftmen

The animation of the vehicles is a perfect blend of handmade animation and procedural animation. I would like to begin with the latter type of animation, and here are the related elements:

> The movement of the vehicle is supported by the physical engine of the game. In this way, the vehicle follows the inclination of a virtual grid, a collision volume or, more simply, a deformed plan simulating the relief of the ground.

> The Artillery also needs to be able to shoot from different ranges and angles. Thus, the articulations related to the rotation of the cannon are animated by the code (what we call the “logic”) so that the shot adjusts itself directly to the position of the target, according to the position of the Artillery.

> The caterpillar tracks are also animated, following the movement of the vehicle. This effect is obtained by dynamically moving the UV coordinates of the model, in game, in accordance with the speed of the vehicle.

As a reminder, the UV coordinates are the correspondence between 3D coordinate (xyz) and 2D (uv) used to indicate where and how the textures are “drawn” on the model. In the case of the tracks, we could say that the UV “glide” on the 3D, giving an impression of rolling movement.

Artillery caterpillar continuous track

All the other animations are handled beforehand by the animator.

The animator is free to use all the other articulations available, except for the 2 articulations handled by the engine that we addressed earlier: the horizontal rotation of the turret and the vertical lifting of the cannon.

In the case of the Artillery, here are the elements created “by hand”, before the “logic” steps in:

> The animation of the installation. The vehicle is rather slow to get into siege position, and conveys the impression of a powerful weapon, which takes time to set up but is destructive. The disassembly is, however, much more short.

> Creation of shock absorption and a wave that shakes the whole vehicle when the Artillery shoots. This animation is achieved through the lifting of the mudguards, which is then synchronised with a shockwave effect, creating dust clouds.

animation joints and curves

And now, about shooting. This is when we add the particle effect which helps materialise the projectile, in the form of a plasma ball.

Finally, the death animation of the Artillery is simulated using the physical engine, called Mass FX. It is pre-calculated with the 3D modeling software and then reworked by the animator to get the desired result.

This animation goes with a smoke cloud and fragments spraying all around the vehicle. The destruction of the Artillery, alone, is not impressive enough to the player:


This is pretty much the life of the Artillery. From the moment it leaves the factory to its death of the battle field.

This post about animation is the first half of a two-part article. The next post will be entirely dedicated to the Sound Design of the Artillery which, as you will see, is directly related to the different animations addressed here.

Switching Win That War! to the Entity-Component-System Pattern

This post describes the switch of our gameplay codebase from a class hierarchy to an architecture based on the Entity-Component-System pattern (ECS). It will first explain why we undertook this refactoring and then present the new ECS framework with which we are currently developing Win That War!. The description is accompanied by some code samples as this post is voluntarily geared towards readers who are curious about the technical details of such an implementation.

The old ways

The Win That War! team is growing and the scope of the game has evolved towards a richer design than originally planned. Concretely, this means that we now need to support new game mechanics as well as new units with some unanticipated characteristics.

Some months ago, at the core of Win That War!‘s code was your typical class hierarchy. A base GameObject implemented all the shared behavior. Additional sub-classing then progressively added new functionalities to create specialized types (Fig. 1). This was all fine and dandy, until our game designer got loose and imagined fancy units such as the Command Unit. Here is an excerpt from its specifications:

The command unit is both a building and a unit that materializes the player’s presence on the game map. The player’s buildings can only operate within the range of a Command Unit and its destruction triggers the player’s defeat.

In other words, this unit must be able to anchor itself on the ground, like a building, but also to take off in order to establish new bases on any other point of the map. Behold the first flaw of the class tree, the dreaded diamond: due to the tree-like nature of our architecture, we got to a point where it was impossible to share antagonist behaviors such as being both a static building and a mobile unit.


Fig. 1 — Simplified representation of the initial architecture. The new Command Unit does not fit in this hierarchy.

At this point, we had two options. Option 1 was to go deeper into the rabbit hole and create a new subclass of GameObject (imagine a StaticButSometimesMobile class alongside Mobile and Static). Option 2 was to think ahead and switch to a more flexible architecture. Given the loads of other units and mechanics that are planned, it became obvious that we really needed to look at alternatives. After some consideration, we chose the Entity-Component-System pattern.

In the meantime, we settled for a quick hack: two versions of the Command Unit were coded, a mobile one and a static one, and we swapped them when landing/taking off. Let’s just say that we were only moderately satisfied with this approach. Some code had to be duplicated and having this very specific swapping logic for a single  type of unit did not sit well with us.

Composition over inheritance

The Entity-Component-System pattern is an alternative to the canonical class hierarchy. The three ingredient of the ECS recipe are:

  • Entities: the concrete instances of our game objects. For example, units, buildings, decor elements and cameras can all be entities. Conceptually, an entity can be seen as a bag of components.
  • Components: the pieces of data that represent specific aspects of the entity that they belong to. For example, position, physics parameters, 3D models and health could all be components. It is the aggregation of components that defines the nature of an entity. We call this set of components the entity’s composition. A strong characteristic of the ECS pattern is that components should only contain data and no logic.
  • Systems: the modules that govern the logic of specific parts of the game by manipulating related components (Fig. 2). For example, a Drawing system could examine the Position and Model components of entities in order to render them. A Physics system could examine Velocity components to mutate Position components. Another strong characteristic of the ECS pattern is that all the game logic should reside in systems and that systems are responsible for the interaction between components.

Fig. 2 — Entities (Top) can be seen as “bags of components”. Systems (Bottom) update them. There is a clean separation between data and logic.

ECS is a component-based pattern with a strict separation of data and logic. The Unity game engine often comes into the discussion when speaking of components. However, the vanilla Unity approach is looser in its definition: a component (MonoBehaviour) contains both the data and the logic. Some libraries do provide an ECS layer for Unity, such as Entitas.

Here are the benefits that we expect from ECS:

  • Flexibility: it will be trivial to dynamically alter the nature of our entities. Want to temporarily buff a unit? Simply change the data in the appropriate component or swap it with another component altogether. Similarly, systems can be enabled/disabled at runtime, which is extremely useful to un-complexify the game for testing/debugging or to reproduce Minimal Working Examples.
  • Data-driven: because ECS is so strict about the separation of data and logic, we should naturally end up with a more data-oriented application. Hence, it will be more straightforward to deserialize our on-disk game data (authored by the game designer) into game entities. Similarly, it will be easier to sync this data over the network without resorting to an intermediary form.
While it was not the reason for this refactoring, ECS is also known to be performance-friendly because the underlying data structures are often layout in a way that corresponds to their processing. That is, same-type components that are processed sequentially by logic systems are contiguous in memory. Thus, the CPU cache is happy.


The new architecture had to mesh well with most of the code that was already in place. To this end, we designed the central data store for entities and components (the Entity Manager) to expose them in different forms to the “legacy” code and to the “new” code (which will reside in Systems).

The gist of it is that the legacy code uses stand-alone Entities with a similar API as the old stand-alone GameObjects. However, the new ECS systems leverage a more sophisticated approach in which they process views on entities that match certain compositions (each system has it own criteria).

Fig. 3 gives an overview of this architecture. Each part will be discussed in the following sections.

Fig 3 -- TODO

Fig 3 — Our ECS architecture. The game data is exposed to the “new” code and to the “legacy” code in different forms.


We use an interface to mark a class as being a component. Notice that there is no internal references to the entity that owns the component. This is a voluntary design choice: not exposing the owner forbids indelicate programmers to access unrelated data (eg. myTransform.Owner.AnUnrelatedComponent). Even more importantly, not exposing the owner prevents to add any logic to the components that could mutate them from the inside, since their context of execution (the “neighbor components”) is unknown. The way in which logic systems do access this context in order to make components interact will be discussed in a further section.


The entity manager contains the meat of our implementation. It has the following roles:

  1. Managing the entities lifetime. Users have control over the creation and destruction of entities. On creation, an entity is given a unique ID by the manager. Under the hood, entities are stored in a map in which they are indexed by this ID.
  2. Composing entities. Users can create, destroy, and query components. Components are stored in a matrix-like structure where rows correspond to the various types of components, and columns correspond to entities. Querying component X of entity Y is a matter of looking at element (X, Y) in this map. Tab. 1 illustrates the kind of data that can be found inside the matrix if you were to inspect its content (this article provides a nice illustration of this layout).
  3. Categorizing entities with respect to their composition. The last job of the manager is to keep track of which entities match a set of user-defined compositions. In this way, logic systems can process only a subset of the existing entities and only consider components that are consistent with their work. This mechanics is detailed in the Logic Systems section.
Tab. 1 — The game data is stored in a matrix-like structure that associates component types and entity IDs. Rows correspond to component types. Columns correspond to individual entities. Changing the composition of an entity simply consists in filling its slots with other components.
(decor element)
  • x: 0
  • y: 5
  • z: 1
  • x: 0
  • y: 0
  • z: 3
  • x: 0
  • y: 0
  • z: 5
  • x: 3
  • y: 10
  • z: 10
  • type: dynamic,
  • mass: 1000
  • type: static
  • type: static
  • name: "tank"
  • name: "crystal"
  •  name: "tiny_rock"
  • name: "factory"
  • effect: "laser"
  • dmg: "5"

This structure is a good illustration of the flexibility provided by ECS. It really favors experimentation and quick iteration because, once all our components are defined, we can design entities with novel behaviors in a pinch. For instance, it’s trivial to weaponize a factory (give a Weapon component to #4) or to make some decor elements interactive (switch the RigidBody of #2 from static to dynamic) so that players can play with them.


An IEntity instance exposes methods for mutating and inspecting a specific game entity. In practice, this interface is mostly used by legacy code that has not been converted to ECS. Because its usage closely resembles that of the previous architecture (a stand-alone GameObject held all the data of a single unit/building/game thingy), we kept a similar API, which significantly reduced the amount of code rewrite.

Manipulating entities is straightforward:

The concrete Entity class that we use acts as a facade for the EntityManager. It also adds a layer of cache in order to reduce queries for the most used components, plus game-related metadata that we had to keep for legacy reasons.

Logic Systems

The last part of the architecture deals with the logic systems that update the entities’ components and run the game simulation. Let’s start by looking at the type of code that we wanted to avoid writing:

We did not want to iterate blindly through all entities (there could be thousands), filtering them away with some predicate, only to process a fraction of them. Instead, we needed a way for each system to express which types of entities it is interested in ahead of time, so that it would only process those.

This mechanics is made possible by the formulation of compositions. A composition is a user-defined class with a number of fields of type IComponent, as well as a reference to an entity that possesses said components.

A composition instance, or node, can be seen as a view on an entity, exposing only components of interest. Their creation is handled by the entity manager who is already responsible for mutating the entities and thus provides the best place to also inspect them when a change in composition happens. Basically, for each existing composition type TComposition,  the manager has an internal collection CompositionNodes<TComposition> containing one node for each entity that matches TComposition (see code sample below).

The logic systems can access those node collections via the EntityManager.GetNodes<TComposition>() method that was seen previously. They can also subscribe to two events: OnNodeCreated(node) and OnNodeDestroyed(node). The collection raises OnNodeCreated when an entity matches the composition and it raises OnNodeRemoved when an entity does not match it anymore. In this way, systems do not need to consider an entity during its whole lifetime, but only when the entity’s composition is relevant to its work.

Here is an example of a physics system written with this strategy.

In this example, the system reacts to new entities having both a Transform and a RigidBody, and it manipulates nodes exposing only those two components. A benefit of this approach is that a programmer does not need to know the inner workings of our ECS implementation by heart to write new systems. The entity manager does all the bookkeeping by tracking which entities match which compositions, and systems just have to listen to the events that it raises.

This notion of expressing subsets of entities to work on can be found in other forms in established ECS libraries. For instance, Artemis-odb lets users formulate aspects and the Ash framework lets users define nodes in a way similar to ours.


After spending several months coding gameplay within this new architecture based on ECS, some conclusions can be drawn.

  • Unavoidably, refactoring a sizable codebase such as Win That War!‘s was several week’s work. Switching to this new “philosophy” also required a bit of getting used to from everyone in the team. So, all in all, the move to ECS took a bite in our schedule. However, the promise of ECS is to make up for this lost time with greater speed and flexibility during the rest of the development. It seems that ECS is already paying dividends as we now iterate more quickly on new features.
  • We had to make some compromises during the switch to ECS and chose to convert specific parts of the codebase in priority. Some aspects of the game logic still adhere to the old ways of doing things and will probably not be updated due to lack of time. And this is fine, because these parts interface well with the Entity facade that we described. In any case, the code that has been converted — as well as new code — feels cleaner. It’s just simpler to write clear, explicit code, and a lot of complex use cases just seem to sort themselves out naturally.
  • Finally, the ECS favors isolation, which is precious for testing/debugging purposes. For instance, we obviously don’t want to pull all of the game rules in our unit tests and some game mechanics that would be constraining in this context (eg. the need to be close a relay for a unit to be active) can be trivially disabled by turning off the systems that handle them.
Screenshot of Win That War! with the components of several in-game entities

Fig. 4 — Some components actually used in Win That War! for different units.

To conclude, switching Win That War! to the Entity-Component-System pattern required a significative amount of work but we are already reaping some benefits. The gameplay code is more modular since various aspects of the game are now neatly decoupled from each other. Most importantly the game code feels clearer and gives us a better sense of control. For the curious, Fig. 4 shows a screenshot of Win That War! with some of the components that are actually used under the hood.

About this Command Unit trick that we had to resort to (the building version sneakily swapped for the mobile version): now we just give our unit a Building component when it lands. When the unit takes off, we replace the Building with a Motion component and all is well in the ECS world!


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


New year, new team, new trailer

Ok, I admit this title is not the most original I could find.
But, you know, the video is speaking for itself:



Putting aside logos and the lost territories map made from hexagons, everything you see in this video was captured in-game. As you may have noticed, there is a lot of changes concerning the Sound Design. Hey, we told you there was a reason for Jpeg hurting his car.

Next week, the post will be proposed by Philemon, so you can guess it will be a bit artistic one!

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!



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.

Hi you, we’re hiring!


You’re a French speaker and you want to join Insane Unity ?

Please see our job ads here : Careers

Return top