Private alpha testing now ongoing!

Yes, it's been way too long since anything was posted on the blog, but the amount of blog activity is generally inversely proportional to how intensely I'm working on the game!

I'm pleased to report that a closed alpha testing session is currently taking place, which should help iron out any system-related issues.  Things are looking good so far for the main game engine being stable over a variety of hardware configurations.

After a few iterations of testing and improvement there will be a general alpha release posted on this blog, so watch this space!

Back from holidays!

The last month has been a little slow on development as I've had a couple of weeks of holiday, leaving me feeling refreshed and possibly even a little tanned.

The most important recent update is that scripted animated objects are now up and running properly.  This means that doors (and any other environment object) may be animated by script strings, meaning that proper game interaction is now possible to generate, such as the player's craft needing to move to a specific location within the world and activate an object (which then executes the script) in order to open the door.  These scripted objects are properly integrated into the physics engine, such that they impart appropriate force to any dynamic objects they collide with during their animations. 

Now, the primary focus is on further development of the AI algorithms for the swarm, such that they can spot the player's ship and attack appropriately, including chasing them through the environment and performing proper route-finding.  The basic navigation node structure is already complete and searchable, the main weakness is the lowest-level control i.e. correctly navigating between nodes without going out of bounds and colliding with the world.

I'm currently holding off creating a new video for a while until there are enough visible differences to make the recent updates apparent.  Also, I had it pointed out to me recently that in all the videos so far I've been playing the game really badly (purposefully), mainly to show off collision particle effects etc., but I'll make sure on the next one to actually fly around normally!

Token post!

OK, I say I'll do more regular updates and then immediately fail to post anything for a week. Welcome to OppositeLand, population me.

Work is still ongoing, worry ye not, with the focus on improving the scripting system and I/O for the more complex objects within the world map. Also, within the main asset management system there's now an overall object dictionary that handles everything from physics objects to particle fountains, allowing them to be spawned easily in a unified way.

So yes, at the moment it's all core engine work, but this is all necessary (except for a few sidetracks) in order to achieve my current main goal of scriptable game objects.

The start of a series of shorter updates.

Up until now I've tended to try and get out one decent-length blog post a week during development, but I think I may change that pattern to trying to post something short today to give a quick snapshot of what I'm working on at any given point.

The main thing I'm up to at the moment is working on the world scripting - my primary goal is to create an animated door that can open/close based on interaction with a world object. I've already gotten the main scripting up and running, such that interacting with a destroyed ship will update the amount of resources you have, give you a new ship component or start a given bit of narrative, but this push towards having a properly dynamic environment will make a lot of difference.

The custom scripting language and the asset management system are tightly integrated. Here's an example of the current scripting that is implemented and working:
"$Timer #3.0 $ZoneResource1 #OFF"

The $ prefix is used to reference an asset that exists in the global asset management framework, and the # is used to indicate a constant value. In this case, there is a special asset called 'Timer' that allows scripts to be called with a specific delay; the #3.0 indicates that the delay should be 3 seconds, and the rest of the parameters '$ZoneResource1 #OFF' are the script to execute once the timer period has completed. ZoneResource1 is another interaction zone, and the #OFF value indicates that it should be rendered inactive after the call. If the last two parameters were replaced by 'script:ExampleScript', the asset management system would check to see if the ExampleScript asset were already in memory and, if not, load it in from a specific default directory.

[Foreseeing potential questions on this issue]
Why didn't I use Python? Because BOLLOCKS, that's why.

Of course, any time you try to do X in development, you tend to find yourself doing Y, Z and occasionally α to support getting X to work, as well as tidying up other bits that you come across while doing Y and Z. As a result, the damage callback system has been given a bit of an overhaul in the last day or so.

Right now, I'm working on an object factory so that a wide variety of different object types may be simply loaded, allowing enemy spawners, physics objects, debris, animated objects etc. to be loaded by the same framework. This will then mean that dynamic components (such as the opening/closing door) will be automatically created and assigned to the right list, and then may be scripted (after a wee bit of work on animation).

[Edit: OK, so that didn't turn out to be so short].

Because banging can be fun, can't it?

OK, the title is a reference to this video (RIP Roy Skelton), which is marginally justified due to this post including physical collisions between convex objects.

Since the last post quite a few significant updates have been made, which are best expressed through the medium of bullet points.

• The convex object collision detection/physics is working well (huzzah!)
• Springs (currently massless) have been implemented in the physics engine, which will form the basis of the tractor beam with Juggernaut.
• The damage and destruction framework has been significantly upgraded to include penetration levels for both laser and projectile weapons.  For example, in the video you will see that the laser weapon immediately terminates upon hitting the debris, but passes through several Scourge enemies before terminating.  A larger penetration factor for a weapon will improve its effectiveness against multiple enemies, but not against single tougher enemies.  
• Each object can now have a convex collision shape associated with it that will be intersected with by laser + arc weaponry.   This replaces the bounding-circle based object/object collision.
• Upgrades the asset management framework that allows resource files containing multiple asset types to be loaded in transparently.  Dull, but very handy ;)

Environmental decoration: instanced cilia

