At some point on the development of KROMAIA, we realized that graphics were our main bottleneck when trying to use hundreds of objects. Not Ogre3D’s fault, the shaders we use are quite “expensive” (and even more with all the objects we want to use). At that moment, we were updating everything every frame, if the game was running at 100 frames per second (FPS), physics and graphics were updated 100 times a second. But graphics (shaders mainly) were spending most of that time (more than 60% of the total frame time).

Note we will try to specify a calling order with the following images, never real time scale between different blocks. Control frames, including physical calculations, take less than a 10% of the total graphic time.

The first solution we tried (single threaded) was to limit the number of graphic updates per second and let physics update at a higher framerate. We limited graphic updates to 60 times per second as we thought it should be enough, but controls and physics could clearly benefit from a higher update frequency.

We could need some synchronization to make this work. We need to update physics whenever possible and look whether it is time to update graphics. If we are on a graphics update frame, we update physics (as always), synchronize positions and orientations (for example) with graphics (with Ogre scene graph) and update graphics afterwards to render the current state.

This way, we update graphics at a fixed framerate and physics can be updated much more often.

This solution could be enough in some cases, but we wanted more. We supposed that the CPU was waiting for the GPU to finish rendering to start the next physic frame (and we were right according to our results after implementation).

The problem is even worse if you plan to use Vsync, the frame execution will be stopped on the graphic update until the next frame can be rendered, blocking the full game when it could be updating control and physics.

Take into account that the execution is not stopped at the point specified on the diagram, but we think it should be easier to understand in relation to the rest of the diagrams. Anyway the effective behaviour is somewhat equivalent.

MULTITHREADING

What are we looking for with multithreading?

This will happen with two processors or two cores, but with one core there are several improvements taking into account that, while rendering, the CPU is sleeping and, therefore, free for the control thread to use.

Vsync will work perfectly now, blocking just the graphics thread and leaving the control thread free to update the game logic as fast as possible.

So, which were the motivations we found to use multithreading?

• Graphics are the bottleneck
• Independent framerate between graphics and physics to make logic independent from graphics (and better yet: highest possible framerates for graphics and physics)
• Use of CPU while GPU is busy
• Use of more than one CPU on modern processors (just two with our current implementation)
• Vsync

If you have decided to give multithreading a try you will have to face some problems:

• Control thread can’t change graphics
• Graphic calls must be done from the graphics thread
• Delay graphic function calls when call is forbidden
• Synchronization between threads

Think carefully about all this before going ahead, it can imply a lot of work. Are you sure the performance gain will pay off?

IMPLEMENTATION

OK. Let’s talk briefly about our implementation:

• Graphic Manager
  We use a “GraphicManager” class as a wrapper of Ogre3D to hide Ogre3D calls to the rest of the game code. It is the responsible for the renderOneFrame function call and, because of that, where the multithreading implementation core exists.
  • If multithreading is disabled the graphic part will be created in the constructor of the GraphicManager class and the renderOneFrame function will be called when needed on update calls.
  • If multithreading is enabled, the constructor of the GraphicManager class will start a thread that will create the graphic part (graphics must be created on the thread that will render them) and loop forever waiting for its turn to start rendering calling renderOneFrame. The GraphicManager update function will not call renderOneFrame but notify the render thread of the next render starting time and will receive a message when the render has finished from the render thread (several control frames ahead, hopefully).

