Posts Tagged ‘STR’

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

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

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

XNA is dead… Long live SharpDX !

The rumor has been around for a while …. It is now official, XNA is dead, or soon will be, since it is to be retired on April 2014. Lots of regrets from indie game developers could be found on the net. “Those were the days !” … at least when it came to the high-level API in C# and its Content Pipeline system.

But do not worry, some solutions exist 😉 In our case, I chose to port to SharpDX, more specifically SharpDX toolkit, the high-level API based on DirectX 11. This API is yet not fully mature, but it is already efficient and has a very responsive community. Last time I had a problem, the author Alexandre Mutel provided me with a patch within the day.

It really is similar to XNA, but has the power of DirectX11, and is compatible with Windows 8 (including mobile version) and Visual Studio 2012. Of course it also works with older GPU classes : our new project WTW targets DirectX 10 cards.

The main drawback of SharpDX toolkit is the absence of the Content Pipeline. I solved the problem by using a custom MSBuild project and homemade MSBuild tasks to process the contents. I also use the lib Assimp for 3D models, and the effect compiler of SharpDX to process shaders. You can directly use DDS for the textures. As for the sounds, I don’t know, I haven’t searched yet: p

So basically, it means a little extra work, but it is worth the effort. Here is a screenshot of the new engine:

WTW_DX

Next : the video that fits, when the porting will be complete :)

Only fools never change their minds !

In these two posts, here and here, I spoke of my tests on the level of detail management when rendering terrain …

But first… Some time ago, Timous, our master of communication, scolded me on several of my articles, including an unpublished one (there seems to be censorship even here at IU :( ):

“Timous (to the wind): Tell me, Michel, your article on optimizing things, it is not bad …

Doom (very happy): Yeah?

Timous (glacial): But it’s just incomprehensible, you kidding me or what?

Doom (sheepishly): Um, bah it’s not that complicated …

Timous: There’s not even an intro, images are ugly, and my 11 years old little sister did not understand anything!

Doom: Bah this is an “Hardcore technical” article…

Timous: I don’t care, everybody must understand!”

So I will make some effort to introduce… this time 😛

In a 3D game, each image is calculated from a scene consisting of triangles. A graphics card can process and display a fixed number of triangles per second. The purpose of the management of level of detail (or LOD)  is to reduce the number of triangles to be processed in order to optimize the display time of each image (if it is not clear let me comment :D). In these two articles, I introduced the method of LOD that I had to use… Ultimately, I changed my mind and choose another method. This is what will remain, this time, in Robinson (is it a good for intro, Timmy?)

So I’ve implemented an algorithm called CDLOD for “Distance-Dependent Continuous Level of Detail Rendering for Heightmaps”, developed by a Filip Strugar. I’ll spare you the technical details that are very well explained by the author in this document… Here is a short demonstration video of my implementation for Robinson:

The more observant will have noticed the reduction in the number of triangle as they move away from the camera, and the progressive subdivision of the mesh. This algorithm is very fast and requires no pre-calculation, contrary to my initial algorithm. However, it has the disadvantage of ignoring the kind of terrain, resulting in a simplification of very poor quality on regular or geometric terrain. But as natural scenes are usually very irregular, this should not be a problem … Life is cool, does’nt it?

Planning of agile free-time work.

At the very time when we started the development of Robinson 2150 (the game-concept we were working on before Win That War!), planning issues arose. How to evaluate the development time for it (and thus the cost)? When our first demo will be ready? When will we announce it? and so on.

seeking the perfect planning tool

Alas, finding a planning tool well adapted to our way of working is a hard job.

First, the amount of time we spend in developing Robinson 2150 is hard to predict, as it relies on the amount of free-time we have (which varies according to professional workload, personal life constraints or leisure, etc.) That’s why usual project management tools won’t fit.

Second, we self-organize in an agile way, similar to the SCRUM method, but without formalizing sprints, nor having any Scrum Master or Product Owner. Each team member is responsible for a portion of product, the and we just hold a weekly progress meeting.

I tried ICEScrum, a perfect tool for SCRUM. I was convinced by its colorful post-it and the relevance of its indicators (sprint burn-down, release burn-up, etc.). It has unfortunately some problems for us:

  • It consumes too much RAM for our small dedicated server…
  • It is a bit slow
  • We do not do sprints!

I also tried a bunch of ticket-oriented tools like TRAC (with some SCRUM plugins) and JIRA (with greenhopper) but was not convinced. They lack ergonomy, they are difficult to use during a meeting, and above all, they do not give a sufficiently clear and synthetic vision of the project.

That’s why I decided to restart from scratch and design a tool that perfectly fits our needs!

So I implemented TODO, a very simple tool :

  • 800 lines of javascript (using jquery) ;
  • 150 lines of SQL ;
  • 100 lines of php.

The interface of TODO provides three views:

  • the backlog, which contains the tasks, grouped by functionality and sorted by priority ;
  • a table, to estimate the tasks in an agile-manner (i.e. relatively, using the Fibonacci sequence) ;
  • a chart, that summarizes the history of the work done, and presents forecasts for the tasks remaining in the backlog.

Well, a video is worth a thousand words:

Finally, we have a simple and ergonomic tool, which is easy to deploy on a server and easy to use during a meeting. Thanks to it, we already have a better insight of our planning.

Some features remain to implement, like undo/redo and real-time update with the actions of other users connected to the same server, but other subjects currently hold my attention (as the AI of Robinson 2150…) If I can found the time for that, I will place TODO on googlecode. You can still contact me if you want to try it!

RSS Feeds & Language Localisation

At last! A good news for all our French readers: language localization is available on Insane Unity!

You may already have noticed that, for few days now, little flags has appeared at the top right of the blog. You can now choose which language you want to read :

Language localisation with country flags on Insane Unity

Country flags for language selection

By default, the site tries to detect the country you are coming from and displays the contents using the right language. But sometimes not (it depends on your provider, your browser and maybe also according to the weather forecast.) In this case, the flags are here to sort the words in the right order :)