As well as all the ongoing work on the physics engine (the convex polygon routines now work except in a couple of extreme cases that I'm fixing), I've taken a little time out to make things more pretty. In this case, I've added some animated 'cilia' that will be used to add dynamic motion to some of the infested areas. The initial version of this is shown in the video below, although I've already updated the actual graphics to add a small bright tip to each strand, stopping it from just looking like grass.



Although there may be thousands of cilia on-screen at any one time, all the work is done by the GPU using immutable buffers. A specialised vertex shader adds the sinusoidal animation based on a time value supplied via a shader variable, as well as adding a small size variation. Also, rather than manually defining the position/angle of each cilia in a level (which would be quite memory-hungry), areas of cilia are just defined by a straight line with a normal.

To further improve the effect, cilia further away from the camera have their colour dimmed in order to provide a depth cue.

Stable 2D Contact Points between Convex Objects

The purpose of this post is to describe a bit about how the 2D collision detection works in Juggernaut.  Some of it may be overly basic, and some bits may skip massively over other aspects, but it does cover a few points (particularly on convex object collision detection) that I didn't find directly anywhere else on the web, and should at least provide a good overview.

In order to integrate a shape into the physics engine, you need to be able to detection intersections between that shape and the others supported by the collision detection engine.

Simple Primitive Intersection

Up until now, Juggernaut has only properly supported circle/circle and circle/line interactions: the main world brush is defined by a series of straight lines (organised into a hierarchical tree structure for efficient collision), and the objects themselves are defined by a series of bounding circles.  These are the simplest types of collision, as there is only ever one possible contact point between the primitives (to clarify, circles can have two actual intersections with a line/other circle, but only a single contact point is required to resolve them).

A very rough image showing example contact points/normals for circle/line and circle/circle collision detection.  By convention, the normals are defined as pointing into object A.

A contact point is defined by the intersection point between the two objects, the collision normal, and the penetration depth.  The circle/circle case is the simplest, as you just take the vector between the two circle centres and compare the magnitude to the sum of the radii.

For the line/circle case you need to create the function closestPointOnLine( Point A, Line B ), which will determine the closest point on the line segment B to the point A, which may either be a point along B or one of the endpoints of B.  Intersection/non-intersection may then be determined by comparison of the distance of the circle centre to the closest point on B with the radius of the circle. 

For a more in-depth look (including the actual maths) this site is a very useful resource.

Convex Primitive Intersection

So, for the simple primitive case, the contact point information can be calculated directly.  However, what if we want to have a more complex shape, such as an arbitrary convex polygon?   Convex polygons are selected as dealing directly with non-convex polygons is much more difficult, and it is always possible to decompose non-convex polygons into multiple convex polygons.  In this case, working out whether the objects intersect is much more difficult, and a naive approach would probably involve comparing every edge in shape A with every edge in shape B.  Luckily, this is not necessary!

The key concepts and algorithms required in order to solve this problem are:
- The Minkowski difference (see here). 

- The Gilbert–Johnson–Keerthi distance algorithm (or just GJK algorithm)
- Alternatively to GJK, a Separating Axis Theorem-based approach such as the Lin-Canny algorithm.
- The Expanding Polytope Algorithm, which may be used in conjunction with GJK in order to improve performance on deep penetrations.


The Juggernaut convex shape handler is based around GJK, and I'll mention a couple of things that I've found about it.

1. It works absolutely amazingly for determining whether objects intersect or not.
2. If the objects *do* intersect, the raw GJK results can be unreliable, as the closest simplex edge won't necessarily correspond to an edge on the convex hull of the Minkowski difference.  To ensure that this always happens, you'll need to use the Expanding Polytope Algorithm in these cases for robust behaviour.

Now, the main problem I've had over the last few days is the calculation of robust edge/edge collisions between convex objects.  This is because, in the general case, what you'll get as a result from GJK is 2 simplex vertices (corresponding to the closest external edge on the Minkowski difference), and each of these is associated with a vertex in Shape A and a vertex in Shape B.  There are four main cases:

1. Both Shape A vertices are identical and the Shape B vertices define an outside edge of B.
2. Both Shape B vertices are identical and the Shape A vertices define an outside edge of A.
3. Both the Shape A and Shape B vertices define outside edges of A and B, respectively.  This will only really occur when the edges are very close to parallel, and can also be associated with a triangular simplex of zero are.  Also, this may or may not occur in exactly the same situation depending on the initially selected simplex point.
   
4. The vertices do something else and define non-external edges of A and/or B (may happen with raw GJK, but not GJK+EPA). 

When there is only a point/edge interaction, both cases 1 and 2 are simple to solve as the intersection point occurs on the point of whichever shape, and the normal is defined by the edge normal of the other shape. However, if an edge/edge interaction is going on, this will lead to only one contact point being found rather than 2, causing jittery behaviour.

So, the solution that I've come up with is as follows: for the shape where only one vertex is returned by GJK, check both edges that are connected to it for contact points.  This is almost certainly not the only solution to this problem, but it's the only one I've found that produces stable results thus far.  This is demonstrated in the diagram below: 

Dual-edge checking collision point calculation, showing the possible basic configurations for 1, 2 and 3 point contacts.  The red vertices show those that form the closest Minkowski difference edge, as returned by the GJK algorithm.  The grey outline show the outlines of the capsules produced by the edges, and the red arrows the intersections/normals.  Note that this figure skips the situations where the endpoints of the lower shape edge come further in than the outer ones of the upper one.

There were a few minutes spare today...

...so I did something very silly.

Beware the Spacehoppergeddon.

More dynamic world environments.

As part of the upgraded environment there will be free-floating debris found in areas, which can either be destroyed or, coupled with the tractor beam, employed as a weapon.

This video shows the prototype implementation, where each piece of debris is circular and coloured a dreadful orange. However, they do properly collide with each other in a realistic way using the physics engine. Prior to this point, the complexity of the physics engine was a little unnecessary when only interacting a single object with a set of immovable objects.



The next step is to upgrade these large debris pieces such that they are an arbitrary polygon, rather than just circular. Also, improving their graphics wouldn't go amiss, either! I must confess to being tempted to texturemap a space hopper face onto them, though :)

Moar better collision detection.

Up until now, the only collision detection between the player's ship and the environment had been with the main outline of the world generated by the initial brush carving, which is a relatively simple shape. However, for a properly completed environment there will also be a lot flair (decorative) objects adorning the environment, and it's also important to be able to collide with them.

In addition, the laser impact effects have also been updated, with the impact explosion orientation now being determined by the normal of the impacted surface. It also kicks up some debris particle effects, although these are currently the same regardless of the surface type being hit, and thus look odd for some of the alien flora.

Flair intersection

There were two parts to getting this to work, both of which drew heavily on my existing codebase for creating and merging vector brushes (which has held up surprisingly well, given that there are a few bits that could really do with improving).

The first part is, for a given 2D (or basic 3D) mesh, generating a 2D vector brush of the outline. This abridged version is as follows:

1. Identify all edges within the mesh. This is something that needs calculating, as by default meshes are stored in terms of vertices/triangles.
2. Identify the set of triangles that use each edge (the set must at least of size 1, else where the hell did the edge come from?) 
3. Determine whether each edge is potentially part of the outline.  If an edge has only one triangle associated with it, then it's always an outline edge.  For multiple triangles, it is an outline edge if the third point of each triangle (i.e. that not part of the edge) all lie on the same side of the line.
4. Throw out all the non-outline-edge edges. 
5. Starting on any outline edge, following connected edges around until you come back to the original edge in a loop.  In normal situations (apart from some awkward 3D configurations) there will never be any branching to worry about that.  Add that as a vector path.
6. Repeat 5. for any currently unused outline edges until all are accounted for.
7. Merge the set of vector paths together to form the final outline (which is a whole different bunch of algorithms).

Then, once you've generated the vector brushes for all the flair objects, you can then merge them together, and then again with the main world outline brush in order to produce the final collision geometry. Finally, take that geometry and generate a binary tree from it in order to allow efficent intersections. 

Rapture Investment Opportunity!

So, if there's anyone out there who believes that the Rapture is going to occur tomorrow, I'd like to offer the last minute opportunity to divest yourself of some wealth and give it to a cheerful heathen.  Not only will it aid indie game development, but by reducing your level of wealth you may help avoid the camel/eye of a needle/Heaven problem*.

*Warning: money not returned in the unlikely event that Rapture does not occur.

Progress Update

Oops, it's been over a week since the last update! Time really does fly when you're coding away.

OK, the main things I've been working on over the last week or so are as follows:

Player/World collision

This is now basically done, along with player ship damage and particle effects at collision points. The particle effects are a mixture of sparks and rock being disturbed from the walls, which looks quite nice when scraping along the side. It also need a good corresponding sound effect!

There's still some tidying up and improvement to do on this aspect, but it's sufficient for now.  Have a peek:

 

Scripting zones

In order to make a game with an interesting and interactive world, there need to be scriptable zones within the world that can do a variety of things, from bringing up a certain story conversation, spawning some enemies, changing world states (e.g. opening/closing doors) and a lot of other things. The basic scripting capability now exists, and is embedded within the main global asset management system.  At the moment its capabilities are pretty limited, but these will rapidly expand as I add more scripting interfaces.

Upgraded collision detection

For anyone unfamiliar with collision detection, the basic problem is one of testing your game object's bounding shape (a circle, in the simple case) against all the objects in the world. Now, if you have 10000 primitives (e.g. lines/triangles) in your world, the easiest way is just to test directly against each of the 10000 objects, leading to 10000 geometry tests per object. However, using a hierarchical (tree-based) model you can achieve this in around Log2(10000) = 13 tests, allowing much greater efficiency. Even better, if you increase the number of primitives by a factor of 2, you'll only need one more test. This scaling allows testing against very complex world geometry in an efficient fashion.

Anyway, something that's been niggling at me since I upgraded to using the physics engine is the old hierarchical collision detection, which used a binary tree in order to calculate collisions with each triangle in the world mesh.

However, in reality, using all the triangles was quite wasteful and pointless, as the only important bits are the lines that form the outline of the world itself, and the corresponding bounding circles/bounding boxes were much larger than they needed to be. Since the world is carved from an overall vector brush, though, this outline is directly available, and thus I've refactored the code to produce a collision tree from a set of lines rather than triangles, leading to an overall improvement in efficiency and niceness. This is one of those things that won't have any directly visible effect, but makes further development easier.

Collision Physics Mk. 1

OK, the basic version of the world collision physics is now up and running.  This takes the overall bounding circle of the player's ship and uses that as a collision object, as shown in the video below.

However, there's still work to do in order to:
- Perform physics collisions with each ship component.
- Apply damage to the components based upon the collision energy.
- Add visual effects, such as a spark stream if the ship is scraping along the side of a wall.


Basic Environment Collision Physics from Darren Myatt on Vimeo.

The ship editor in action:

This video demonstrates the initial drag/drop ship editor interface in action. It shows that each ship component has a number of slots that can be used to attach either other structural components or weapons.

This video starts after the two wing elements and one of the engines have already been added (due to FRAPS time restrictions) - you then see the addition of a couple of power generators, which provide increased power recharge rate and power maximum (which is consumed by firing weapons), a missile launcher and a couple of standard energy cannons.

The angle of any of these components may be changed by dragging with the right mouse button, so you can create rear-facing/side facing weaponry as desired. As development progresses, there will also be computer-controlled turrets that will auto-target enemies.

Juggernaut Ship Editor Demo Video from Darren Myatt on Vimeo.

Time for reflection...

OK, while I'm putting off a bit of particularly annoying refactoring, I thought it may be a good time to post a quick reflection on how far Juggernaut (and I) have come so far.

I quit my previous job (as a technical consultant at a defence subcontractor) on the very first day back this year, because I simply couldn't do it any more. Monetarily it was a pretty good job, which is how I can now afford to do this, but I got no satisfaction from it and the pressure nearly drove me crazy.

I'd been working on the code that became the Juggernaut engine for about a year in my spare time (including long periods of nothing) before then: it initially started out as the engine for a 3D game named Super Robot Harpsichord which, who knows, may one day still get made. However, it quickly became clear that attempting to create a full 3D game on my own was completely infeasible in terms of art assets, at which point I came up with the basic idea for Juggernaut, although it has evolved a lot since the initial conception.

The Super Robot Harpsichord graphic engine at the time when work was stopped.  Notice how everything has the same texture, a constraint that I quickly removed when creating Juggernaut!  The red spheres are a large number of test bullets that bounce around the scene.

So, after fully leaving my last job on the 5th February, I have been working on Juggernaut (more than) full time. It is still quite ambitious (something warned of by MrMacguffin), but I am trying to keep to deadlines, and progress has been rapid.

My original plan was to make a first demo in May, and I think I'm still reasonably on target for that, although it's now going to be the end of May. It's certainly going to be an alpha release rather than a beta, but hopefully it should demonstrate enough of the concepts of the full game to get people interested.

The first high quality Alpha video!

Yes, it's finally here, I've managed to make a video that doesn't look like arse! Alas, the free version of FRAPS only allows clips of 30 seconds, and this video doesn't necessarily show off anything to the best effect, and the sound is knackered, but it's at least a start. Now that I'm confident it produces good results, I'll upgrade so that I can record full videos.

The video demonstrates the laser weapons and the force-applying missiles with space-warping effect. There's also going to be a graphical explosion effect for the missiles, but that hasn't been implemented yet.

Also, note that the Scourge aren't bothering to attack the player in this video as the AI is just set to do a patrol loop. In the actual game they'll turn and start following/attacking the player once spotted.


Juggernaut Alpha Demo 1 from Darren Myatt on Vimeo.

FRAPS vs CamStudio - Fight!

Up until now I've been using CamStudio in order to produce videos, as I'd used it before on my Neuromantic post-doctoral project to produce tutorial videos.  However, as you've seen, the results thus far have not been so great.

Luckily, my friend Mark reminded me of the existence of FRAPS recently, and having downloaded it and done a quick test I can confirm that FRAPS is much, *much* better, and can easily handle 30FPS capture without slowing the game down.

So, you can all expect some much higher quality Alpha videos soon!  Huzzah!

Juggernaut Development Update.

My new keyboard arrived today that should help streamline the development of Juggernaut:

It'll be so much easier having the 1 key to the right of the 0, unlike standard keyboards.  Also, the air-cooling will definitely reduce the level of key-melting that I usually experience.

Post-Easter update

Since the 15th I have been exploring the vast and desolate wastelands of the North of England (while visiting my family over Easter), and only returned to Guildford a couple of days ago.  Now, after going to the Reading Beer Festival yesterday I'm ready to start work properly again.

This is not to say that I haven't been working over the couple of weeks: things have actually come quite far.  Before now, the main thing missing from the Juggernaut engine is any proper collision physics: rather than the player's ship bouncing off walls and taking damage (as you'd expect), damage was just applied while the ship was colliding with the main environment.  This was just a temporary, but obviously incomplete, solution.

However, the advantage of being back in the North was that I only had my laptop with me, which lacks DirectX 10 hardware, and as a result there was no way that I could work on the main game engine.  This forced me to do the necessary research in order to be able to implement a decent rigid body physics engine, which means that not only will the ship react well when colliding with walls, but it leaves a lot of room for interesting physics-based challenges, including pulling things around using a tractor beam.  I'm currently just doing the refactoring necessary to integrate the physics engine with the main game engine, but in a few days I'm confident that this last major aspect of the game will be working well.

After that, it will be full steam ahead towards the creation of the first demo!

Refactoring!

Sometimes, there's just something in your code that niggles away at you, making your life more awkward until one day you decide you've had enough, reach for the refactoring chainsaw and refactor the buggery out of it.  Today, I reached that point.

In this case, it was a couple of aspects of the main game object class structures that, although sensibly designed at the beginning of development, has since grown into a significant bugbear (as shown in Figure 1).  Basically, I'd shoved a templated structure too high up in the hierarchy, meaning that I was having to do a lot of dynamic casting between different interfaces as it wasn't really possible to have a single interface that had access to all the important bits (in this case the object's activity state, pose, dynamics, collision properties and damage interface) due to this templated bit sitting in the middle (which was a subobject list, in case anyone cares). 

Figure 1: Artist's depiction of a bugbear.

To simplify development, I shifted this templated element down to the bottom of the hierarchy.  Of course, this involved screwing with a lot of the core code and, as you'd expect, it's taken a fair amount of time to get everything back up and running again.  There's still some additional validation to do, but it's generally all looking promising and should make my life easier in future.

In general news, the ship missiles are now coupled with one of the space-warping effects, making them look quite sexy (should make a video), although I still need to create a larger explosion graphic to go with it.

I'm heading back up to the North of the UK for a week soon to see my folks and, unfortunately, my laptop doesn't have DirectX 10 hardware, making working on Juggernaut more tricksy.  However, I do have a fair amount of work to do on improving the collision physics that doesn't really need pretty graphics, so this seems like a good time to do it.

Missiles!

Since I last posted I've mainly been doing some improvements to the comic overlays and some general refactoring/improvements, as well as some changes to the game control interface (I may blog about the latter soon).  Yesterday and today, though, I decided to add guided missiles to the array of weapons in Juggernaut.

The standard projectiles types have a very simple dynamics model, and simply move in a straight line until they collide with the main collision stencil (or their lifetime expires).  This type of collision detection is performed on the GPU, and therefore is highly efficient, which is why it is a good choice when there may be thousands of collisions to determine.  The downside to using GPU-based collision detection is the necessity of a GPU-stall before you can actual get the information back to the CPU.  The stall is necessary as the GPU needs to finish its current queue of commands up to and including the collision detection operations before the results you want are available.  At the moment on my GTX260 this stall is only at around 3ms, when 16ms is generally available per frame (assuming 60Hz), so this is not much of a problem.  To avoid just losing this time, the GPU-based collision detection operations are queued, then the main CPU-based updates are performed before the stall is forced.

Anyway, the missiles are effectively treated as standard projectiles, but with more complex dynamics that allow them to select a target and then accelerate towards it.  They will also spawn different (and larger) explosion types to the majority of projectiles and cause splash damage to other enemies.  The larger explosions aren't properly implemented at the moment, though: that's today's task!

Here's a screenshot of the initial missile implementation, along with a nice blue vapour trail to add some visual variety.

Screenshot of the first implementation of smart missiles within Juggernaut.  At the current time their AI just locks onto the closest enemy at the time of launch and accelerates towards it, although I will upgrade this soon to also take account of the target's velocity.

Introducing ARIADNE

One of the problems with having an external 2D view of the player's ship is that, while the action may be fun, it's not very conducive to storytelling, as the ship does not portray any sort of character.  As I wanted Juggernaut to be quite a story-based game, I needed some way of telling the story without a) requiring FMV or b) full voiceovers because c) my budget is tighter than a gnat's anus.

