Posts Tagged ‘Insanity’

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

Return top