Balancing Act

Over the last couple of weeks I've been designing and modelling a set of 3D structures to use as the alien interiors.  I wanted them to be consistent, sci-fi looking but also slightly alien rather than appearing like they were something a human would construct.  I'm getting there but my inspiration is limited somewhat by my technical and artistic ability.

Being consistent they can all share a very few number of textures.  This has the great advantage that if they are created as one model it only needs one draw call to the graphics card to display them.  The Xbox 360 can handle huge numbers of triangles but gets much slower if it needs to make loads of draw calls.

I got a bit too carried away trying to get the minimum number of draw calls...

After having returned from the Olympic 3 Day Eventing final on Tuesday I started work on laying out another section of what will become the first level of the game.

Olympics
My wife is the horsey person which is why when the chance to get tickets to the 3 Day Eventing came up we took it.  It was a good day with a fantastic atmosphere.  Team GB got a silver medal.  The stands shook with excitement.  I was very impressed with how the whole thing was organised.  There were lots of people but still everything flowed, we quickly passed through security in to the grounds of Greenwish Park and to our seats. 

The view from the stands was perfect and even with the few minutes of rain we had from time to time the brollies did not block the view.

My wife has some pictures and more info. on her blog:
http://tomandhenry.blogspot.co.uk/2012/08/greenwich-park-equestrian-eventing.html

I use Blender to create sections of the level and then import them in to the game and move them in to their final position using my own editor.
http://blog.diabolicalgame.co.uk/search/label/Editor


I've had to redo a lot of the work I did in Blender on Tuesday night.  Perhaps the excitement of the day got to me!

I had joined all the models together too early on and moved vertices in Blender to layout a large sections of the level.  I did this with the intention of making the draw calls more efficient but that was a mistake.  The single model is now too complex to separate and adjust sections and I had forgotten to allow for shadowing!

The Diabolical engine does not self-shadow.  This is where the triangles of a single model cast shadows on to other triangles in the same model.  I have other posts on the unsightly effects caused by self-shadowing so I won't repeat that here:
http://blog.diabolicalgame.co.uk/search/label/Shadows

3D Modelling for the Best Game Performance
Keep all models as separate component Objects so they can easily be picked up and moved about while laying out.  Combine them [Ctrl-J in Blender Object mode] at the last minute in to a smaller number of meshes that use the same texture to reduce the number of draw calls required by the game engine.

Remember to keep a copy of the source model file before the Objects are merged to make future adjustments easier.

3D Model Meshes
There is no advantage combining Objects that use different textures.  Each material will automaticaly separate to another mesh in the exported file because typically shader effect files only use one diffuse texture.

3D Modelling for Shadows
In the current Diabolical engine there is no self shadowing and this may apply to other engines.  When combining the Objects look at which Objects might cast shadows on other objects and make them separate models.

For my game engine I need to balance the performance gain from having less draw calls for the Xbox 360 against the visual quality of having shadows cast correctly on to more surfaces.

Diabolical Editor

I noticed the other day that I had not mentioned much about the level editor that I use for Diabolical: The Shooter.  I've spent a lot of time adding features to it so I thought it worth describing.

The editor is used for shaping and colouring the terrain and for positioning the static models on to the map.  With hindsight I should have created a completely separate application but my original design was to be able to quickly play test any level I created so the Editor uses much of the same code as the game and is run from the game's main menu.

That works but there has been a lot of struggling to keep the game code tidy whilst also adding in the Editor methods.  This has resulted in a lot compiler directives of the type '#if EDITOR'.

To be able to use Windows menus I have had to do some messing about.  The WinForm menus are not fully supported in the XNA game loop.  I have an open source test project that shows how I have managed to get the menus to work with some limitations:
http://code.google.com/p/xna-game-menu/

The top level menus and the drop downs have to be coded by hand but they can launch forms created with the Visual Studio GUI.  The menus work fine for the Editor used only by me but I would never use the WinForm menus in an XNA game.

Over time I have added stacks of features, too many to list but just a few are: texture terrain with up to four layers, adjust the height of the terrain with various helpers such as flatten, noise, slope etc.  use a round cursor, a rectangular cursor, add structures, waypoints, triggers, static particle and sound effects and so on...

The whole terrain is based on a height map using a regular grid.  This makes finding heights relatively quick.  The grid only has one value, the height at each corner.  The limitation of this is that it cannot do vertical faces only slopes.  For the vertical cliff faces seen in some of these screen shots I have created 3D models.