Of course, this only really leaves some kind of text-based approach, but I really didn't want to assail players with walls of dry text.  Instead, I decided on a comic-based approach, where the story is conveyed by the main characters talking to each other.  Each character is vector-based, and may be posed in a variety of ways to portray emotion, with comic speech bubbles (and the emphasis therein) used to get across additional character.

The two primary characters are the protagonist Captain P. Tenuous (cookie to anyone who manages to work out *that* reference), a space trader undergoing a midlife crisis, and his belligerent navigational computer ARIADNE, who assumes the role of the deuteragonist.  Most of the dialogue within the game will be plot points and general banter between these two characters, and also serve to break up the action.  There is also a human antagonist who will be involved in dialogue less frequently.

Anyway, as a first character to implement in this system ARIADNE is the ideal choice, because its basic facial structure is so simple that it may be hardcoded.  In the game world, ARIADNE's model comes with a wide variety of different and engaging personalities, but since Tenuous was too cheap to upgrade he gets an annoying cynic with a face made of 16 triangles.

Each character is defined as a mesh with a neutral pose and a number of different sub-expressions that define delta vectors for a subset of the mesh vertices.  For example, ARIADNE has sub-expressions to raise its eyebrows, as well as close its mouth vertically/horizontally and move its eyes etc.  Larger expressions (such as happy/angry etc.) can then be generated as a linear blend of these sub-expressions. 