Moreover, the Blog and the Twitter have their own RSS feeds, which make you able to follow any of our twists and turns. To subscribe, click here for the English version of the RSS feed and here for the French one.

For the Twitter feed, click here (but is it really useful?).

However, there is no RSS feed for the RSS feed itself… but we are thinking hard about it! :)

Artificial Intelligence part 1: path-finding with collision avoidance

…and then I chose Flowfield

According to what I have found over the web, whenever you want to put a first step in game AI development, you have to start by A* algorithm.

Perhaps because I do not want to do like everybody, I preferred to try a different approach : the flowfield path-finding, as used in Supreme Commander 2. A good start is this very good paper.

Contrary to A* which implies that we have to compute the path of all agent separately, one interest of this approach is that the calculation is done only once. A cost field is globally computed over the map, from which the speed and direction of each agent are then deduced.

A wolf in the AI

For example, imagine a dozen of wolves attacking a poor, lonely, human. Every wolf has the same objective:  “bite the human”. The distance field to that human is common to all the wolves and can be computed once only per step. Other fields like density, comfort or threat can also be computed once for all. If there is more than one human on the map, the common target can become “bite the nearest human”, and so on we can also set high-level objectives.

In the next video,  you can see a round unit moving toward its objective (a square). The cost field to reach that target is in blue. The speed of the unit is computed based on field values in the surrounding squares.

In Robinson 2150, the terrain is about to be a very big and procedurally generated planet. That’s why the field is not computed over the whole map, but we stop as soon as every unit has been reached.

Now we have a bunch of units moving according to a field, we can add collision-enforcement and try a group-crossing simulation. In fact, crowd simulation can be seen as path-finding with moving obstacles. The first try was fun… Adding speed and density fields in the equation shown acceptable results :

At this point, our units know how to move towards an objective, but they still cannot choose this objective by themselves. This will be the next step of my work.

HDR rendering

Last week, I’ve worked on our home-made Insanity Engine and especially on HDR rendering. High Dynamic Range rendering simply refers to lighting computation in 4x floating point  (higher range) instead of the traditional 32bits RGBA format. In addition to be able to manage very bright and dark lights, HDRR enables to use a lots of secondary effects that make the rendering more realist.

The video below shows the famous Sponza Atrium test scene displayed with the current version of Insanity, showing tone mapping, luminance adaptation and bloom effect.

The result is not too bad on my HD5870, but I still have to work on performance for lower-end systems.

Return top