Game Dev

Runners v0.0.5

It's been another hiatus since the last update but there's been a fair amount of progress made recently.

I've finally gotten around to improving the UI in some areas. The task screen has been completely remade to remove the majority of the text and use icons instead. Tapping on an icon will show a text popup with the description.

v005 Task UI

Another important addition has been changing how text is stored, it’s now done in a way to allow automatic language switching within the game based on the device.

The map has also been completely remade due to software issues (more on this below). During the recreation, I’ve decided to add in a few different biomes to help split up the map. This still needs a lot of work but the variety of environments will help to make the world a bit more interesting. It’s still a work in progress so the edges between the biomes still needs work.

Biome 1Biome 2

Alongside the actual game development, the tools used to help create the game have also changed. Originally I was using Tilesetter to create the map but unfortunately due to bugs in the software, it caused additional work with parts of the map having to be recreated multiple times. I’ve since moved over to using Tiled which does essentially the same task as Tilesetter but appears to be still in active development. On top of that, Tiled also has a lot of features already implemented which are still on the Tilesetter roadmap which I’ve been waiting for to help with production.

Recently there has also been a lot more planning on the whole project including features to add and what needs fixing/changing. One essential point is the pricing. Originally it was planned to make the game completely paid but now it will be a freemium type game with ads that can be removed with a one-off payment.

Runners v0.0.4

There's not a huge amount to see in this update as most changes are behind the scenes or still needing some tidying up before being showcased.

Potential Inventory

The way the inventory and tasks worked together was somewhat flawed when adding a task which had requirements. The issue was that it was checking the current item quantities instead of what the runner would be carrying at the time. The solution was to create a 'potential inventory' system which would calculate what a runner would be carrying at the time of the task if all previous tasks had been completed.


A simplistic dialogue system has been added, only for the tutorial at the moment but now it's in place it can be used elsewhere it's needed. The tutorial itself still needs to be updated to be more informative, currently it just tells the player the items they need to complete it but I plan to change it so it explains the UI as well.

Map Updates

The majority of the map updates are still a work in progress but in the mean time I've added a new building type, the tavern. The tavern allows you to hire more runners and therefore allows you to perform multiple tasks at once. A few more random houses have also been thrown onto the map which at this point purely act as locations to receive quests.

Exitus v0.0.1

Over the last week I've been starting to convert Exitus over to libGDX & Kotlin. During the process a couple of additions have also been added.

Not just squares

The first noticeable change is that the city generation now allows non square buildings to be created. This was on the list of changes for quite a while but it's been added in during the rebuild. You'll have to excuse the textures, it's still using the whole spritesheet as the centre textures for the building sections.


The other change is the appearance of buildings. The building models now have two different height walls for the internal and external views. Outside a building has full height walls but moving the camera inside the building cuts away to show the current floor. The left image shows the internal view and the right image shows the external walls (in the top left).


What's next?

After finishing the basic structure of the building, the next step is to add neighbouring city block generation for an infinite map.

Runners v0.0.3

The main update for this version is adding an info panel for the runners and locations. It provides the player with additional actions including centring the map on the selected element, creating a task for a runner from a location and opening the runner's inventory.

The above show what will appear when a runner is selected, the icons are an image of the selected runner, the tasks button and the inventory button. The sizing and position still needs a bit of tweaking as you may have guessed. You'll also probably notice that the runner has a different appearance too. The core method for allowing different skins is now in place so you can easily identify which runner is which (when you can finally have more than one)

I mentioned the inventory earlier which has also been put back into place but it's currently being scaled so the text is a little blurry

Another important addition for this version is getting the saving working again which required a complete remake for the GDX infrastructure. Like before the gdx update the camera position and the runner data is saved.

Runners v0.0.2

The most visible change made this week is another one which hadn't been implemented in the original version and that's background animation on the map. This is really another reason why it was decided to move over to gdx, although possible with the original version it would have been time consuming and gdx has made it a breeze to get working.

Another change which is being worked on is adding landscape orientation support. The original version was purely portrait and adding landscape was always an afterthought but being that the UI is being rebuilt anyway, it's the perfect time to get it plumbed in.

The rest of the development has been migrating elements from the original version into the new. A slow gradual process.

Runners v0.0.1