On the current test implementation of ARIADNE, the results look like this:

Example ARIADNE expressions.  The top left image shows the neutral expression (which is symmetric with strong right angles), while the other panels show various mixtures of sub-expressions that break the symmetry and add character to the mesh.  You can see the start of the speech bubble to the right.

As well as the expressions, there will be different framing options for each character, such as zoom level/angle, which can be used to imply 'intensity' and add additional graphic variation.

When Macros Invade Your Home

It's not very often I'd be inclined to post code bugs that I come across during development, but this one foxed me for sufficient time and the answer was face-palming enough that I thought I'd post it.

This is a little excerpt from some of the GUI handling code.  When you click on a control, it iterates through any sub-controls in a recursive fashion and calls the same function on those:

      virtual int mouseDown(const Tuple2f& Position, const IBaseMouseEvents::mouseStateChange& State ) override
      {
         int Result = -2;
         //Check for intersecting with this control's layout
         if ( Overlaps(Position) )
        {
            //
            Result = -1;
            //Call mouse down on subobjects
            for( uint32 i=0; i<Objects(); i++)
            {
               //Update the final result
               Result = max(Result, Object(i)->mouseDown( Position, State ) );
            }
         }
         return Result;
      }

This seems pretty straightforward, but when I'd added a Next button to the GUI it was oddly getting clicked 8 times every time I pressed it, and I just couldn't work out what was happening for about 20 minutes. 

