Posts Tagged ‘independant’

Win That War! Early Access opens today!

Hello everyone.

 

Win That War! Early Access will be released today, 7th April at 5 P.M UTC
Visit the Steam page here: http://steamcommunity.com/app/599040

The whole team has been impatiently waiting for this moment. Ever since we laid the first bricks of our engine, three years ago, the team has grown, the gamedesign and visual aspect of the game have been entirely reworked, and the MMO campaign, the core of Win That War!, has come to life.

Today, all of this will become a reality. We’re all looking forward to you playing Win That War!

To help you get the hang of the game, we created two documents, which are hosted online on Steam, but seem a bit hard to find.

To make things easier for you, here are:

We are waiting for all of you. And may the best strategists win!

Win That War title

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

startenginemarque

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.

stopenginemarque

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

artilleryloop-sequencewwisemarque

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

artillerylandmarque

The « ArtilleryLand » event plays the Artillery landing sequence.

Wwise sequence

artilleryland-sequencewwisemarque

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

artillerydeploymentmarque

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

artillerydeployment-sequencewwisemarque

 

 

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

artilleryshootmarque

Wwise sequence

artilleryshoot-sequencewwisemarque

 

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

artillerytakeoffmarque

Wwise sequence

artillerytakeoff-sequencewwisemarque

 

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:

 

Win That War! is on Steam Greenlight.

The Greenlight is now officially launched, and is only waiting for your votes!

We’re counting on you, not only to show your interest by offering us some green thumbs, but also to spread  the word of the Greenlight on your Steam community. Having Win That War! available on Steam is up to you now.

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:

dislocation

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.

I love splines!

 

A curve

In Mathematics, a Spline is a numeric Function that is Piecewise-defined by Polynomial function, and which possesses a high degree of smoothness at the places where the polynomial pieces connect (which are known as knots)“. Thank you dear Wikipedia, I couldn’t have said it better myself.

“But, what link can there possibly be between Splines and Polygons?” you may ask yourself. And that’s a legitimate question, since I usually write about polygons and cake (made from polygons too).

Well, you have to know you can actually create 3D models by using these famous splines. That’s right!

A basic spline

As you may know, I mainly use 3DS Max to model my vehicles, buildings, etc. 3DS  taught me to use the word “spline” to define a 3D Bezier curve when it comes to design.

Actually, It’s a commonly used technique in automotive design. Seeing as I mostly model vehicles, it makes perfect sense for me to be working with curves.

However, I apologize in advance, because somehow, I have the feeling this post will feel like a tutorial.

The 3DS Max “Lathe” tool works just like an actual shaping tool and allows to easily sculpt an object  with a very smooth shape.
So, as an example, I’ve made a pretty bowl for you:

The process to use Lathe modifier.

I’ve got another little trick for you : You also can do what is called a “Sweep”. This is actually a  standard shape that you’ll select and with which you’ll “sweep” the previously drawn curve.  The shape is then multiplied to create the desired object.
Here is another example for you, and be prepared, I went a bit crazy and I’m now modeling…a mug!

The process to use Sweep modifier.

Anyway, now that you see how it works, let’s get serious and I’ll show you how you can apply it to your 3D modeling.

Once, in my student days, I was looking for a tool to model by using Splines, and I finally found a tool called SURFACE. At the beginning, Surface was a third party plugin, then Kinetix eventually bought the licence and included the tool in 3DS Max 3.0. I don’t know who this third-party is, but I owe him a big “thanks”.

Digging through my archives, I found the following model. That’s what it looked like the first time I tried to use this tool, based on three pieces of circles intersecting with each other.

The use of a Surface modifier

How did the software turn this into that? I don’t have a clue. Voodoo magic?
Well, and so… how do you put this technique into practice? Among other things, you can  use these tricks to model a vehicle. An airplane, for example.

Use of spline in modeling

It can also be used for specific organic creations.
Like for this wonderful purple…marshmallow.
I could probably have made something sexier, but you get the idea.

Chantilly

In short, I love modeling using Splines . The tool “Surface modifier ” is probably my favorite, it’s part of the workflow for all my vehicles .

I also think it’s a good starting point to model an object with a lot of rounded surfaces .

However , be aware that Splines, alone, are difficult to comprehend in 3D for our poor humanoid eyes that can’t decide whether a form is curved or hollow. So we will have to get used to the tool and rotate around your model, regularly move the camera angle to visualize the form , and then use the Surface modifier.

If you’re not using this technique already, I can only recommend you try it asap!

Cheers

Philemon

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!

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.

Procedural generation & P2P

Network, network aaaand network… yeah, I’m working on multi over Internet mod for some months now. But here it is, today I decided to take a rest and write a post about the backstage, for you!


p2p

RTS & Lock-stepping

In a multiplayer game, we use the network to synchronize the world’s state on all the computers. Every player has then the same representation of the map than the others. Following the example of all known RTS,  WinThatWar! network layer is based on an algorithm called lock-stepping.

