Friday, 20 December 2013

Gazing at the night sky sphere

Tis the season for builds. I managed to finish a couple of bits of code off before heading home for Christmas.   Couple of things, I got a sky sphere up and working with just a simple dashed line.  Meant I could get rid of the blank plane I had just below the world.  I found I really needed something in the background to help with orientation.  That was just tricky enough that I might do a little write up of the process when I get back in the New Year.

Check out the build here!

Simple dashed lines and a horizon line
make up the sky sphere.


Also has some early work on the menus that I talked a little about last week.  They may not end up looking anywhere like they are right now but I wanted to test transitioning screens on and off and handling the input neatly.  So you can hit 'begin' and it will take you into the gameplay screen, which has a toolbar thing.  When you Escape out of there the camera neatly transitions into orbit and you're back in menus.  This is stuff I worked through in 'Last Chapter' so I'm pleased to be reusing the concepts.

I've been listening to 'Let It Go' from "Frozen" over, and over, and over again while I worked on this...love that song.  I sometimes find it easier to code with music, looking forward to seeing the film.

It's obviously still very rough but I'm pretty happy with the way things are going.  It's slowly starting to shape into something more like a tangible game, and I'm getting more comfortable using Unity too so a nice end to the year.  I'll be away until January, so until then Merry Christmas and a Happy New Year everybody.




Monday, 16 December 2013

UI & game state management

I delved a little into the Unity GUI stuff this week.  I'm not entirely sure what I was expecting compared to XNA but I was surprised it wasn't a bit more...developed I guess.  I don't want to speak  too ill of Unity as the gui code is neat,  but when I think about how sophisticated 3D rendering in games is, font rendering seems primitive in comparison.  It's rendering textured quads, using a bunch of helper methods for positioning and cutting things up.  But if you wanted to scale up or down for different resolutions it can look like mud.    Compare this for example to the text on this web page which is very smooth and highly scale-able.  Games have so many different types/needs/platforms that it's probably not a fair comparison.  I'm just wondering how other engines handle it.

You can still get good results though, here I'm just picking a nice font with some useful coloring.   When drawing frames, you can see below I also get some glitching from the way it stretches the texture, I managed to fix it by altering the texture settings.  The borders don't seem to have tiling at the sides which is a bit of a bummer, I might end up needing to write a bunch of rectangle drawing.  All the other widgets like horizontal sliders, and in particular being able to add colors within the strings are a super helpful.