Worked it out yet?  If so, congratulate yourself on being a smug bastard.

The problem is that the max() function in C++ is defined as a macro, rather than a function, and this macro is (((a) > (b)) ? (a) : (b)).  As a result,the mouseDown() method could get called twice per loop iteration, and as my button control was 3 levels down the GUI hierarchy, this meant 2^3 = 8 clicks rather than 1. 

Bollocks.

Right, now back to programming rather than scratching my head!

Font woes

OK, the title is not quite accurate.  What I'm currently having trouble with is finding a reasonably cost-efficient way of embedding a font into my game.  I've found a font, and it is lovely and perfect but, unfortunately, it will cost a total of $300 to purchase a license such that I can legally embed it within my game.  It's slightly irksome that this cost is basically 10x the fee for using the same font in unlimited commercial print media.

Arse.

Today I've been mainly sexing things up.

I've spent a bit of time today sexing my blog up, as it's been going for a while now but I hadn't gotten around to adding on all the standard gadgets yet.  So, I've added some tags to entries and the first couple of related blogs to my blog roll.

Up until now I've been a bit insular, but I'm making an attempt to engage the video indie game development community as a way of exchanging ideas and also hearing about other people's experience in the industry.  Mr. Tengu also wants me to slowly work out where my competitors live and have them assassinated, but as it is our budget barely stretches to kicking one person in the shin.