The classical approach (in FPS for instance), is to synchronize the internal representation of every items of the game by relaying, via the network, the changes bring to the other players. In a RTS, we can get to hundreds, even thousands of items to synchronize at the same time. So, you would probably understand that’s not possible to send, 5 time a second, the exact location of every unit of the map to every player in the game. However, even the most frenzied korean Starcrafter doesn’t exceed more than 5 commands by second, so that’s 300 APM (actions per minute)… Ok that’s not so bad.

To simplify, the lock-stepping will “cut” the game in 200ms turns. During that turn, we’ll record all the controls of the player: selection, moving orders, attack orders… At the end of the turn, theses controls will be send to all the other players while you’re waiting for their own. After a period of time, all the players finally get the list of  all the controls for this turn. This list is delivered to the game-logic (AI, Gfx, etc.) that will execute them (the controls). Then, the next turn begins. If the game-logic is determinist, which means it will always get to the same result for a given list of controls, the World state is exactly the same for every player. It’s called “Synchronous simulations”.

In facts, that’s a bit more complicated: we mask the network latency by simulating a n -1 turn, so we give time to the next turn controls to arrive before the end of the current turn simulation. Are you still following me? Anyway, in the case of games over Internet, we just make sure that these turns length of time vary depending on the players’ computers and network capacities.

This paper, wrote by Age of Empires creators, describe this principle very well.

At the end, the network part is quite simple. The true difficulty resides in the game-logic determinism. For a given list of controls, all the computers have to end in the exact same result.

Procedural generator & GPU

In the case of WTW, we chose to use procedural generation to produce our maps. We’ve actually got a tool that allows us to define varied maps styles, then our generator is able to create an infinity of variants of them. Well, we have to confess that’s still a bit experimental now, but we’re working on it!

For the sake of performance, the maps relief (heightmap) is generated by the graphics card with the help of Pixel Shader, at the very beginning of the match. That’s quick, and efficient.

Problem is there’s still some negligible differences between what results of two graphics cards made by a different constructor or so. Usually, it really is a tiny variation, in the range of 10e -5 or 10e -6 maybe (0,00.001 and 0,000.001 if you prefer). But here it is, that causes troubles in the synchronous simulations. For example, at Player 1’s, a tank could perfectly shoot the target, but at Player 2’s, the tank seems a bit upper on the map, and it can’t shoot. In short, that’s not synchronous anymore. And we do not like it this way.

P2P transfer & ECC

I the way to fix this problem, in LAN mode, the host was sending his own heightmap to all the player. This way, we ensured there was no display difference. But we can’t use this method  concerning the multiplayer over Internet mode. Our largest maps heightmaps is around 400Ko heavy. In the case of a 8 players game, the host would have to transfer 7x400Ko of data, knowing our Network technology is P2P based, and if, like me, you didn’t have choice and subscribed to an ADSL which don’t allow you to upload more than 100ko/s… it would take you 28 seconds just to transfer the map. And we all now, here, how these seconds can seem lengthy when you wait a game to be launch.

So, this is roughly how it works at Insane Unity: If 8 players join the game, the map is “cut” in 8 parts, and every player send his own eighth to the 7 others. So one player will upload only 350Ko (7x50Ko), which means 3.5s sending time.

Actually, the map is “cut” to be as efficient as possible for the processor cache, but in any case, it doesn’t change anything of the 8 parts things, since every player will send more or less the same volume of data.

Engine

The heightmap in Yellow, the cutting in Red.

But wait for it… that’s not the best!

I think that ECC (Error Correction Codes) are one of the most magical thing of informatics. The principle is to use an abstruse mathematical process: For one data bloc, a “parity” bloc is reckoned. The whole (data + parity) is relayed, then through a second abstruse process, we can firstly check that none of the data are damaged, and then fix the potential errors. Reed-Solomon codes (RS) might be the most used: CD, DVD, Blu-Ray… it even works when it’s scratched. And, if as mine, your ADSL is a 2,5km long interferences antenna, I think you might be happy that your residential gateway or router fix some of the errors.

reed_solomon_code_word

RS bloc coding, n = total weight, k = playload (useful data), and 2t = parity. Through a 2t parity, you can fix up to t errors.

Well, let’s get back to our map. The heightmaps are almost the same for all the players. So, I’m using the RS to calculate a parity bloc, and that’s what players are exchanging through the Network. Then everyone can apply the error correction, and that’s how all the players will finally can have a perfectly identical map. Oh yeah, I almost forgot, parity bloc is obviously smaller than data bloc but you probably noticed that already. In our case, it’s RS(223,255), being 32 octets parity and 223 octets of data. Let me do the calculation for you: Now, the players just have to upload  50Ko each thanks to this method, which means an half a second transfer.  And that’s what we like!

So, that’s my daily life at Insane Unity. Hope you enjoyed this post.

Doom

Roadmap little changes

Hi people!

It’s been a long time I haven’t wrote anything on this blog. That’s why I take advantage of this post-return of summer holidays break to bring you some general news.