To position the cursor I project a line from the view and calculate where it intersects the terrain.  At first the cursor always followed the view but I found this difficult to see what I was doing so now the cursor stays still unless I hold down the Ctrl key.

I am not sure if my method for finding the point on the terrain to position the cursor is efficient but it is fine for this editor.  I step along the line projected from the view, testing the height at each point.  The step being just under one grid width to ensure every grid is tested.  As soon as the end point of the line goes underground I know that somewhere between the last step and this step it intersects with the ground.  I then back step in smaller and smaller segments to get a nearly accurate point of impact.  I only need to know which grid I'm in.

I use the top left corner of the grid in which the line intersects the terrain as the centre position of the cursor.  For some modes I offset this by half a grid in others I stay with the corner point.

I can size the terrain cursor using a simple popup form.  Whatever action I carry out is done for every point under the cursor.  The positions are all easily calculated using simple maths.

The terrain cursor and the many helper shapes I draw are just simple lines drawn in 3D space.  The cursor samples the terrain height at the ends of each line and sets the heights a fraction above the terrain.  This means the cursor follows the contours of the terrain.

There has been a lot of work over the years getting to this stage with many features I have not mentioned yet.  If I knew then what I know now I would probably use an existing editor and spend the time writing an importer rather than adding all these features to my editor.  Having said that, I've learnt a lot and I do enjoy knowing that I did all this.

To complete the picture, this is a list of all the features of the game engine:

• Walk round a 3D world
• - first person controls
• - over the shoulder view of yourself (more fiddly than it sounds)
• - resolution 1024x576 (for better performance on the Xbox 360)
• - jump
• - spectate
• - two player split screen
• Animated
• - blend animations
• - merge in arm movement to follow which way the player is looking
• - hold attachments that move with whatever they are attached to
• - shared animation files (and a way to get them in to the pipeline.)
• Physics
• - collide with characters and structures
• - projectile impacts
• - projectile trajectories (thrown grenades)
• Terrain and game editor (development only)
• - change heights
• - change textures
• Add and remove (only in the development editor):
• - models
• - triggers
• - particle effects
• - goals
• - trigger goal success
• - trigger add a new goal
• - trigger spawn player
• - trigger spawn non-players
• - trigger particle effects
• - waypoints for AI pathfinding
• - spawnpoints
• - weapon or equipment pickups
• Lighting
• - single shadow casting light
• - three effect lights
• - shadows (not a trivial task, many many months spent on this)
• Full menu system
• - select which map to play
• - customise the player character with hats etc.
• - load and save character choices
• - change music and effect volumes
• - in game pause menu, resume or exit
• - display goals outstanding and completed
• Combat system
• - select weapons
• - shoot weapons
• - throw grenades
• - melee (elbow bash while holding a gun)
• - projectile trails
• - impact damage decals (instanced)
• - impact effects, debris and smoke
• - explosions
• - muzzle flash
• - sound effects
• - drop weapons
• - pickup weapons
• - pickup ammunition
• Head Up Display (HUD)
• - weapon sights
• - sniper sights
• - zoom in
• - display ammo as used
• - compass
• - radar showing friend and enemy positions if close
• Non-Player Artificial Intelligence (AI)
• - pathfinding (A* using navigation rooms)
• - select a target if in range
• - shoot at a target
• - move to better cover to shoot from
• and I'm sure there's more...

Bots Can Walk Up Stairs

I got a bit excited today when a Bot walked up stairs and back down again.  I had not attempted to force the AI controlled Bot to do this.

This was a scenario I needed to test with my new collision model but the Bot did it on its own :-)

A few weeks ago I identified that my previous design was not detailed enough to allow the characters to walk through doorways cleanly and completely failed if that doorway also included steps or was already on top of a structure.

For the last three weeks I have been coding and testing an improved version.  Physics engines are surprisingly difficult.  It should just be a bit of maths but the complex tiny reactions regularly produce unexpected and frustrating results.  I got there in the end.

New Design

Instead of sharing collision bounds with the projectile impact code, the new movement system relies on a separate pre-calculated detailed grid.  This acts like a height map just for the areas of the map that contain structures.  If there are no structures the player must be standing on the less detailed terrain.

I like the feel of the typical sliding sphere response but I was trying to avoid having to create, store and load oriented bounding boxes (OBB) for every structure.  This needed some thinking about.  The goal was to be able to give a reasonable collision response with the minimum of data needing to be loaded by the Xbox.  File loading on the Xbox is relatively slow and most games take a long time to load their levels.  This is inevitable but with careful design I can minimise it.