More ship upgrades!

OK, I've gotten quite a bit further with the ship editor now, and have gone as far as implementing a couple of new ship components in order to increase the variety of test configurations available.  One of the important things that's changed is the addition of a proper engine type.  Up until now, the main weapon component also served as a thruster for simplicity's sake.  There's also a new structural wing-type element (which looks much better than the old strut type), and I've redrawn the generator type to fit into the new graphic scheme more effectively. 

The screenshots only show two weapons: the standard cannon and basic laser type.  One of the things I need to do in the near future is create a proper ship weapon that implements the lightning weapon in a specified arc (rather than hitting absolutely everything as the test implementation did).

That laser effect still needs some sexing up.  It's on my todo list.

After a bit of improvement of the spawning framework I have once again gotten the laser weapon to leave a set of custom explosions at the point where it intersects the environment. 

The white lines that you can see between certain Scourge spores are for debugging some of the swarming algorithms, and obviously will normally be invisible.  I plan to redraw that turret weapon as well, it no longer fits in with the new ship parts that well.

Example Ship Configurations

Now that the ship editor is actually functional, I can post a couple of screenshots of example ship configurations.  They're not particularly varied, as I've only bothered to make a minimal set of ship components at the moment, but it should be informative, at least.

The two weapons shown here are the basic energy cannon (which was the first weapon implemented) and the laser cannon (a straight line instant hit weapon).  As work progresses, a lot of other weapons will be implemented, and upgrades will be generated for existing ones.

This first configuration places two laser cannons on the back of the ship, thus providing some all round firepower.

The second configuration concentrates all the firepower to the front, allowing more effective frontal assault of a swarm.  Having a power generator exposed on the back probably isn't a great idea, though.

Thursday Haikus

Programming a game\
It takes a bastard long time\
Hope this fucker sells\

Alternatively:

Coding all day long\
What time can I start drinking\
Without being a lush?\

Right, back to sexing up the ship editor.

Video Test

This is a test video I made a while ago using CamStudio, but hadn't gotten around to uploading until now: the FPS isn't amazing, as my development machine does *not* like running the game at full FPS while simultaneously encoding, but it should give a first indication as to what the basic gameplay will be like.  It only shows a couple of weapon types (standard projectile + lightning blast), but it does feature the newer particle effects, although it predates the recent improvements in environment decoration.

[OK, what the Blogger upload did there was take my already highly compressed video and then proceed to squash the Bejeesus out of it.  Hopefully it still gives a bit of an idea, though].

When creating the main demo video in the next few months (as part of my Indie Fund application), I'm going to have to find some way of recording at full fps, which may involve adding the ability to specifically seed the random number generators and record player input, then play it back frame-by-frame so that processor power isn't an issue.  Which will be a bit of an arse, but as the most important (and pretty much only) part to the Indie Fund application process, it's definitely worth the time.

