Friday 4 March 2011

Improved particle effects.

Some upgrades to the particle effects.  Since this enemy type is organic, being damaged now causes them to emit blobby green chunks of matter behind them.
I'm going to have to see if I can actually make some decent videos of the game engine in action: screenshots don't really do it much justice.

More web presence!

After a very drunken conversation last night, I have moved on buying the appropriate domains and so http://www.brainwormsoftware.co.uk and http://www.brainwormsoftware.com are now mine for 2 years for the princely sum of £27. 

There's bugger all on them at the moment, but shortly they will redirect to this blog, and then in a while to a proper webpage.

Wait, Tengu has noticed that I've stopped working.

A new addition to the team.

My new line manager Tengu has finally arrived.  He sits on the top of my desk and lipsyncs to BBC News Live and Last.fm, and gives helpful ideas for my game in a voice that sounds like a slightly more evil version of my own.

He also tells me to kill the whores occasionally, but I'm pretty sure he's just joking.

No, Tengu, don't look at me like that!  I *am* doing some proper work!

Got to go.

Thursday 3 March 2011

Things I have learnt recently...

Since I've been programming DirectX 10 a lot recently, here are a couple of quirks and gotchas that I've found (and lost a fair few hours to).

1.  Never, and I mean, never, accidentally use a DirectX 10 buffer initialised with vertex buffer binding flags as an index buffer.  If it just returned an error code/threw an error, like most other similar things in DX, then this would be simple to spot/fix.  However, what actually happens is that it assigns fine AND renders fine, but screws up the DirectX state is a way that will cause a horrible memory error at a later arbitrary time. 
2.  Be careful with input layouts - even with matched annotations it seems there is no proper checking that the size of each annotated variable is assured to be identical.  As a result, you could have a variable Pos that you've specified as a float3 in a vertex shader input structure, while in the layout it's defined as a float4, and no error will be flagged.  It may even render reasonably, but will probably be doing bad things to the DirectX state.

At the moment I'm splitting my time between tools work (on the main map editor) and working on the ship editing overlay.

This image shows a small world map in the editor with the navigation nodes for the AI ships added.  Each node has a radius as well as a position/connectivity information to provide additional information on free space around the ship.

Tuesday 1 March 2011

Screenshots!

To give an idea of what the current engine state looks like, I bring you... screenshots!  Bear in mind that these are still early days, so the main world environment is a bit sparse.

The game takes place inside a planetoid, that you have taken the job of exploring in order to retrieve an artifact.  In the planetoid you find some remains of previous alien technology, as well as some particularly unfriendly biological entities that are infesting the inside.  These currently go under the name the Scourge, but this is also subject to change.

Note that a noise texture and slight RGB-channel-separation effect are used in order to give the game a more retro look, but in screenshots the appearance looks a lot more fuzzy than in reality due to the per-pixel noise being constant.  The text in the top left is just for debugging purposes, and certainly won't be present in the final game.

This first screenshot demonstrates the basic world perspective i.e. top-down (or side-on, depending on which way you want to look at it) with an 8-way scrolling world.  The player ship (central) is firing both projectiles and an electricity-based weapon at a small number of enemies.  The RPG elements are clear by the health bar over each enemy as it is being damaged - certain weapon types will damage specific enemies more or less, so this feedback is important.

This is a slightly more recent screenshot showing the particle effects that have just been implemented, in this case shown as smoke when an enemy explodes.
Another screenshot with more of the smoke particle effect.  At the current time it supports up to 65536 texture-mapped quads' worth of particles without noticeably decreasing the stall caused by GPU-based collision stencilling.
Over the last couple of days a space-warping effect has also been added for the more powerful weapons, but this effect doesn't come across well in screenshots.

Introductory Post

This blog has been set up to chart the development of the indie game that is under development by Brainworm Software, that will be available on PC for anyone with Vista/Win7 and DirectX 10 hardware at some point in the future.  The game currently has a working title of Juggernaut (until I think of something better), and is an action/adventure/RPG/2D shooter hybrid.

Primarily, the game is a 2D 8-way scrolling shooter, where you fly around and blow the hell out a staggeringly large number of enemies.  The engine is designed to efficiently handle several thousand enemies on-screen simultaneously, with a similar number of projectiles, as well as a good number of laser, lightning effects, space-warping and any other interesting effect I can come up with.  The aim is to effectively model large swarms of (intelligent) enemies that need to be cut through in order to progress, as well as less frequent yet more powerful enemies and some crazily large bosses.

Upon showing engine builds to people, their first impression is generally "it's like Asteroids!", which is quite accurate in terms of the basic viewpoint and some of the more rudimentary mechanics of the game.

However, there is also a significant exploration element, and RPG elements are brought in by means of custom upgrades and modifications to the ship that improve your ability to fend off the swarms as you progress in the game.  So, in terms of being a mush together of existing games, the closest description is probably some bastard nephew of Asteroids/Smash TV/Zelda and Metroid.

The game has, technically, been in development already for a year or so in my spare time, but I recently made the decision to leave my current job as a technical consultant in order to work on it full time.  The custom underlying engine (written in C++ and DirectX10) is fully 3D, but is used here to mainly render 2D objects, and strongly exploits the DirectX 10 instancing capabilities for efficient rendering.

The next post will include a number of current screenshots to give more of an idea of the current progress.