• Synchronization
  • Object synchronization
    Physics can be updated as fast as possible, but positions and orientations are not needed on the graphic part until a frame is going to be rendered. That is why the setPosition and setOrientation calls can be delayed until the graphic frame is reached. The same can be applied to scale and opacity. Remember that setting a position or orientation to any scene node is forbidden while there is a render in progress.
  • Delayed functions
    There are some calls that will be “asynchronous” with the graphic part, that is, won’t be made always on a graphics update, but will need to call to a graphics function. But calling some graphics functions is possible only if there is no render in progress, so you have two options: you can stop the thread calling to the graphic function until the render has finished, or you can add the function call to a queue of “pending function calls” with its parameters and continue executing. The first solution is easy, thread synchronization, but breaks the multithreading we have constructed; if that function calls happen quite often we will end with a multithreading implementation that behaves like a single threaded application. The second solution is not very complex: “store functions and their parameters and call them whenever possible in the same order the functions where queued” but you have to take into account that the function call can be delayed several control frames ahead, and “not calling” that function can have consequences you will have to foresee. For example, we delay the createEntity function, that means that when you create a new object in a control frame (imagine you fire a projectile) the graphic entity won’t be created until a graphic frame is reached, but the object can move, collide (projectile impact) or disappear (or explode); all that behaviours must have a sense even without the entity being ready (think of material changes or fading).
    Functions we are delaying include: entity creation, material functions, adding/removing child nodes and destroying billboardChains/ribbonTrails. There will be much more depending on what you use and how you use it. Oh, one more thing, we call every delayed function at the start of a graphic frame to get everything ready for the next update calls and avoid more delayed function calls along that frame.

• MessagePump
  After our first implementation we faced some problems with messages from the operating system (Windows). We couldn’t fix the problem ourselves as we didn’t know what was happening so we went to the Ogre Forums (LINK). As Xavier pointed out, the problem was the call to messagePump being done on the control thread instead of the graphics thread. Anyway, after several tests we found out that our game behaves better calling messagePump both, from the graphics thread AND the control thread, so it is being called from both threads from then without any problems (yet). We don’t have much to explain here, but accept suggestions.

ALLOWED OR FORBIDDEN?

There are some things we know you shouldn’t do while the renderOneFrame function is working (of course there should be much more forbidden functions, and even more depending on how, or when, you call some functions, use this just as an example of what kind of things you should avoid):

• Destroying nodes or changing parent or child nodes results in a crash. It seems not to happen when creating nodes, but we wouldn’t recommend creating a new node while there is a render in progress.
• Attach to / detach from root node. Don’t do this.
• CreateBillboardChain/destroyBillboardChain, createRibbonTrail/destroyRibbonTrail. The same than nodes.
• Changing position, orientation or scale of a scene node could crash or create other strange problems. We have no further information on that.
• Creating entities seems not to crash, but we had lots of trouble with creating/cloning materials for the entities we wanted to create. We decided to delay complete entity creation as it was just as complex for us to delay creating materials than to delay creating entities.
• Changing materials is not recommended. We are not sure if this is a direct cause for a crash, but there were some strange problems because of this.

Of course sync with the render thread before destroying the graphic part of your game. You can destroy things from the control thread, but make sure there is no render in progress.