You're probably wondering why after the previous posts about the runners game we've landed at version 0.0.1, well there wasn't any sort of versioning before and it's being remade to a degree. The way the original version was put together made it very difficult to implement zooming on the map. Because of this, zooming was one of the first things to be put together in the new version.

It was also made with my own implementation of OpenGL which was still pretty buggy so I've decided to switch it over to use libGdx. Now the new map is working the way I want it to I can start merging code over from the previous version.

Runes v0.0.2

The main noticeable change this week is the introduction of animation for both the creatures and the background. Previously the creatures would instantly move to the selected location but now they follow the path changing direction and displaying an animated walk cycle. A test area of water has been added to the centre of the battlefield as a testing ground for both an animated background and to act as a blocked area for pathfinding.

Another visual change is the selected creature details box has been styled (slightly) and also works as a quick link to centre the camera on the selected creature.

Behind the scenes a major change has been made to the creature movement and action point system. Previously creatures had one movement point per round and the action point accumulated, now it's completely custom for each creature and non creature cards now have mana and/or stamina requirements. Creature movement is his based off stamina but based off movement stamina, meaning big slow creatures with high movement stamina won't be able to move far but can do some devastating high damage stamina based attacks.

Runes v0.0.1

Learning libGdx is something I've been meaning to do for some time now and I've finally gotten round to doing it. I decided to convert an existing project instead of creating something from scratch and spent the last week or two working on it. The previous game was purely for Android but using Gdx allows the project to also be built for desktop and iOS.

The initial idea for the game was to create something which was essentially a TCG with an additional layer of strategy by having a playfield to move characters around. Each character would have their own deck and characters of different types would have decks containing different cards.

The first version was created as just portrait for mobile but being the main structure was being remade I made the decision to cater for both portrait and landscape, especially with the option for building for desktop. Originally the battlefield was going to just be a five by eight grid with just the card icons as movable tokens but while working on the Gdx implementation I thought it would be better to use separate battlefield sprites and create an actual level with obstacles to maneuver around. In its current state the creatures gain one action point per turn and can move one space each turn but they cast as many spells they have action points for. After thinking about how this plays out I think it's going to change in a future update

Another visible change is that I've decided to give a 'demake' effect to the card images by changing the graphics to a 16bit type appearance. They all still need to be tweaked and I need create a proper palette for them.

Currently there's only a few different cards which were used for testing. This mainly consisted of spawning creatures and affecting them with effects. Once everything is working correctly with Gdx and I make a few changes to some of the game mechanics, I can continue to add new cards.

Runners - 2020-01-16

There's just a couple of new things to showcase after all this time which are the inventory UI and scrolling support. A fair amount of work was put into the tutorial but has been put on hold for the time being.

A bit more map work has also been done to start planning the position of additional locations.

Runners - 2019-11-11

The bulk of the progress made this week is with the UI. I've completely remade it all to use a base display to keep it consistent for each view. I'm not too happy with the buttons and there's a little bit of a stretching issue but the new changes will make updating this in the future much easier.

Other updates include creating a dialogue handling system for displaying multiple strips of text which will be used for the tutorial and quest information. Hopefully this will be finished next week

Runners - (2019-11-03)

Over the last month I've been revisiting the Runners game and quite a lot has changed since the last post a couple of years ago!


The first big change you'll notice is the tile set has been swapped out for a brand new one. The new tiles blend together better than the old ones and will allow more interesting environments, they generally look a bit better than the last as well.

Under the hood

Now this is where the majority of the recent changes are so I'm gonna break it down a bit:


The graphics are now being rendered with OpenGL which will help with general performance and allow some advanced graphical techniques


The UI originally was a mash up of Android components layered on top of the map canvas which was a pretty nasty way to do it. It's now been completely redone within OpenGL to make it more fluid.


The quest system has been completely rewritten to allow different types of objectives to be part of a quest and to give prerequisites to each objective if required

Exitus - Reactive pathfinding & FOV

The last week has been mostly spent working on two core mechanics. Although both could still do with some tidying up, they're both functional.

Reactive Pathfinding

The idea behind reactive pathfinding is that the character will keep checking their path as they progress down it to see if the route can be optimized. The result will therefore be a shorter path and hopefully one which looks more natural.

