Deep Loot Coder Diary #2


This is part 2 of my coder diary.  Part 1 is here.

Finding time to keep these updates regular is proving to be difficult.  Anyway, I’ve got quite a lot done since my last diary a few weeks ago.  I’ll go through the new features in more-or-less the order I implemented them.

Prefab spawning system

In my last entry I ended by saying my next step was to add support for authored content.  Dave and my plan was always to include some element of authored content in the procedural generation.  This was an attempt to have the best of both worlds in our content.

What the system does, is for the most part it generates randomised tiles based on parameters in an XML file as I described in the last diary but from time-to-time there are opportunities to spawn large sections of content in one go.  When this occurs I create these chunks of content based on templates which are also defined in an XML file.  These templates look a bit like this:

Screen shot showing an XML file in an XML editing program

Here's what the prefab XML looks like

The XML describes each template as a series of rows of comma-separated numbers.  Each number represents a tile in the template.  Zeroes mean tiles that will appear empty in the prefab and ones represent tiles that will be replaced with a solid tile that will be grabbed from the content generator.  This is done so that the tiles will be appropriate for the player’s current depth and also nicely randomised so that it’s not too obvious to the player that some of the content is template-based.

The only time I can actually guarantee that spawning a prefab will be fine is when we’re building off the left, right or bottom edges of the map boundary.  This is because with my node-based system it is quite time consuming and complicated to work out whether there are any tiles already occupying a particular position/space in the world.  This would make trying to ‘slot’ a prefab into a gap in the map too complicated.

I also decided that there should be another type of authored content.  The type I just described is intended to make the standard map generation more interesting  for players, without drawing attention to the fact that it is template-based content.  However Dave and me also wanted to be able to have content that was quite clearly a ‘one off’ instance and it wouldn’t matter if it looked authored.  This is how we plan to create our so-called ‘Easter Eggs’.  These areas will be authored sections that appear exactly as we created them, i.e. without the content generator changing the tile types.  Easter Egg sections will also have specific art assets and background details.  I haven’t started work on this yet but it occurred to me while I was writing the prefab code that the Easter Egg system could be implemented using mostly the same code.  This may be especially useful as we may want to use content generated tiles around the edges of an Easter Egg section in order to blend it into the other tiles at the player’s current depth.  Hopefully I will be able to report on this in the next diary.

 Adding the player character

After I managed to get the prefab system working, Dave and me agreed getting the player into the world and moving around with the touch screen was our next priority since this would help us work out how big the player and the tiles should be.  There are quite a lot of considerations to make when deciding our final scale, for example:

  • We want the main character to be nice and big on screen for aesthetic reasons
  • The tiles need to be touch responsive since the player navigates the world by touching the tile they want to move to – this means the tiles need to be at least as big as a well-designed UI button
  • The smaller the tiles are, the more we can fit on-screen and this might help the player plan their route through the world

After a couple of builds at different scales, we’ve settled on a scale that suits the iPhone/iPod Touch.  We’ll probably need to go through this again when we start looking at iPad resolution(s) – I don’t even want to think about Andoid at this point!

Screen shot of game engine showing the player character in the middle of the screen

Here's the player character moving around the world

Detecting tile taps

My node-based system makes it quite difficult to find out if there’s a node at a particular point in the world.  I thought this might make detecting taps on the screen quite difficult.  It turns out it wasn’t so bad since my system does at least guarantee that the screen is filled with nodes (even empty tiles are still nodes).  This meant that detecting which tile the user had tapped was a case of starting from the top-left node on the screen (which I track constantly) and walking right from node-to-node until I equal/exceed the mouse x coordinate and then doing the same downwards until I equal/exceed the mouse y coordinate.

Path finding

Deep Loot is going to need quite a lot of path finding.  For example the player character will need to find a route to any tile that the player might tap.  Also, enemy characters will need to path find towards the player and we may also need it for other purposes since in my node-based system the only way to work out if there is a node at any given arbitrary position is to attempt to path find to it.

