Sunday, 27 October 2013

Upon a Voronoi Sphere

The title may sound like a poem, but it's the start of a new game.  I started work on this a few weeks ago with a few ideas in mind.  I really liked the spherical properties of 'Last Chapter', like the camera motion etc and I wanted to build on some of the things I'd developed from that project.  This time though I'm going to work from a bottom up perspective rather than start with a high falutin' idea.  'The Prettiest Ribbon' is a result of that method, taking well known gameplay and build up from there.  I've settled on developing a cool turn based strategy game.  The first thing to tackle...the map.

A voronoi sphere with overlaid delaunay triangulation.
With zero to handful of smoothing

Rather than work on a flat grid, I want to generate a map on a sphere.  This is not totally straightforward and I may well fall back to a 2d grids but I think I've figured out the steps needed.  To create a more interesting adjacency I want to use voronoi regions.  There's a great article and demo that provides tons of help on this. The math for doing triangulation on a 2d plane is tricky enough but I got a simple case up and running, the 3d case was way beyond my abilities though.  A bit of internet searching though and I found a great C# library for creating convex hulls for physics collisions which conveniently are also delaunay triangulations.  I feel I need a tag for "I'm not sure if this is hard or I'm just stupid" because even though I'm not really writing the really hard math code it still takes me ages to work out how to piece the code together.  It's coming along pretty good though, check out the potential when I use more points.

Gaia


The other news this week was that 'The Last Chapter of Man' was released on Desura.  Yay! And a bunch of people had trouble installing and launching it.  Boo!  It's a really frustrating thing as I don't know where the problem lies.  It could be the installer. (Though I followed the walkthrough from Microsoft to the letter).  It could be some bit of code I've written that doesn't work with certain monitor configurations.  It could be a driver issue with their system.  I just don't know.   In some ways it's good as I was fairly keen & happy to stick with XNA even though Microsoft have abandoned it themselves.  But if the framework can't be deployed reliably, and there are some interesting comments on the microsoft installer, then it's value is questionable. So I'm going to check out Unity this week, already had a little look this weekend, and I'll see if I can recreate what I've already done in xna.  There are another couple of other tools out there, both the wave engine and sunburn are an option, but I'll no more by the end of this week.

The users on Desura have been very patient and kind about this though.  It's upsetting as one the main points of XNA is to abstract away the difficult parts of handling windows & graphics devices etc.  So if it's not working it's frankly above my technical ability to debug.  And then all I can really do is apologise, and like I said, they've been surprisingly pleasant about the bugs.  Desura users.../good /people.


Monday, 21 October 2013

Picking code from the Octree

As I begin work on the next game it's nice to revisit some well worn code.  The octree  I wrote for 'Last Chapter of Man' worked well but the implementation meant the tree was kind of top heavy with objects, not ideal but bounding sphere checks are pretty fast...plus it worked.  Once it was up and running I didn't want to break it mid game unless I had to.  Now though I've gone back and improved it into a loose octree implementation.

Without loose bounds (left) a lot of objects only fit in the root node.
With loose bounds they can filter down (right).

I won't go over the basics of octrees, there's a number of articles available on them. I do want to go over a few parts I personally found confusing though as I found there was a slight gap between the theory and the implementation in a few of areas.  I may well just be stupid, but hopefully others find this a little helpful too.  My confusion stemmed from...

  1. Handling objects that crossed boundaries, i.e. didn't fit within a box.
  2. Pruning of the tree when objects are removed..and related to this
  3. Expanding and collapsing the tree as objects move around.


1) In my implementation, objects are only present in one node of the tree.  If an object wasn't wholly contained within the bounding area it would not filter down.  And I store these objects in a list rather than an array, so octree nodes have an ideal amount of objects they want to hold...but they can happily hold more as needed.

2) When I remove an object, I call that node's parent to try and prune the tree.  And all it does is count how many objects are contained in it's branch, and if it's less than our max we copy all the objects into this parents node clear everything below us.