Field of View

Field of view is a key mechanic so the characters can see enemies and know how to remain hidden. The method was completely changed from the original. Instead of doing a periodic check along an angle like what was originally used, it now uses a line intersection check to see where the ray hits a wall. This will give a smoother line next to walls.

Original FOV


What's next?

Well now the field of view is in place the next step is to add in the mechanics of what to do once something is seen. This will be the beginnings of adding in some sort of simple behaviour to the characters.

Exitus - 2019

It's been a while since working on Exitus but it started playing on my mind over Christmas as to why it was abandoned. The main reason was due to the time to take fixing bugs and not progressing, these bugs were mainly due to trying to build something too quickly and the structure becoming difficult to maintain.

It was therefore decided to reign back some features for now and rework them. It also allowed me to familiarize myself with something I had been interested in for a while, WebGL.

After building up the core groundwork for WebGL I began incorporating previous pieces back into the new version.

So far the city generation is in place but limited to just one block, there's also no internal structure which was one of the pieces which needed the most fixing. The path finding is also in place but being worked on again to give it some well needed improvements, the main being implementing reactive path finding to make it look more natural.

Exitus (2018-05-29)

After spending a fair amount of time on the perimeter buildings and not getting it to work nicely I've stashed it for now to work on other pieces.

I've added some basic characters, enemy and player. Currently they're just coloured circles with a code showing their field of vision. If a player goes into an enemy's FOV then the player will turn white. Just so we know they've been seen, in the future they'll start chasing the player.

Players are black and can be selected, once selected they can have a path created by clicking on the map. Enemies will just move randomly around the map.

character FOV

Exitus (2018-05-22)

I've spent a little time working on a project to learn ECMA6 and the process of transpiling it down to ECMA6. The project is essentially rewriting a collection of code I've previously written in other languages and merging them together to play nicely. I'm now considering developing it further into a survival game.

So far I've put together the bulk of the city generation and the polygon path finding. The polygon mesh currently consists of the roads and a very basic algorithm for building layout. In the image the polygons are only visible for the current city block you're currently in. This is only temporary so you can see the room layout as there's no building textures yet.

Screen Shot 20180522 at 170029

I had originally thought that having procedurally generated building layouts would be good but I'm now thinking that having preset layouts would be a better idea.

There's some lag while moving around the world which I've got to address and I've still to combine the perimeter buildings as they're currently split by the city block edges. I'm also eager to get some sort of gameplay added in.

A working example can be viewed here and the code is available on github

Map outline completion

The map outline has now been completed so I can finally start concentrating on the actual layout and finer details of the map itself.

I've also finished the import from Pyxel Edit into the game and the video shows a quick device recording so apologies for the jerky movements. You'll also have to excuse the black right border, it'll be covered by UI so it didn't need to go to the edge of the screen

One minor issue which is going to annoy me is there's a small line between each tile. This is a pixel or so from the Java bitmap selection functionality I'm using to get part of the tileset onto a Sprite. Not a huge issue, it's just going to bug me til it's sorted.

Runners Map Implementation

Up til now I've just been developing on a testbed 20x20 tile grid. This has been fine for testing but I wasn't sure how well it'd run with the real map size of 254x212.

Method #1 - one big canvas

The original method was using one big canvas and drawing each tile to it which was fine for the small number of tiles used for testing. For the final number of tiles however resulted in instant failure due to bitmap size restrictions. I had considered using multiple smaller bitmaps but went on to trying the next method

Method #2 - individual tiles

The second method was using a separate sprite for each individual tile instead of one giant one. This had marginal success as in it didn't fall over instantly. Instead it was just horrifically slow and made the game unusable. I spent quite a bit of time diagnosing bottlenecks and trying to speed things up. The main idea was to stop rendering all the tiles which were off screen but there was still the overhead of the tiles existing in the first place. This led me to come up with the final method

Method #3 - reusable tiles

The final method came from the idea: what if I didn't need all the tiles created at once, all I need is enough tiles to cover the screen then reuse them when they're out of sight. So now if a tile moves too far to the left and off the screen, it redraws and repositions itself to be the next tile on the right.


In this example, there's only ever 80 tiles (8x10) yet I'm able to create a map of all 53,848 tiles with minimal overhead.