Unity stretching the ui texture instead of tiling them :(
I spent some time on the game state too.  This is the kind of code that I often get paralyzed by, it's like putting a puzzle together when you don't have a final image to work from.  I'm basing it off the xna gamestate stuff that I really like.  A particular point of puzzlement was the OnGUI() method in Unity.  This is where the UI stuff is both used and drawn, like clicking a GUI.button, but, you as it turns out don't want process other input here like key presses as it runs differently.  e.g. a single key press will fire multiple times instead of once.  And the reverse of that, you don't want mouse interaction on the GUI menus to also then interact with the 3d scene beneath it.    Then there's other stuff like where do you want to hold your list of game objects, how do you handle updating them, keeping track of what's picked, stuff like that I struggle with. 

I might try and get another build done for the end of the week but after that I'll be away for the holidays, so if I don't post again... Merry Christmas!

Monday, 9 December 2013

Picking & Pathfinding

Couple of useful bits done this last week.  I got mouse picking of the regions in Unity using the Mesh Collider.  Each region generates it's own little mesh, which I don't use for drawing, but unity can use it for collision nicely.  For some reason the very first region, [0], doesn't want to be picked even though it's exactly the same as the rest..maybe it's shy.

I also go path finding up and running.  There's a good xna sample that I used as a basis and amended for my needs.  For a goal cost estimation, which you need for some search heuristics, I thought I'd look up and use the arc distance.  I'm getting pretty good at some calculations on spheres but every so often I'll seek out some formula and get a hell of a fright.  Look at this demonic utterance.

kill it with fire!
There's a simpler one below thank goodness.  I now know this is called the great circle distance. (+1 math to me).  I have three different search algorithms to pick from, best first, A* and breadth first.  Best first & A* work fine and are pretty similar, in some cases they won't get the optimal route as you can see below in the two images.  They work pretty well though and I can swap between algorithms...maybe even make it an unlock for a unit, as it gets better at exploring it can use the better search.  Something to keep in mind.  That is all.

A* vs breadth first.  Latter gets a shorter
path but needs a large search space. 

Monday, 2 December 2013

Numpad Forever

New build. After some difficulty and dragging ass I finally got a pretty good version of the keypad movement up and running in Unity.  I know when I play Civilization I favour the keyboard whenever I'm moving units around.  Moving units around is going to be what you spend much of your time doing in the game so I'm working on these lower level systems then building up from it.

Check out the build,  (Instruction on that page but mostly tap the numpad keys)

The rare ideal case - all 8 directions mapped.

Debug build in xna.  The fuzzy values in the top left
map how each node best fits each compass direction.

I'm still finding it much easier to tackle issues in XNA then move to Unity.  In the bottom image I have all the fuzzy logic values printed on screen.  In that particular image, I have to shuffle the mappings a little on the North East to the South as they don't fit neatly, seeing the problem and values all on screen was very helpful in tackling the problem.  The heuristics are broadly:

  1. what directions can these nodes fit?  (calculate fuzzy values for all 8 directions)
  2. where is the best/ideal fit?  (pick the best fuzzy value)
  3. are any nodes not mapped, if so try and slot in.  (use a less than perfect fuzzy value to find a spot) 
  4. failed to neatly plot so plan B.  (use a secondary plotting and allow the player to toggle between)

I'm starting to appreciate why turn based strategy game mostly adhere to nice uniform grids.  Though I've got it largely working quite well there are still a couple of edge cases.  Couple of stupid moment these last couple of weeks.  The directions where half broken at one point until I realized XNA uses a right handed coordinate system and Unity is left handed.  Second one was spending over an hour wondering why icons weren't changing/appearing/vanishing and getting null console messages when I was clearing adding the game object to the script! Then I realized I was adding them in the wrong place...doh.  That's going to be a recurring theme, I'm still a little clumsy using Unity.

Updated to Unity 4.3 with no issues. /hurray

Monday, 18 November 2013

Which way is up?

Not a hugely fruitful week.  I spent some time looking at building ui elements in Unity and by extension how manage game state.  I followed the xna gamestate previously and that was nice, it allowed menus to transition on and off nicely making the user experience very pleasant.  There's a good example of how replicate a manager class in Unity where you create an empty game object and attach a manager, as a MonoBehaviour to it so I'll probably follow that as best I can.

After that I started thinking about how handle movement of a game unit.  I recall reading about how Blizzard made Diablo, they knew the player would spend most of their time clicking and attacking so they got that low level system up and running as quick as possible so they could refine it.

0-7 as directions. sampling different points.

Without a regular grid, either square or hex, it's a mildly tricky problem.  I want to able to use the numpad for a lot of the movement.  So I find North from the center point of each cell then calculate if the angle toward is within a certain range,45degrees. In image_A I'm just using the center point and there 0 would be numpad8 and so on.  This is not so good for most cases, so I also then looked at the midpoint of the edge which you can see the results in image_B.  So I calculate it twice to see what fits best, in some case the center point and edge midpoint overlap.  In image_C I add one more point to sample, which is one third between the edge and the center point of the cell.  Sadly you still end up with broken cases to deal with as in image_D.

That probably didn't make much sense to read.  The gist of it though is when you look at these irregular cells, in your mind you may look and think "well that's obviously north, that's east" etc but actually translating that into something you can encode is not straightforward.  My next approach will be to use some fuzzy logic to define what cells best fits what direction, and in certain cases add a small delay where you can toggle between two destination until the one you want is highlighted.

(Unity 4.3 is supposedly out but my 4.2.2 install says it's up to date...hmm).

Monday, 11 November 2013

From XNA to Unity: That's no moon!

Some good Unity progress to report this week...here is the first public demo!  I got all the voronoi sphere generation code up and running in Unity along with the line and vertex color drawing.  Hurray!  Go check it out and play around with the sphere generation parameters.

Voronoi sphere in Unity 
Moving to Unity is proving to be a very good thing.  While I prefer writing this code with XNA and Visual Studio Express, once I'm into spawning units and creating interfaces I think that's when Unity will really come into it's own.   For this early procedural stuff I'm copying and pasting it into MonoDevelop for Unity once done.  That integration is a little awkward, the solution keeps refreshing and the syncing to dropbox, where I back it up, keeps throwing the odd file in use error.  It's a bunch of minor fiddly stuff though.  You can use Visual Studio with Unity but I was getting linebreak errors and other quirks, so it's seems best just to use MonoDevelop which is...well it's ok.  For the really important step though, the build & deploying of a game, Unity seems tons better.

Tortured indices
Couple of glitches for the week, got my indices messed up on the first attempt but that often seems to produce interesting results anyway.  Not entirely sure how Unity handle mouse picking, I think I'll need to create static rigid bodies for all of the voronoi regions, and I presume it has it's own octree implementation which is nice.  That crossover between XNA  and Unity might be a little tricky to translate.  Next step though is to get a unit up and moving around.  Then we can go exploring the surface of the sphere.

Monday, 4 November 2013

From XNA to Unity

I spent part of the week trying out Unity and it's definitely a goer.  The main issue I investigated was being able to generate meshes when the game runs for building maps.  The mesh class is thankfully open for adding your own triangle and line vertex arrays.  There's a great set of videos walking through parts of the process.  That was another nice thing about Unity, it's obviously quite popular now and there's a ton of help out there for all sorts of areas you might need help on.  I went through the opening tutorial, where you make ball roll around, and the final build step already seems tons better than the XNA equivalent.  Plus it supports Mac & Linux as well and a bunch of mobile platforms too.  It looks pretty great.

I wrote a quick Matrix class to replicate some the XNA methods I was used to, namely the CreateRotation X/Y/Z methods and CreateTranslation method.  You can download that class from my site.  Unity totally has the same functionality for transforming, rotating & scaling, it's just down to habit on my part that I like those methods separated out.

One major bump in the road though was the convexhull/triangulation library I was using.  Knowing this was going to be important I built the library in MonoDevelop and added the dll to the Unity project pretty early on and it compiled no problem.  Fast forward and couple of days though, when I went to actually use the code it threw an error.  Oh...crap.  The MiConvex code was written in .net 4.0 and Unity uses 3.5.  So I find the setting to change the build target, and I'm already starting to feel out of my depth, and it wouldn't compile as it's using some specific 4.0 features.  Double...crap.  I looked into trying to rewrite the few parts that used the specific 4.0 features but it was just above my skill level to decipher.  Triple...crap.  It's really clever code, and the only reason I'd managed to get the voronoi sphere working before was because I'd found that code to handle the tricky generation part.  So I was back to square one all of a sudden.

Went back to blindly stumbling around the web trying to think of my next step.  I had a light bulb moment when I found a site illustrating different algorithms for building a convex hull.  Stepping through the incremental version, which is this nice simple brute force approach, it finally clicked how I might go about replicating the triangulation...and thus the voronoi sphere.  Check this out!



Success!  I wrote my own convex hull triangulation algorithm.  Let me repeat that, I wrote my own convex hull triangulation algorithm.  I'm pretty sure I got enough experience points to level up in programming...I put the talent point into 'luck'.

It actually works super fast for number of points I'll need, showing off the animation because it looks shiny.  Also shows that even if I where to slow it down and it took 5/10seconds  to build a level, if you can turn that into a nice animation for player it's a good trade off.  Plus it only has to do it once at the beginning of the game.  That build is still done in XNA and I'll hopefully get that into Unity shortly.  That's probably the pattern I'll follow, where it's a little easier to do the more code focused work in XNA and then port it across, and then I can use all the nice Unity features, like particles, input etc for the rest.

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