From movie the mummy found on tumblr

So! Insane Unity is doing well. Doom is still working on his network stack (which has quite progressed), and Philemon get back to a concept arts phase (which are also in a good way). Also… our two trainees abandoned us last week (sob).

Anyway, we’re still looking for financing and that takes a lot of time, but we’re doing our best to stick to our roadmap at the same time. And as you’ll see below, that was not as effective as we expected. Let’s see what we forecast for September:

  • HUD (tactical information)
  • Tutorial
  • Multiplayer over the Internet
  • Gameplay-guided music

Hum. Well, the HUD is functional, as you may already know if you receive our newsletter, but we’re waiting for Philemon to find a moment to draw some pretty strategy icons miniatures before we let you test it.

About the tutorial, we’re waiting to finish fixing every single interface issues. But, here is the point: Since I had loads of administrative tasks to handle these months, I barely made progress on the interface. Maybe I should buy a tie (just kidding). Even though, I found some times to work on the AI, and that’s the good news. Be patient, I’ll wrote a  post about that later.

Multiplayer over the Internet mode is working! Here is another good news, right? At least, one of us is doing his job, here: Doom. The connecting time between two players is just melting like an icecube on the top of an uranium battery, and the stack is getting stronger and  more and more efficient. Maybe Doom will also write a post about this in a couple weeks.

Last but not least, about the gameplay-guided music, we just have to integrate in the engine the loops CiD produced on Wwise.

I think I’ve nothing else to add. I just wanted to be honest with you and confess my mea culpa before sneakily going to modify the roadmap on WinThatWar! website.

Bye everyone, and thanks again for all your support.

Etham

the decal system part 2

You missed the part 1? Keep calm and click here.

Long distance decals

The problem with the artillery in the game is that you don’t have a clear idea of its possibilities. For example, you’d like to park it behind a mountain and target the enemy base, forcing him to bypass the relief and loose a precious time. However, since it is impossible to have the base and your artillery in the same screen, you cannot know how your artillery would react to such an order. In fact, if not at range, it will move right into the enemy base and be destroyed. The point is, when you start thinking strategically and not just a-clicking the enemy, you need critical information, such as the range of a unit.

Now technically, how should we do it ? We could make a decal from a texture, as we did with the selection circle, but that would be a really large area, mostly empty, so it may not be the best option. What we can do, is using the GPU to render vector art on the screen. I’ll explain it later, but if you want to know more about it you can check this chapter from GPU Gems 3 : http://http.developer.nvidia.com/GPUGems3/gpugems3_ch25.html.

But, what is a vector art?

The most common way to consider an image on a computer is basically with a table of colours. When you create an image you have to define its size, which is the number of pixels it contains, and each one of these pixels will have a colour. So all you have to write in the file are the colours of the pixels in the right order, and the GPU will be able to print the image whenever you need it. However, this induces a small problem when it comes to scaling the image.

Picture yourself in a FPS, and in front of you is a brick wall. You are a few meters away from the wall, and can admire the beautiful brick texture the graphic designer created. However, as you get closer, this texture takes a bigger part of your screen, since it is larger, in pixels, than its original size. At this point the details of the texture are less accurate since the colour of a pixel is extended to 5 or 6 adjacent pixels. We could increase the size of the texture, but then the file would be two times bigger, and we want to avoid a heavy file that will take longer to load.


briques

The classic way to overcome this difficulty is vector art, used in the svg format that we need for large decals, such as ranges. The idea is to save a description of the image that doesn’t depend on its size in pixels. To do that we rather consider the curves that form the image, as “paths”. Each path is a command, a set of points, plus a colour and various options about fill, or stroke, or whatever you need, defined in the svg standard. But it will be easier with an example.

Please, draw me a triangle

Let’s make a simple triangle : all we have to do is draw three lines, with each end being the beginning of the next one. For instance,

M 0 0 L 0 100 L 100 0 Z.

This is what a path looks like, a set of letters that are commands to indicate a certain shape to draw. The numbers after it are the coordinates that describe this shape. M means “Move” the current point to this position. It represents the start of the shape, as if it was the position of a virtual mouse. Here we position this cursor in (0,0). L is the command for “Lineto”, that draws a line from the current point to the arguments. At this point we drew a line from (0,0) to (0,100) then from (0,100) to (100,0). Z is the command that closes the shape, by drawing a line to the start point. In this example the line joins (100,0) and (0,0).

triangle

We now have a triangle between the points (0,0), (0,100) and (100,0). We can add options like “fill: black” if we want to fill the shape in black, but basically that is how svg files work.

This way, we can always adapt the shape to how large our image appears on the screen, and then avoid the problem of resolution, but of course complex images can induce a lot of paths, so it is better to save it for something schematic, with only simple shapes.

Other commands (Q, C, A) are used to draw the Bezier curves that we will need for the large decals, and are a little more complex, as you will see in the next part. Yes, there will be a part 3! Wait for it.

Return top