Runners 2017-11-17

Over the last few weeks I've made a little more progress on the map but most of the time has been spent on the code base. Map-wise I've continued working around the map to get the edges in place and started the rough placing for a mountainous path (the swirly bit). mapbig

Code wise I've been reworking the tasks to allow building up a task queue so you can set your runner to do multiple tasks without interruption. They still need the option to view active tasks as well as remove or edit them.

I've also added in basic Quests. They're randomly assigned at the moment but I'll add in some structure later on. They're automatically assigned upon reaching a location and they have a requirement of delivering one or more of a specific item. You can then assign the task to a runner to deliver an item if the runner have it in their inventory.

It's all pretty rough but at least progress is being made.

Pixel map

I'd started working on an idea for a game a while back and it faded into the background but now I'm back to working on it. The main concept is a supply / demand style game where you have to obtain specific items and deliver them.

It's going to take place on an island which I had originally intended to be generated but on reflection it wouldn't add anything so I'm rethinking it to be a static map. For this I started out with looking for an island map I liked the look of for a starting point and I went with Lombok in Indonesia.


I've been using Pyxel Edit to create a tile map and tile over the original image.


I've created about thirty tiles to handle the majority of angles of the edges but I'll probably create a few more for variety. Once the outline is done I can start adding some additional features.

Pixelnaut - We've got movement!

It's typical that as soon as I commit to start doing device captured videos, my phone breaks preventing me from doing them. It's been replaced but unfortunately the update to lollipop hasn't been pushed to it yet so the screen recorder doesn't work.

The device shadow issue on the previous video is due to the shadows overlapping. This is because each shadow is being ray-casted from each shadow object and the semi transparency is building up on the overlapping shadows. Ideally the shadows should build up one mesh to keep all the shadow elements on the same layer.

No more work has been done on the space side of things, mainly planning and coming up with ideas. A few changes have been made to the level parts. Player movement has been added along with direction swapping and the wall tiles have been corrected. There's are few odd tiles in place but they're just placeholders for elements still in development.