3) Every time an object moves there are a few checks it makes.  If it no longer fits within it's bounding area we remove it and add it back into the tree from the root.  If it does still fit within the bounding area, we don't just leave it be.  If that node isn't a leaf we also try and filter it further down the tree, so objects are constantly being filtered into the best position for boundary checking.

objects moving and the tree adjusts accordingly.
Only  non-empty nodes are shown.

I'm sure all games require variations on the above, but those where the areas where I was fuzzy on and it took me some head scratching to get working correctly.  With the loose tree version, the boundary checking uses the center point of the sphere against the strict bounding box.  When you do your collision checking you have to check against the loose bounds rather than the strict ones, the loose bounds being twice as large. It means you have to check against more parts of the tree then, but the tree itself is more balanced to compensate.

I've posted the code online and you can download my loose octree implementation and study it for yourself.  I think it's robust and bug free but by all means let me know if you spot an error. I hope it of use to others and I intend to post other small little snippets of code too as this blog continues.

Monday, 14 October 2013

Tying a ribbon

I've been putting the final embroidery on the my next game, entitled "The Prettiest Ribbon".  It's snake..but on a cube.  This began as an amnesia fortnight project toward the end of Last Chapter of Man.  XNA is great for 3d rendering, and I think taking a classic game type like snake and fitting it into a three dimensional space actually adds quite a lot to the experience.



The core technical trick was keeping the drawing of the ribbon, the input and the camera all in sync as you move around.  You have a bunch of vectors tracking the way things should face, look and behave...and when you move from face to face you change this frame of reference suddenly, you then have to re-orientate them all to respect this new frame of reference, but do so in a nice smooth way so that the player doesn't lose their bearings. That core gameplay and renering was all nicely solved by the end of the fortnight and it was a fun little game.



So once 'last chapter' was done I returned to this and decided to build it out a little more.  I added in splitscreen for local multiplayer which is really neat.  Then I started to think about more levels and unlocks, go check the main page for the sales pitch version of that, 32 levels etc.  The non-sales pitch version is I kind of wish I'd stopped at that point with just the plain empty cube, or maybe just half a dozen simple cubes, with just a little work on tidying the menus.  There is a purity to that layout that I think gets a little lost when I added more elaborate levels with moving walls and switches.   When you start building this stuff out you find you have to revisit code to make loading and parsing more workable, and then more code for controlling how to unlock them.  So it becomes a fair bit of work but I'm not sure it added a qualitative difference to that core gameplay.   It is nice to give the player some goals and it does provide for a bit of single player structure so not all bad.  Plus it did give me an excuse to create a bunch of nice palettes.

The game is done, check out the trailer on youtube. Like 'Last Chapter' it's pay what you like.

Monday, 7 October 2013

Let us begin at the end.

I've recently finished a game called The Last Chapter of Man.  It was difficult.  It was also ignored.  When I started work on it I decided to keep an archive of various build as I went along that highlighted various code and feature implementations.  In so doing at the end  of it all I could go back and create a little documentary revealing what goes into making a game of this nature, seeing broken wireframes  and debug text as it all comes together. I've always been a big fan of 'making of' features on movie DVD's.  A great example is Under Pressure: Making 'The Abyss' and this was my little take on that genre.

watch the world burn


There was certainly a benefit to just hunkering down and focusing on trying the get game done, without worrying about the pr and marketing side.  The big problem is that once complete the game is unknown and quickly vanishes into the digital ether.  It's just not a viable strategy.  So this blog is largely a replacement for that process.  I'll be focusing mostly on my next games development, probably posting once a week, and hopefully releasing builds as when appropriate for people to check out.  And just generally opening the curtains on my game development process.

Find out more on my homepage and try the game for yourself.  I'll post any new blog entries on twitter so you can follow me there.  So stick around and enjoy the show.

/Richard