Path finding in general is a pretty well explored topic.  I decided to implement A* path finding and used this resource.

My path finding system is pretty much exactly as documented in that tutorial.  The system worked very well as my world representation is already node-based!

The only tricky decision was how players might want to navigate the world.  A major element in the game design is that the player uses up air for any action they perform e.g. moving one tile uses up a bit of air, so does combat and so does mining.  Since mining uses more air than walking, players will probably mostly want to walk to their target destination.  This probably means that players will expect the path finder to pick routes around solid tiles.  However, in some cases mining through tiles (and using extra air to do so) may still result in less air usage than taking the long route round.  Also, consider that there may not be a clear route to the destination.

I decided that it was worth adding an option to the path finder to ‘auto mine’ or not depending on a control preference setting so players can choose whether they’d like the path finder to mine for them or not.  With auto mine on, the player character will choose the route that has the lowest ‘air cost’, mining if required to get to the destination.  With ‘auto mine’ off the player character will only take clear routes and will not mine unless the player manually taps minable tiles.

Auto mining does have a problem if there is no clear route to the destination though.  In which case the player character moves as best it can ‘as the crow files’.  I could allow the player to partially follow a generated path but this might actually result in the player walking in totally the opposite direction and then stopping!


We’ve decided to use TestFlight for distributing test builds of our app.  This is because it’s easier than sending out IPAs and syncing with iTunes etc. to get builds on to various iOS devices.

If you make a build for TestFlight then it has to be an Ad Hoc build.  This is possible using FlashDevelop.  It means faffing about with the iOS provisioning portal and creating suitable certificates and provisioning profiles etc.

Trying to get this working took me a whole day.  Though the biggest problem we had was when I got the Ad Hoc builds onto our iPod Touches, they misbehaved.  They installed and ran but didn’t work the same as the development build.  It took me ages to track down the problem and even now I don’t know why the current builds work – it may be a weird bug in the AIR compiler.

Anyway, it turns out one of my functions was returning null when it couldn’t possibly be.  When I traced out from the function it was all correct and as expected…  And weirdly, worked perfectly but only when tracing the output – if I removed the trace statements the function misbehaved again!  This issue is still unresolved so I’m putting the code here just in case someone reading this can see the problem!

 * Returns the tile that the specified point (in screen coordinates) is over
 * @param x The x value of the point in screen coordinates
 * @param y The y value of the point in screen coordinates
 * @return A reference to the tile - null if the method fails
 public function getTileUnderPoint (x:int, y:int):TileNode {

      // The supplied point is effectively relative to the viewport
      // so we can easily work out the world coordinate
      var worldX:int = this.viewPort.x + x;
      var worldY:int = this.viewPort.y + y;

      // Now starting from the top left node we can find a tile that
      // contains the specified world point

      // Find the column
      var isColFound:Boolean = false;
      var isRowFound:Boolean = false;
      var currTile:TileNode = this.topLeftNode;
      while (currTile) {

           // Matching column?
           if (worldX >= currTile.pos.x && worldX < currTile.pos.x + this.tileWidth) {

                isColFound = true;

           // Move right
           currTile = currTile.leaves[1];

      if (isColFound) {

           // Find row
           while (currTile) {

                // Matching row?
                if (worldY >= currTile.pos.y && worldY < currTile.pos.y + this.tileHeight) {

                     isRowFound = true;

                // Move down
                currTile = currTile.leaves[2];
      else {

           // No tile found
           currTile = null;

      // For some reason, removing this line causes ad-hoc builds to misbehave..!
      // I have never experienced anything like this before!
      trace("Please leave this trace here if you want the ad hoc build to work!");

      if (!isRowFound) {

           // No tile found
           currTile = null;

      return currTile;


If I remove the trace near the end of this function, then in an Ad Hoc build this function always returns null which results in the app never responding to mouse input.

That’s it for this entry

Thanks for reading, I’ll post again soon!