I thought the game needed a name so came up with 'Pixelnaut' (pixel as it's using 16bit sprites and naut as in astronaut), not completely sold on it but it'll do for now.

Navigation mesh

Over the last few weeks I've been trying my hand at rigging up a basic navigation mesh for path finding. Using a navigation mesh should allow a more natural feel and responsiveness to character movement while moving through the map.

The general theory is quite straight forward, polygons are created on the walkable areas of the map and are linked together if they're direct neighbors. The pathfinder then uses the edges of each polygon to navigate through the mesh.

The initial implementation of this is quite basic and only uses the centre points of each edge so the paths used still look like they're on rails but I plan to update it so the whole area of the polygon is used.

The red lines in the examples below are the paths generated from the start to the end points, not elegant but a good start

Basic Navigation Mesh

Shadow Bug

Well it turns out that there was a major issue with the new shadows where they didn't maintain the correct positions if the parent was moved. It was visible in the previous video as the parent was situated at 0,0.

A little annoying but glad it reared it's ugly head sooner rather than later.

Onwards with pathfinding, currently working on a navigation mesh for path finding.

ZRPG September 2014

Its been a few months since any sort of update, mainly due to other commitments but I was also struggling with getting my head around how to tackle randomised building generation. At this point my plan of action is.... I don't. I can get away with having a few different variations of each building which will do for now. In the future I could always create an algorithm to make it completely random but that'll be saved for another day.

A couple of days ago I began writing a separate prototype for the buildings which includes a new method for handling shadows. The new shadows can now work with any polygon which should work nicely with the effect I've got in mind for the game's atmosphere.

Below shows the prototype in action, it achieves the effect I was after and only uses 162 triangles but this will likely multiply five fold once the textures are sorted out and extra elements like furniture are added.

I know the textures are ropey but it's just a quick prototype to demo the progress. It's also a good testbed for building related feature development.


Over the last month I've been working on a new project. Usually I'd try to resist starting a new project as long as possible but feel that this could be a rather quick game to create.

It originally started off with trying to think of other ways I could reuse my city generator and I came up with a city where enemies come in from all exits and your squads have to fend them off. There will also be survivors in the city which can be rescued for cash. If I were to give it a genre it'd have to be an action strategy with hints of an unconventional tower defence.

Progress is coming along quite well, although there's not a whole lot to show at this point. Units are controllable with pathfinding and enemies will wander around until they see a unit and attack.

There's still a lot to get done but its a good start, I should have something to show shortly.

Yet another new perspective

I've been taking a look at the game and thinking about pieces which dramatically increase development time and not really essential to the game. The key piece is the 3D side of things which although is a rather nice feature, is somewhat expendable.

Looking at games like Hotline Miami and Teleglitch, we can see that they're still amazing games even though they're of a top down 2D perspective.

With this decision in mind I started looking into the Starling 2D framework which integrates the 3D stage to utilise the GPU in 2D rendering.

After getting Starling setup its really quick to start working with as it uses the same variable and function naming convention as core AS3. Unfortunately it became apparent too quickly that my intentions for the framework were more than the intended use. Once the city generator was implemented, the performance went down to half which was seen using the core 3D previously. I'm not saying Starling isn't good, for most projects its ideal, but unfortunately its not cut out for this project.

This has resulted in me creating my own version of it. It'll conform to the AS3 functions to behave in a similar manner to using the inbuilt 2D engine but for it to easily extend the standard model to easily create complex sprites.

ZRPG (2014-01-06)

So at the end of the last year I entered the Oryx Trial with a somewhat poor entry and unsurprisingly didn't win. I didn't expect to but the point of entering was to push myself into writing some classes which would be used in my other game. I must say it's also inspired me to get back into the game development side of things.

Since the new year I've made a big push and managed to get the random city pretty much sorted and integrated with the 3D stage. Now although this is pretty much regurgitating previous posts, a lot of work went into rewriting big ol' chunks of code for it to work more accurately and quicker.

Now the main thing that's up with this example is that there's a delay when you hit the edge of the city block, this shouldn't be a huge issue as I've purposely scaled the map down to down to show this. The map is really ten times the size so by the time the player reaches the edge of the map, the neighbouring block would have already loaded (in theory =P) The way the map works is on a 9x9 grid, when the player reaches half way through a block it starts loading in neighbours. The delay is present as threading in AS3 is still in beta so I'm currently daisy-chaining the processing off the main frame rending. When the player moves to a new block, the loaded blocks shift over so only new blocks have to be loaded. This now does mean that you can walk infinitely in one direction and the city will keep generating buildings around you.

There is a minor issue where some buildings don't get loaded which I shall have to look into but I'm happy with the progress at this point. There are still a few pieces which can be optimised at this stage but I thinking I'll work on a different piece of the game for now. I'm really hoping to have something fresh for the next post as this is yet another post which contains the same as previous entries but with minor updates.

Roguelike (2013-12-24)

Well I submitted by game last night but have mixed feelings about it.

I'm pleased with the amount I got sorted with the limited time available but I'm not happy with the quality, especially towards the end as I was having to cut a few corners in order to get core functionality in place.

For example, the inventory & UI in general was very slapdash, levelling and experience of the player and items was somewhat unfinished & untested and there were still quite a few noticeable bugs in place.

The main bug is still the shadows, they still allow defogging of tiles behind walls and there's a weird ghosting issue where you can see ghostly enemies on the fogged tiles but they're not there when you get to the tile.

Since the last update I've added in enemy AI, they'll intercept you when they see you and go to attack. If they lose sight of you for too long they'll lose interest and stop chasing. I quickly added in food to heal the player.

Anyway, for anyone wanting to see what was submitted, you can download it here

Roguelike Development (2013-12-08)

Progress of the roguelike has been slow but steady, not really had a huge amount of time to spend on it but happy with what I have managed to do.

I thought I'd post as a slight milestone has been hit and that's shadows & fog of war. I remember spending many hours before trying to get a good 2D shadow algorithm created and failed due to heavy resource usage but I've come up with a new method which works quite well.

It still needs a little tidying up but it's a start.

Trials of Oryx

While I was looking at sprites for my rogue like game at Oryx Design Lab, it turns out that they're doing a competition called Trials of Oryx which started on the day I started looking into doing the game, what are the chances?

I've taken this chance to accept the obvious fate and join in with the challenge. Could be tricky with a minuscule amount of free time I have for such things but perhaps it's the inspiration I need to keep at it.

I'll try to keep updates coming but for now, I've got a game to make =)


