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.

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.

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.

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.