Space Needle

Space Needle

Hello, folks

Today, let me present the air factory to you.

Thanks to it,  you’ll soon be able to produce all the air units you always dreamed about… well at least the ones we designed for the game (sorry to all of you that were already imagining themselves flying the Millennium Falcon, it’s not planned on our Blueprints list).

But let’s get back to the factory itself : I was inspired by the Space Needle, a huge tower located in Seattle. But also by the Hesperia Tower, an hotel on the top of which we can see a beautiful retro-future dome. Have a look here: Click-me.

early concept of the air factorySecond concept of the retrofuture air factory

We wanted this building to look like an airport combined to a shed, that’s why it’s equipped with a control tower. Just in case the non-existing-tiny-little-planes-makers would like to call back a defective serial number…

Well, I warn you, this is still work in progress.

About tools: we use Marmoset Toolbag to preview the model and materials. So it’s not  very representative of the final in-game model. We will do our utmost to visually approach this rendering.Air Factory standby model

 

Lights on: working factoryAir Factory working mode

 

I’m still not sure about the dome…

We don’t have emissive effect (also called glow) in our engine yet but we will work on it. It’s an unavoidable feature anyway!

The next step will be to add some more details to the model: antenna, vents, and maybe a dynamic windsock using physics, too.

Don’t hesitate to tell me what do you think of it. What could be better in your opinion. I’m right here, keeping my ears open just for you.

Hope you enjoyed this post!

Philemon

A new website appears

Logo_WinThatWar

This week, we’ll just make do with a small announcement.
No big technology related blathering nor plenty of beautiful pictures today, but we promise to get back to that very soon.

Win That War! website grand opening!

Nope..today, we announce you that WinThatWar! website is now online. Universe, Roadmap, Team…some pages will need to be reworked later, so we could provide you more details about the game’s background little by little.

support devblog

Meanwhile, we hide a little surprise for you on the website. That’s not so much complicated to find, so you don’t need to train your 6th sense before visiting winthatwar.net !

Have a nice weekend, under the sun or in front of your computer, as you prefer.

About RTS engine determinism

Hi everyone!

This week I’ll write about a topic which may seems a little bit austere, but truth is that it can easily become quite fun: testing

How to test a game?

When we talk about test, it may refer to several things. In the case of WinThatWar!, we distinguish three test levels:

  • unit test
  • integration test
  • test in real conditions

Test in real conditions

Let’s start with the last one, it’s the simplest: the best way to test a game is obviously to play it. It allows you (and me also) to find out unexpected issues, not only bugs, but problem of use as well (ergonomy, feeling, gameplay possibilities…)
When you’re coding a game, you can’t stop telling yourself that you really need to improve it and you forget to play it “seriously”. That’s why, at Insane Unity, we schedule regular test sessions of WTW, that we intensified when the release is about to come out.

The problem is, after a while, we know the game really well, we play the same way again and again by force of habit, and because of that we’re becoming unable to hit the broad side of a barn. That’s why we are constantly looking for new users. Newbies allow us to easily find out ergonomy issues and to make a game which will really be easy to play. Talented RTS gamers allow us to estimate how hard to master is the game, and they bring out balancing issues and the efficiency level of the interface.

Once again, I take this opportunity to thank you all, all the alpha-testers. If you weren’t there to help us improving the game, WinThatWar! would be of a much lower quality than it is today. That’s your game too!

IMG_20150523_121101

 

Unit test

Unit test responds to a very simple problem: not to go round and round in circles everytime you’re coding something, undoing what was already working.

Before comitting any change in the code, the developer have to execute tests that will check if every module’s basic fonctionnalities work well. For example, some path-finding tests check that two groups of units can cross without striking each other, some others exist to check that our maths library’s convertion functions produce the expected result, etc.

Generally speaking, a unit test is written BEFORE coding the function it will satisfy. It’s called TDD.  This is one of the fundamental practices of agile development. Unit tests are very useful to “re-factorize” the code, in other words to deeply overhaul it without changing its functionality, in order to get it ready for the add of a new feature, or to make it simpler and less subject to bugs.

If a dev ever commit a change that “broke” one of these tests (called regression), he received an e-mail from our buddy Tim (that’s the name of our integration server) that gently insults him, and keeps doing so as long as the problem isn’t solved.

 

Integration test

Finally, the integration test takes place between the two other kind of tests I just wrote about. While unit test limits itself to test a module, integration test consists, as the name suggests, on making all the modules working together.

At Insane Unity, that means make 4 AI playing in 2vs.2 every night. Here again, Tim is in charge. Forward, we’ll check that we meet the expected balancing (for example, that AI lvl 5 always beat AI lvl3 in less that 10min.) But, for now, we’re using these tests for two things:

  • check there is no crash during the game
  • make sure our simulation is desterminist

 

RTS engine determinism

Determinism, WTH is that? Once again IT engineer gibberish…actullay a program is called determinist if it provides the same result every time it’s launch with the same starting conditions. It may sounds a bit “dumb”, but that’s not that simple. When you launch a program twice in a row on a modern computer, that’s never exactly the same starting state. So, if you ask your computer to do several things at the same time, it can choses, on its own, to launch the tasks in a different order every single time.

So what? Is that really a serious problem? Yes! When two players launch a RTS game, the world state isn’t sent by the network: it would take too long. Instead, we just send every player’s commands. Starting with exactly the same initial situation, and if we apply the exact same order, at the very same time, every players actions, we manage to keep exactly the same state, the same “reality” on every device.
But here it is, if one of the computer choses to execute the operations in a different order, the reality of every player will start to split, and that where the troubles start.

The first  versions of WinThatWar! were massively using parallelism to take part of the molticore modern processors. We quickly realised theses kinds of optimizations didn’t get on well with the network mode of the game. If you want to explore further, you can read this excellent article about Age Of Empire.

So, from now on, everytime we use multithreading, we have to make sure the operations order have no impact on the final result. And how to be really sure about that? Of course, we asking Tim for help! I told you that Tim plays WinThatWar! every night, at a rate of ten per night. That’s not all: it plays every game twice in a row, starting from the same seed and checking that every step of the world simulation is exactly in the same situation during both of the two games.

From now on, if you test a LAN pre-version of WinThatWar! with some of your mates, and if you suffer a crash, be curious and go get the log.txt file to watch it’s written on it. Now, you should know what that “Simulation out of sync!” message means. 😉

Etham

STUNFEST 2015, a little more indies?

 

Back from the Stunfest

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

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

bannière stunfest

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

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

Insane Unity team, after setting up.

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

3 days of WinThatWar!

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

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

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

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

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

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

Llewellys with Etham, Insane Unity CEO

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

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

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

More pictures on Facebook.

Insane Unity team, still a bit jet-lagged.

Alpha 0.3 is available

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

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

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

 

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

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

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

Have a nice weekend!

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

Shortcuts

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

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

FinalShortCut

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

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

Have a nice weekend.

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
Easy!

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.

Patiently…

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.

Philemon

If you want to learn more about baking:

http://wiki.polycount.com/wiki/Normal_map#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.

Wwise

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

And finally, here is a little video for you.

Physics!

Hi everyone!

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

Physics simulation, alright…but why?

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

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

Here is an overview of Insanity Physics functioning:

Insanity.Physics-Overview

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

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

Insanity.Physics.Collision-Overview

 

 

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

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

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

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

That’s it for today!

Doom

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.

 

 

 

 

 

 

Return top