I love playing the majority of video game genres but think out of all of them, RPG games are probably my favourite game genre and delving down, rogues would have to be my favourite sub genre.

For those not in the know, rogue like games are classic dungeon crawlers which are randomly generated and notoriously difficult.

It'd been a while since I'd played one and once I'd delved in, I became obsessed. After a week of being reminded of the unforgiving difficulty it dawned on me that a started building a dungeon based game many moons ago. I checked my project folder to make sure it was still in existence, luckily it was.

Although it's in the very early stages, the key functionality of the seeded random dungeon generator was pretty much in place. Other pieces in place is the beginnings of the path finding and sprite loading.

As you can see it's all rather barebones, the same one sprite is used to represent the player and the enemies, stairs are yellow tiles & doors are green. Where I left it, it was mainly the dungeon generation which was being developed with everything else to be thought about later on.

I'm quite keen to pick this project up again so hopefully I'll have more updates in the near future while the enthusiasm is in full flow =)

Game Development (October 2013)

Not too much has changed over the last couple of months, nothing at face value at least. I'd been doing some testing of the game on a tablet and wasn't completely happy with the city transition. On the mobile device there was a slight lag when moving between the city blocks as it was generating each city block instantly which had an effect on the performance. In usual cases this would be solved by threading but unfortunately in AS3, threading is currently only available in beta for android applications and currently in development for iOS.

After some time thinking of solutions I came up with changing the city generation from using standard loops which would run through everything there & then to using the game's frame rate as the loop instead. This would result in spreading out the processing over multiple frames allowing to maintain a good FPS. The only drawback of this method is that it will take longer for the city blocks to be generated which shouldn't cause too much of an issue, the city will be large enough that the generation would have finished long before the player reaches the edge of the city.

There's been two other relatively small changes, the first is random buildings which is quite significant for a random city generator. The second change was so buildings at the edge of city blocks get grouped together into one building instead of fragments.

random city buildings

This is a rough example just implementing the classes used for the city. The different coloured squares represent the different building types and the roads poking out the sides are the roads which link up to neighbouring blocks.

Back in the zone

For the last couple of months I've decided to take a step back from the game development and work on a new site. When progress seems to stand still for too long I tend to shift onto something else temporarily which usually leads to it ticking over in the back of my mind.

In the mean time I created a new site for snippets ( not really relevant but more of a shameless plug =)

Anywho, while working on the site I was also thinking about the game and have made yet another u-turn and decided to go back down the 3D route. I've thought of a way to turn it into more of an action RPG style game which should also help preserve the survival aspects I'm wanting to maintain.

Upon getting back into the 3D game development state of mind and starting to implement these new ideas, it dawned on me that there were a couple of underlying issues with the setup of my existing work. Although I did spend a little while trying to correct these issues, the decision was made to start afresh & gradually import the existing work into the new workflow.

Although there's nothing much to show at this point, there should be soon =)

Game Development (June 2013)

Well it doesn't really feel like there's been huge leaps & bounds in anything to see over the last month but the basis of some pretty important pieces have been put into place.

Please note that the video is also zoomed out to what it will be, this is purely to show how the tiles are working. The first noticeable change will be the buildings but they're merely placeholders for something better which is why they look pretty flakey. They're currently created based on individual tiles which won't really work as a whole as they're going to need to know which building type they're part of and which tile of that building. There's also the issue where buildings at the edge of a city section have a wall through the middle. The next thing to notice would be the enemies are back, even if they are very basic in their current state. At present there's a set limit of five which will randomly spawn on the level load and respawn when they're knocked off the map. They move very linearly, as in a randomly picked direction and they'll travel in that direction non-stop unless you get close enough for them to follow you. They can also be targeted and attacked by the player, though this is a very primitive process as it currently stands.

What's Next?

Like I mentioned earlier, the buildings really could do with a lot of work but at this point I'm thinking that the basics of different building types would be good to get in place. Another important item on the todo list is obstacles and let the player walk through walls =)

A new perspective

After spending an excessive amount of free time trying to get 3D picking to work without any success I decided to go back and revisit the original plan.