We hope this description helps you understand what we have done and why. Feel free to ask whatever you like. We will update the post with your suggestions and questions. You can comment on the Ogre3D forums (http://www.ogre3d.org/forums/viewtopic.php?f=5&t=68155) or contact us through e-mail (contact@krakenempire.com) if you want too.

We are very happy with the two nominations we have received to date in opposite parts of the world:
http://www.freeplay.net.au/2011/08/freeplay-awards-2011-finalists/
http://bit.ly/qu9pSB
We are doing our best in hope that it will get even better. Thank you for your support!

KROMAIA is improving fast. We have almost finished the engine programming already and we are currently working hard to improve gameplay and build enemies and levels. There is a lot of work on the way to the final release, but we are on track.

Take a look at our newest video. You will find some elements we haven’t showed before, like special weapons, and graphical improvements, such as depth of field. Thanks for reading, and stay tuned.

Kraken Empire is composed by only 2 members. We wanted to make games no one had played before. A new and hopefully better gameplay in some way. We are best at programming, so our game would be based on programming and procedural generation. We needed to avoid complex modelling and animations as no one would have enough time for them. A game with vehicles in a space environment was something we could afford. We wouldn’t make the next AAA space game, but we could add something new to space games: real physics.

The first improvement to be done in a space game using physics are spaceship controls. Using physics, ships can be moved however we want with all the smoothness the physic engine provides. Of course the engine won’t do all the work for us, we will need to apply discretization and numerical integration. The forces to apply are integrated along time and applied through the physical engine. We use objects that we call propellers that apply forces to the object they are attached to, according to their own power curve and integrate the values along time to be used by the physical engine. The same is used for enemies and friction when needed.

At the beginning we didn’t know how it would work when finished, but the results are even better than expected. The smoothness we have reached is something we haven’t seen before and it is even more evident if you play other space games after playing KROMAIA. Our universe feels completely coherent because every object is physically modelled. As a result the game is really immersive as we were expecting from a game without interface that takes place in an extremely solid and coherent world.

Using physics is the only way to implement complex physic interactions. Making a black hole is not difficult by itself, but when you plan a battle between different enemies firing hundreds of projectiles and colliding with asteroids while all of them are attracted by the black hole… you can’t just implement every interaction by hand and hope the best. You need physics to make it believable.

Of course, it is not the way to go for everyone and every game nowadays. We wouldn’t recommend it for indies either, unless you want to make a new control as we have done. But physics should be used seriously in every game sooner or later, since it is the only way to make coherent worlds and responsive controls as we see them.

Kromaia will be your best chance to experiment with black holes from the safety of your seat.

Take a first look to black holes in Kromaia and what they are capable of…

Highlights:

• Notice every object in the video is attracted by the black hole including 400 asteroids and every enemy and projectile fired.
• Objects contacted by the black hole explode generating a shockwave that affects every other objects in range.
• 0:30 Observe how projectiles, after colliding with the column, are attracted by the black hole.
• 0:49 An enemy crashes with the black hole and is instantly destroyed.
• 1:32 and 1:48 Admire how projectiles orbit the black hole shortly after being fired.

This version is about  20 minutes long (with a 20MB download) and features a couple of bosses and three play modes. The current gameplay and bosses are not close to a final version, but the game is quite playable at this stage (or at least we think so ).

We would like to keep this control demo private by selecting some players with experience in different game genres. We will release a public demo in a near future with the improvements suggested by our first volunteers.

All we will ask from you is to try our game and tell us what do you think about controlling your ship with keyboard, mouse or joystick (whatever you use). The game is quite hard, so don’t worry if you die or if you can’t make it to the end. Remember it is just a control demo.

If you are interested in trying KROMAIA, please send us an e-mail to request@krakenempire.com, telling us why do you want to play our game and what “similar” titles you have played.

We will accept requests until the end of November. Contact us if you want to try KROMAIA now!

Thanks in advance.

P.S. The current version is Windows-only, sorry.

We are currently studying  several control schemes… A demo including the best ones will be ready soon!

The next question that could be asked is: “How do you move the player’s spaceship?” Well… again the answer is… applying physical forces. Although the detailed answer involves what we call “propellers”.

Propellers, when turned on, apply forces to the player’s spaceship in the position they are located and along a fixed direction. Propellers are represented using “broken rings” and the amount of force applied is proportional to the angular velocity of the ring.

Why all that information right now? So that you can understand our new video. Look carefully to see the propellers and which ones are turned on for each movement shown in the clip.

How can all that propellers be useful for KROMAIA? We like to think that we have the smoothest control you have ever seen. Hopefully you can see it in the video but you will have to try our demo to know if it is really true (we are planning to release a demo in October, be patient).

Just a final note regarding the modding capabilities we promised. It is not a part of the gameplay, just a customisation feature by now. But imagine that all that propellers define their characteristics in a data file (position, direction, power, acceleration, deceleration…) and you can activate one or several propellers with any key… What control scheme would you prefer to pilot your ship? Maybe it is the first time you will be able to customise how your vehicle moves in a videogame with six degrees of freedom.

KROMAIA is a 3D, fully physics based experimental action game, placed in a strange and hostile universe governed by rules to be discovered by the player. This immersive experience, in which traditional interface elements as well as text do not exist anymore, goes beyond the space shooter genre boundaries and sets a new standard: Spatial and physical awareness, insight, tactic and reflexes in exchange for survival.