Feeling all GUI.

So far this week I've been continuing work on the main GUI system, and have certainly now churned out enough code for a fair number of simpler games than Juggernaut.  For example, if I ever need to do some kind of drag-and-drop 2D puzzle game I'm now pretty much set!

Although the GUI system is completely custom, I've based the layout fundamentals on Windows Presentation Foundation in terms of split panels/stack panels because, although I grew to hate WPF with a manic passion, the layout system was pretty good.  It would have been easier just to hard code all the panel positions for the ship editor, but bothering to do a passable layout system will make subsequent GUIs (such as the main menu) much simpler.

Just for you, even though it's still early days, I thought I'd post a screenshot of the early version of the ship editor, since it's been a while and I know how much people prefer a picture:

A first look at an early version of the ship editor, with a list of components on the right hand side that may be dragged on the main playfield and then attached to the ship.  Note that the background textures and title are just placeholders, and will be replaced by something much more sexy.  The basic layout is likely to stay pretty much the same, though.

Anyway, once I've finished off the most basic functionality of the ship editor (which should be today or tomorrow), I'll probably go back to the world editor and allow distribution of ship components throughout the environment that you can find and then bolt onto your ship.

Current Juggernaut code base size: 1.25 Megabytes.  Great Expectations by Charles Dickens weighs in at about 1 Megabyte.

Game Review: Dead Rising 2

OK, as well as posting status updates for Juggernaut I thought I'd also post a few game reviews as well. A couple of weeks ago I bought Assassin's Creed 2 and Dead Rising 2 on the cheap, and finished Dead Rising 2 early last week.

The first issue I had with DR2 was that it crashed completely on start-up, a problem that I fixed (after looking on forums) by changing my sound card settings.  Changing my sound card settings?  Is this still the early 90s?  Anyway, for a large company with proper QA teams this is a piss-poor fatal error to leave in.

Firstly, I have to say that overall, I did enjoy DR2 a lot: it does manage to effectively portray large crowds of zombies that you can mow your way through (sometimes literally) in an entertaining fashion. Unlike the Left 4 Dead franchise, these are proper old-school shambling zombies and, importantly, it's simply not possible to kill them all because there are so damn many: this is very different from L4D, where you pretty much have to kill every zombie you come across. When travelling around, usually inside a large mall, you instead find yourself running through the least dense areas and only killing zombies when you have to.  There was a particular highpoint when I found myself wearing a summer dress, Davy Crockett hat and spearing zombies with a swordfish that I'd pulled off the wall of a casino.

The overall game is timed, and certain events/missions will occur at specified times, meaning that is was impossible to complete anywhere near all the missions, leaving a lot of scope for replay. Although this is an effective mechanic, there are times when it's possible to end up with savepoints in either completely unwinnable or almost unwinnable positions. For some of the main missions (which must be completed else the game forces you to restart), the bar that shows you how long you have left to complete it may actually encompass the entire amount of time it requires to do 4 parts of a multi-part mission, with no idea how long it will take to do each part. A much better way to do this would have been to set time limits for the start of each mission sub-section, meaning that you could guarantee that the overall mission was always possible in the time available.

However, the main issue with Dead Rising 2 as a game is the balance, in that there isn't any. Seriously, elements of this game are as balanced as an upturned pyramid on cocaine. I fought bosses a quarter of the way through this game that made the final boss feel like punching out a 10 year-old with leukaemia. Especially since, in a fit of genius, you only earn the essential "dodge roll" move several hours after you've had to fight the bosses it was really necessary for.

Strangely, all the difficult bosses you'll fight are human, not undead. Hell, you can destroy any of the zombies with a couple of hits from a sledgehammer, it's those pesky humans that require 200 rounds of machinegun fire to the head followed by a good pounding with a baseball bat before they'll feel faint. It's particularly irksome when they're a fucking hippy armed with a shard of glass.

Seriously, though, if you're going to make difficult boss fights that you are going to die on a *lot*, not allowing players to save directly beforehand is just being a bastard. A lot of the time you'll need to run for a couple of minutes from your last save point back to the boss area, simply to get immediately killed and have to do the whole thing again.  This does not make for fun gameplay.

Oh yes, and the final final boss fight relies way too much on quicktime events, which everyone knows are a bad idea but they still keep getting put in games. To be fair, they're not "Press X Not To Die" ones (unlike Dead Space 2, which was a bastard for them), but it's still quite annoying.  Especially, I have to say, when they're converted to the PC and so the button flashes say "WASD" - because you are only using the buttons as up/down/left/right, I (and I suspect it's not just me) find it mentally harder to map "W" when it flashes up instantly to the "up" button than if it just used a directional arrow.

Yahtzee's Review also rings very true, and he complained about pretty much the same things that I found annoying.

Anyway, the moral of the story for game design is:
- Add savepoints before encounters you expect players to repeatedly die on so they can jump straight back into it, else they will get mightily frustrated.
- Don't take away essential gameplay elements (such as the damn dodge roll) simply to boost your levelling system.
- Make sure that you don't let players save the game in an unwinnable state.