When I first started out planning this game I was originally torn between two very different directions. Firstly there was a more old-school type RPG style using point & click on an isometric field. The other was more of an action RPG where the player would be in direct control of their character. Originally I was leaning towards the isometric as I thought it would work better on touch screen devices and there were certain aspects of gameplay could be integrated. For example, I wanted ammunition to be relatively scarce and for the player to weigh up using valuable ammo from a safe distance or going in for a melee attack. I think this idea works better in a classic RPG style due to weapon familiarity could then be added to provide better accuracy and damage.

Although I preferred isometric and thought it would work better, I chose to go with a top down approach purely out of laziness which was probably a bad step. I knew that if I used a top down setup then it would allow me to adopt a GTA style of sprites where only one direction would be needed and rotated. The isometric view would however need a different graphic for each direction.

During working on the isometric tiles I revisited the AS3 graphics API which I've not really looked at much for the last few years and there are a few neat feature which have been added in. One which I'm now using is the ability to use texture triangulation on the 2D canvas in the same way you would in the 3D stage. This means that I can reuse my road texture which could create all road tiles from just one square image.

You may be wondering what's going on with the tiles, the lime green & white set is the old tiles which was loading in each city block as it was in the 3D version. The dark green tiles is using a new technique which consists on only 100 tiles which dynamically update their positions and tile types based on the player's position. Doing it in this manner should be more memory friendly as there will be less creating / removing and fewer tiles overall.

Dynamic Roads & Picking

It's been a slow couple of weeks on the game development front which has mainly been down to trying to get 'picking' to work. I was thinking about the game play style and think that I'd prefer it to be more strategic than action and decided to change it to a point & click style game. This would also be a better choice as its mainly been aimed for mobile devices.

The main issue with this decision is that because I'm using a 3D environment now, I need to use a process called picking. Picking is the process when you click on a position of the screen and it calculates which object in the 3D environment has been clicked. This is all new to me and left me feeling quite out of my depth. I did manage to find an example of picking but it didn't play nicely with my current workings when trying to add the methods to my code. After a full week of free time hours try to getting this working, I admitted defeat which doesn't happen too often. The decision was made to take a look into a premade 3D engine so I started looking at Away3D.


Looking at the examples on the Away3D shows that picking is alive & kicking and having a quick go at creating a testbed seems like a quick & easy solution to creating a 3D environment. My first issue was that there's not really a great number of tutorials and the genreal help seems to be lacking, that is unless you want to pay for their support or purchase a book. At this revelation, the tenacious side of me kicked in again and I've decided to take another look at getting my own version working but in the mean time, take a break & make progress in other areas.

Dynamic Roads

While looking into the picking, I came to the realisation that the different sections of roads being used could be generated from just one tile. Being that the 3D models use triangulation, I could create a tile which would contain two different elements which could be manipulated to the correct road layout.


When applying the texture to the mesh, I have control over which part of the texture gets applied to which corner of the triangle. Therefore, with the image above I can create a straight section of road with the left triangle of the image twice or a crossroad using the right triangle in the same method. This in theory means that less textures are required and should help improve performance. The short video below shows this method in action.

It's not the greatest looking piece of work but it's functional and can be updated later on.

What's Next?

There are a few pieces which are next on the list, I still need to get the picking working but I've pushed this to the back-burner for now so I can make some progress on other sections.

I really need to optimise the transition from one city area to another, currently there's a lag when creating the new area which I really want to reduce or remove.

The other two sections are the pieces I really want to get my teeth into, that's the enemies with basic reactions. The other is to make each city block more unique, I want there to be different building types and searchable items (crashed cars, bodies, containers, etc)

Seamless city generation progress

I've made the decision to change the loading of levels in the game. Originally the plan was to load each piece of the city at a time when you exited and entered a new area. In more recent games, gamers are more accustom for levels loading in the background making it a seamless experience, therefore, this is what I've attempted to go for.

To show how I've implemented this, I've zoomed right out to give you an idea of the process being performed.

As you can see there's still a little left to do, the buildings at the edge of each section is still full length which will lead to long buildings so I just need to half the width of these. There's also a slight lag while each block is being generated. All in all, it's not too far off what I was hoping to achieve, just needs a few tweaks.