I like the use of grids because it only needs a very quick bit of maths to determine which grid any location falls in to.  The new design stores only three bits of information in those grids and only stores it where it is not the default.

I automatically calculate the highest point of any structure in each grid square.  I can then manually set an additional floor level and clearance height for any building that can be walked through.  This only needs to be where the structure has a solid ceiling.

Interior scenes will have ceilings that do not collide so the floors in these areas will calculate automatically.  It only tends to be doorways that have to be done manually.  I spent much of the last few weeks trying to automate this calculation but the results were never robust enough.  Either they collided where they should not or worse they allowed a character to fall through a floor!

In-game it is fairly quick to calculate the slope between where the character currently is and the most appropriate floor in the grid they are moving to.  If it is too steep then the entity cannot move there.

The design took a bit of tweaking to make sure that all edge cases were accounted for with the minimum of calculations but after a lot of frustration the end result has been performing well.

Artificial Intelligence (AI)

I gained some advantages from the new pre-calculations which are used to speed up the generation of the navigation mesh used for the AI.  The most notable is that the cover height is automatically available to me rather than the long calculation I had to do previously.

I was also able to create a much more reliable test to check if any path could be walked by a Bot.  This now matches the results that the entity gets when moving so there is much less chance of getting stuck and most importantly it checks the floor level.   This is what allowed an AI controlled entity to finally walk up the stairs and through doorways.

:-)

What Can My Game Already Do

An article by Nick Gravelyn over on his blog inspired me to think about what I have done.  Theirs shows a screen shot of what a team of three achieved on their game engine in 6 months.

I've been working on mine for over two years on my own and I'm pleased to say my game can already do a lot, in fact code wise there can't be much more to add.  I hope!

This list of features is a reminder to me of what I have achieved:

• Walk round a 3D world
• - Jump
• - Spectate
• First person controls
• Over the shoulder view of yourself (more fiddly than it sounds)
• Animated
• - Blend animations
• - Merge in arm movement to follow which way the player is looking
• - Hold attachments that move with whatever they are attached to
• - Shared animation files (and a way to get them in to the pipeline.)
• Collide with characters and structures
• Terrain and game editor
• - Change heights
• - Change textures
• Add and remove:
• - models
• - triggers
• - particle effects
• - goals
• - trigger goal success
• - trigger add a new goal
• - trigger spawn player
• - trigger spawn non-players
• - trigger particle effects
• - Waypoints for AI pathfinding
• - Spawnpoints
• Lighting
• Shadows (not a trivial task, many many months spent on this)
• Full menu system
• - Select which map to play
• - Customise the player character with hats etc.
• - Load and save character choices
• - Change music and effect volumes
• - In game pause menu, resume or exit
• - Display goals outstanding and completed
• Select weapons
• Shoot weapons
• Bullet trails
• Bullet impact decals (instanced)
• Bullet impact effect, debris and smoke
• Muzzle flash
• Most things have sound effects
• Drop weapons
• Pickup weapons
• Pickup ammunition
• Head Up Display (HUD)
• - Weapon sights
• - Sniper sights
• - Zoom in
• - Display ammo as used
• - Compass
• - Radar showing friend and enemy positions if close
• Non-Player AI
• - Pathfinding
• - Select a target if in range
• - Follow a player (target)
• and I'm sure there's more...

All the in game stuff runs on the Xbox with a development version running on the PC as well.

In addition to all that I had to write a Python script for Blender to be able to export models from Blender to XNA and as a short distraction I am currently trying to unify that with the built in FBX exported in Blender so that in future one exporter works with everything!

I'm still a long way from finishing the game though.  That is because most of the above use placeholder graphics and so I am now working to create the finished 3D models to go in the game.  Then I will post a video to really show off :-)

I'd like to thank all those people on various forums that have helped along the way.

First Images

Originally posted: 23 Feb.2010

These are the first images of the engine in development.





Please do not judge it yet. This is not even alpha code. I've been working on this in my spare time since March 2009. That's when I started with XNA and very shortly after had to learn a little bit of Blender to get some models in to a scene. The XNA dude shown in the screenshots is not the original from the skinning sample.
It is a duplicate transfered to Blender so I could add additional animations.



The first area I tackled was shadows however that took a lot longer than I expected. The shadows are still not finished.



The terrain editor is a very recent addition which only took a few days to complete.