Within the main design for Juggernaut, there is a checkpoint structure that the player will respawn from every time their ship is destroyed (it's even justified within the storyline), so this will allow easy avoidance of the first issue by providing the automatic saving of progress.

A Short Rant About "Unique Selling Points"

In the games industry, there is always some requirement for a new game to have a USP, which is something that sets it apart from other games.  This seems like a good idea at first, but it pretty much always just manifests itself as some pointless gimmick such as the ability to shoot round corners/slow down time a bit/have trousers that turn to jam.  Every time I describe that I'm making a game to a fellow gamer, people tend to ask "Ooh, what's the USP?".  To which I would like to reply "That's a bad question" and slap them.  However, it's generally a bad idea to attack your potential customer base.

I think all this attention on USPs takes attention away from what is genuinely important about a game, and that is is it actually good?  If that's the case, it doesn't really matter much if it has a USP or not, because USPs don't necessarily make a game either good or bad.  In fact, I think feeling the need to try and explicitly crowbar a USP into every single game may well harm the development of some games.

Another thing that the USP idea doesn't take into account is that novelty can appear at lots of different levels within a game.  For example, it could be a completely generic FPS but with amazingly novel level design and very well designed challenges, but because it doesn't feature Jam Trousers it's somehow seen as Not As Novel.

As a good case study, look at the original Half Life.  I've thought about it, and I can't really think of anything that could be considered a USP.  You play a man fighting against an alien horde (ooh, novel!), with plenty of shooting (yawn) and platforming (double yawn).  Of course, what made Half Life an amazing game was a mixture of the story, the atmosphere, the level design and well, pretty much everything.

Anyway, I think my main point here is that concentrating on USPs is a bad idea that may be used to prematurely judge the quality of a game.

If you're thinking that all of this is bollocks, then luckily Juggernaut has a pretty good USP :P

General Progress Update

This is just a general update, alas without any particularly exciting images.  I should have some updated screenshots soon, though. 

Control/AI Improvement

After spending a few hours remembering how to do control theory and Laplace Transforms, I did some significant upgrades to the Proportional + Differential controllers that are used to determine the rotational behaviour of the player and enemy ships. The parameters for the controllers are now calculated appropriately for each ship, thus leading to much better behaviour when rotating to the current target direction (less overshoot and faster damping).

I've also started to do a bit of preliminary work on the swarm mechanics.  One of the main issues here is how to efficiently identify the neighbouring Scourge ships when you could have around 2000 in play simultaneously (leading to around 2000000 naive distance calculations to calculate all neighbours).  I'm currently considering some kind of dynamic histogram-based binning method.

GUI work

I've also been doing a lot of work on some of the required (and slightly non-exciting) GUI aspects of the game.  The most important in-game GUI is the Ship Editor, where you can upgrade existing ship components and add new ones that you've scavenged.  This allows your ship to grow and improve over the course of the game (which is the main RPG aspect) as you add better shields/power generators/weapons etc.   Over the entire game, you will progress from being terrified of facing a single Scourge ship to being able to fend off a swarm of hundreds or thousands.

Updates to environment complexity and some AI.

Although I'm probably making life more difficult for myself than is strictly necessary, I decided I wanted to do a good job on the AI of the Scourge and make them an enemy you had to outwit as well as outgun.  Each one of them counts as its own 2D dynamics object, and applies a couple of thrusters in order to navigate around the world.  Coupled with the first implementation of the navigational node system, this produces a result something like this:

The Scourge on a circular patrol route using their basic untuned P+D controller and singularly failing to navigate around some of the new flair objects.

Although this at least validates a lot of the underlying ideas, there's still a good amount of work to do.

1) Each of the individual enemies does not interact in any way with its neighbours, meaning that although there is some impression of a swarm simply due to numbers they don't really exhibit any swarm behaviour.  I have plans to upgrade this to so that they will dynamically track those in front of them, leading to much more realistic swarming.
2) At the moment the swarms stay much too bunched up, which is a combination of the fact that they have no knowledge of/collision detection with other members of the swarm, and also because they still aim squarely for the centre of navigation nodes at the moment, rather than exploiting their full radius.

Ideally, I would like an attacking swarm to be able to peel off automatically into subswarms that will attempt to attack the player from multiple angles using a variety of tactics.  For example, against weapons with a large spread it may be better to bunch up and rush the player, whereas for weapons with a single large beam scattering and attacking individually may be superior.

Environmental Decoration

Over the last couple of days I've been doing further work on the world editor towards a more interesting environment.  It now extends upon the brush editing capability I created for actually carving the world to allow the creation of vector graphics to add as decoration.

An example of a (slightly) decorated environment using a few simple static flair meshes.  The plan is for areas infested by the Scourge to be significantly different visually in order to warn the player.  Since this screenshot was taken from within the World Editor the transform handles for each object are overlaid.  

My current plan is to try and create a first playable demo by May, although this will almost certainly be only to a few playtesters, rather than general release.  This will probably take the form of an environment where the player must dig in at points (using some of the deployable items I have planned) and hold off waves of Scourge before progressing.  There are going to be prox mines, because I honestly can't think of a game that hasn't been improved by prox mines.  

Right, now for some sleep.

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.

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.

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.