Bytesize Adventures Crafting bite-sized digital worlds Thu, 28 Mar 2019 11:06:52 +0000 en-US hourly 1 Ludum Dare Time-lapse and Results Fri, 25 Aug 2017 11:16:01 +0000 Read More]]> Time-lapse

Last time I entered I produced a time-lapse of the development. I find these pretty interesting so I’ve done the same again.

I’ve tried to lengthen the video this time around by lowering the frames-per-second. A screenshot was captured every 30 seconds during development and there are 4 frames to each second of video. So each second of video represents 2 minutes of work.


The purpose of Ludum Dare, for me at least, is to brainstorm some ideas and kickstart some creativity. And to that end, its been a success. The game I produced had lots of flaws but something in the core idea has got me excited to produce a more fleshed out version – we’ll see where that goes in the coming months.

Participants in Ludum Dare are encouraged to play one another’s games and to rate them in a number of categories. In spite of some great feedback in my game’s comment section, my results weren’t particularly encouraging.

The results below are out of 2,431 games. Also worth noting is that the ratings are out of all entries regardless of whether you did the competition (1 dev, all from scratch in 48 hours) or the jam (teams, can use existing code and assets, and have 72 hours).

Whilst at first glance it seems pretty awful (even with the caveats above), I decided to compare it to my results from Ludum Dare 25.

Ludum Dare 25 (Overall): 254/1,326
Ludum Dare 39 (Overall): 415/2,431

Both of these are within the top 20% so at least that’s something.

More importantly, we can normalise the old score against the new one.

(2431/1326)*254 = 466

This means that my score from Ludum Dare 25 translates to 466th when compared against the new score with its increased number of participants. So it looks like I’ve improved by 51 places. Not too bad after all :)

The game itself, whilst having a pleasing gameplay loop, is not a good game. There’s no real challenge and it can’t hold your interest much past a few minutes. These are things that I intend to look at for my post-jam version.

]]> 0
Ludum Dare 39 – Liveblog Sun, 23 Jul 2017 18:55:31 +0000 Read More]]> Ludum Dare is a game development competition (and game jam) that takes place over 48 hours. During that time, the aim is to develop a game totally from scratch (inclusive of code, art, sound effects and music). Additionally a theme is voted on and announced just prior to the competition start time.

It just so happens that there is one taking place this weekend, and so I’ve decided to join in.

This will be my second time entering Ludum Dare; my first one was way back in 2012 for Ludum Dare 25. During that, I came a fairly respectable 254th out of 1,326 entries with my crime simulator – Micro Mob. Let’s see if I can top that this time.

Last time I also live blogged my progress which I enjoyed so I figured I’d do the same again this time.

One of the things that limited me with Micro Mob was its requirement to download it in order to play. So this time, a platform with web deployment is a must. As a result, I’ve opted for Phaser which I used for my procjam entry a while back and really enjoyed.

In addition to this liveblog, I’ll probably also create a development timelapse and will try to post some gifs.


Framework: Phaser
Sound Effects: CFXR (and maybe my analogue synth)
Music: I might try to create something with my Pocket Operator
Art: Affinity Designer
Other: TexturePacker, GlyphDesigner

Development Diary

7:50am (Hour 6)

Im up, showered and coffee is brewing! Ludum Dare began at 2am this morning (due to timezone differences) so I’m already somewhat behind.

I’ve just checked the website and the chosen theme is: Running out of power

I’m going to spend some time coming up with some ideas and getting some inspiration.

8.30am (Hour 7)

I think I’ve settled on an idea. It has a basic premise and I think the assets are achievable in the time. There’s some complexity around input so I’ll focus on that first. I’m going to box out some areas of the screen with some basic shapes.

Time to crack on!

10.30am (Hour 9)

Slow progress but speeding up a little now. I’m just working on getting some of the basic elements in place and some of the core mechanics.

12.45pm (Hour 11)

I forgot just how quickly time whips by in these events. I now have the basic interaction and fuel mechanic in place. Still lots to do to make it engaging. I’m taking a short break for something to eat before moving on to some basic graphics.

4.15pm (Hour 15)

I have some very basic graphics now and I’ve also added a few placeholder sound effects. I’m going to spend a few minutes creating a prioritised list of the remaining work and nice-to-have’s.

6.30pm (Hour 17)

Visually, I haven’t added anything new really. I’ve introduced the start of a new game mechanic and I’ve refactored some of the code ready for extension.

Fatigue is starting to kick in big time now so I’m going to take a break for an hour or so. The remainder of the evening is likely to be spent on graphics and/or sound effects.

11pm (Hour 22)

I’ve put some placeholder music in place. Hopefully I’ll get a chance to replace it but its not a huge priority. I’ve also completed some of the key graphical assets – by no means my best work, or even very good but they’ll suffice if I run out of time.

And with that I’m going to get some sleep ready for day 2!

8.30am (Hour 31)

I’m up a little later than I’d have liked but I’m ready to go. There are 17 hours of the competition remaining. My first task is to put the graphics from last night into the game. Then its onwards with the gameplay.

12.25pm (Hour 35)

The last 4 hours went by shockingly fast! Lots done though. I’ve implemented the new graphics, added some visual clues to avoid text, fixed some bugs, and added several game features.

I’ve got some larger features to work on now which will require new graphics and gameplay.

5pm (Hour 40)

Phew! lots done. Everything is now in place. With the remaining time, I have a couple of bugs to squash, a game over and restart function to write, and the dreaded tutorial. I probably won’t have time to work further on the graphics which is a shame.

I plan on taking a break for an hour or two to recharge.

11pm (Hour 46)

Success! I’ve just submitted my entry to Ludum Dare 39 – Stoked. I’m thoroughly exhausted. I really wanted to revisit the graphics but I’ve ended up improving gameplay a little instead.

I’ll tidy this post up in the coming days. I also have a development timelapse to stitch together and post :)

You can view the entry and play it here.

]]> 0
Cardboard Dungeon on Mozilla Hacks Fri, 08 Apr 2016 11:17:21 +0000 Read More]]> I was pretty chuffed when Mozilla approached me recently to write a case study for their Mozilla Hacks blog.

The aim was to discuss my experience with A-Frame and producing a web-based virtual reality experience. I think the final article has turned out rather nicely.

Here’s an excerpt:

VR lesson #2: Strain

Placing common interactions out of the player’s line of sight creates an uncomfortable experience. Having to gaze at the ground in order to trigger movement means constantly tipping your head forwards and backwards. Placing this interaction close to the player’s natural resting gaze position makes for a much more comfortable experience.

My final solution was therefore to utilize a teleportation mechanic. The player simply gazes at any blue sphere to move to that location, regardless of whether the room is on a lower or higher floor. I opted to limit this to one dungeon square around the player in order to retain the feeling of exploration.

You can read the full article on Mozilla’s Hacks blog.

Thank you Mozilla for the opportunity :)

]]> 0
Cardboard Dungeon Devlog #4 Sat, 19 Mar 2016 15:03:45 +0000 Read More]]> This will be the final devlog for this project. Whilst the final product is not really a game, it is a fun “experience” that has given me a taste of virtual reality development. A-Frame has been really fun to use and it can only get better. I think that web-based VR experiences absolutely have a place and I’d imagine we’ll see more google cardboard icons (to launch VR mode) on websites in the future.

I’ve implemented quite a lot of stuff for this final devlog.


The compass is something that existed way back in devlog #1 but I removed it to focus on other elements. I’ve put it back and improved its appearance ever so slightly. Its a good way to keep your bearings, especially in the new larger map.

The compass also acts as the trigger for opening and closing the inventory.


I’ve overhauled the inventory slightly to only render items once the panels are fully extended. The inventory now also shows smaller items to make selection easier. It’s generally more robust in its handling.

final Inventory Design


Items are now driven by the JSON map data so its easy to place them in any room.

The process for creating a new item currently looks like this:

  1. Create a model using MagicaVoxel and export as an “obj” file
  2. Import the “obj” file into Blender in order to export it as a collada (dae) file (I had issues texturing obj files in v1 of A-Frame but its unlikely you’d face this issue now and could just use “obj” files directly)
  3. Define the assets in A-Frame
  4. Create an entity, and figure out the position/rotation for the object when its in the player’s hand
  5. Add the item to the JSON map data to specify where it should appear

The code takes care of rendering the item in the correct room and the inventory.

I also created a new shield item :)


A new area

Cardboard Dungeon Tutorial

I’ve created a new area outside of the dungeon. This is where the player first enters the experience and is intended to teach the basics. Rather than implementing lots of text, I’ve hopefully created a simple enough area that the player can intuitively experiment to figure out the controls.

In this area, the player needs to find the key, select the key from the inventory, and gaze at the door to enter the dungeon.

This area is kept separate from the JSON map data and is in fact rendered above the dungeon. Here you can see through the smoke and mirrors :)


A new map

I’ve created a new, much larger map for the final experience. This is all defined using JSON and, since I haven’t yet created a level editor, its fairly laborious to create. Hopefully the new map is a much more guided experience. It doesn’t have an exit, its just a larger dungeon with a few items that can be collected.

What’s next?

That’s it for this series. Cardboard Dungeon is complete for now. I’ll definitely be checking in on A-Frame regularly and I can certainly see myself using it again. For now though, I’m moving on to some Virtual Reality experiments with Unity (with any luck my HTC Vive will arrive soon :) )

You can read the full series of weblog’s here:

  1. Cardboard Dungeon Devlog #1
  2. Cardboard Dungeon Devlog #2
  3. Cardboard Dungeon Devlog #3
  4. Cardboard Dungeon Devlog #4 – You are here!

Play Cardboard Dungeon

Play Cardboard Dungeon here!


(Scan this QR code with your phone to launch it directly on your device)

Cardboard Dungeon QR code

]]> 0
Cardboard Dungeon Devlog #3 Fri, 04 Mar 2016 13:01:49 +0000 Read More]]> Its been a little while since my last devlog and, in truth, things have slowed a little. This is partially because I’ve begun investigating Unity at last with a vague goal of producing a fully fledged VR game.

This isn’t a reflection on A-Frame. I’m still excited by the potential of web-based VR experiences. I’m just eager to experiment with full VR headsets and room scale VR.

That said, I have made progress on Cardboard Dungeon. Lets get into the detail.


This has been the core focus of my work since the last devlog. Having experimented with the inventory room a little more, it really wasn’t working as well as I initially thought.

Its just not terribly convenient being shrunk and having to look around a room in order to interact with your inventory. More than that, the scaling sensation makes you feel pretty sick (a limitation of phone-based headsets due to latency?).

I’ve scrapped that code and instead implemented a simple expandable inventory with 4 possible slots for items.

The way this works is that you look at the square at your feet to expand the inventory. The squares around the outside are inventory slots. The centre square can be used to close the inventory – it will probably also be home to the compass in the next iteration.

Cardboard Dungeon Inventory Loop

Items can now be picked up and are placed in a free inventory slot. Opening the inventory and gazing at an item will assign it to your hand or, if you already have it equipped, remove it from your hand.

The position of items in the player’s hands are pre-programmed so it will always replace whatever you currently have equipped if that position is needed.


The old graphics were just some placeholders. They looked okay but I feel that cartoony graphics work better in VR as its easier to overlook lower resolutions and the fact that they don’t match reality.

I paid for a few textures from 3D Ocean. I think that they offer a much more coherent aesthetic. They’re not perfect but they’re suitable for the purposes of this experimental game.

What’s next?

If you want to play the current iteration, you can do so here.

I’ve reduced the scope of what I’m trying to achieve for this series of diaries. I want to wrap up this mini-project so that I can progress with my Unity experiments some more.

I feel that the following items will take this game/experience to a satisfactory conclusion:

  1. I want to drive the item positions from the JSON data. This means it will be easy to place items in rooms not yet rendered.
  2. I want you to be able to interact with at least something in the dungeon (based on the item in your hand).
  3. Finally I want to create a new, larger, dungeon layout – which is really just taking the time to describe one with JSON since that system is already in place for the existing dungeon.

So the ambitions aren’t too lofty. I expect to be wrapped up in devlog #4. See you next time.

]]> 0
Cardboard Dungeon Devlog #2 Mon, 08 Feb 2016 21:00:55 +0000 Read More]]> Working with Google Cardboard, and the A-Frame framework, continues to be enjoyable. Virtual reality has some interesting challenges in terms of game design and its often the case that what appears on the screen during development has a totally different effect in virtual reality, especially in terms of scale and distance.


I had some necessary, but slightly dull, work to do by way of performance improvement. I started by defining all of the container entities in markup first and then switched my rendering method from dom-based injects to instead utilise the “visible” component in A-Frame. This worked but was a little inflexible for when I need to change the markup of a container.

In the end I opted for an init function that is called once for each container upon creation. This injects the correct entities. The rendering function that is called during movement then just modifies the “visible” component value. This gives me much more flexibility during development and reduces the dom manipulation during runtime.


Up until now, there has been a single floor. This results in very uniform, boxy rooms. I wanted to add a sense of height along with the ability to move between different floors without a transition if possible.

I’ve now implemented additional rendered containers above and below the main floor. This allows me to load in rooms from the JSON file at different heights, creating more interesting level structure. Theoretically, this allows for an unlimited virtual height but, in practice, will be bound by memory constraints.

I haven’t created much with it yet but that will come once I start to create a tool for creating the dungeon.

Multiple Floor 3rd Person

Map Traversal

The new multi-floor mechanism brought with it a new challenge: Map traversal.

I tinkered with a solution for separate compass movement and height movement. In the end though, I merged these into a single solution that intelligently displays a sphere in any room you can move to (within a 1 room radius). You just highlight the sphere and you’re teleported to that room.

Its a nice, streamlined method for traversing the map. Its something that I’m sure I’ll revisit as new gameplay mechanics are introduced.


Everything about virtual reality makes you want to do away with traditional 2D interfaces. There’s a real desire to create tangible items that can be interacted with.

For Cardboard Dungeon’s inventory, I wanted to experiment with something you can interact with directly. I think it would be pretty nice if you could actually step into the inventory. This would give the player much more freedom to browse, and interact with, their items.

It turns out that this is actually a pretty fun idea. I’m still experimenting with it but not only does it act as an inventory, it also works as a handy area where you can get a few moments respite from the game. You can just sort of hang out in your inventory. This could be expanded in lots of different ways.

What I’m currently experimenting with is an open box at your feet. You can make out objects in it and it looks like a tiny room. This is exactly what it is. If you gaze at it, you shrink and enter the box. You can look up and see the roof of the dungeon of the room you’re in. Alice in wonderland style.

Cardboard Dungeon Inventory

I’m toying with switching the box for a bag. Lots more to experiment with on this front but its now fun just entering and exiting the inventory :)

Next time

I’m going to play with the art style a bit soon. I want to go for a more cartoon style. I’m also currently playing with MagicaVoxel and Blender for objects.

The key gameplay mechanic coming next is to experiment with picking up objects and adding them to your inventory. Then, by extension, selecting these to hold them.

Finally, I need to make some inroads into how I can create a very simple tool for building the dungeon. Working with JSON directly is extremely time consuming.

Google Cardboard viewers

]]> 0
Cardboard Dungeon Devlog #1 Sun, 24 Jan 2016 10:38:49 +0000 Read More]]> Welcome to the first devlog for Cardboard Dungeon. In actuality this is really a devlog for experimenting with virtual reality using what I have available to me – Google Cardboard.

I’m anticipating a relatively short project but lets see how it goes. It’s very much going to be an organically developed game, trying things as I go.

What is Cardboard Dungeon?

Cardboard Dungeon is a first-person dungeon crawler for Google Cardboard. I’ts my first virtual reality game and my first 3D game!

At the moment I’m interested in having the experience revolve around exploration – perhaps something to do with cartography.

I’m also keen to play around with both interaction and interface. What can I achieve purely with gaze and single click interaction? How can I manifest all required interface as objects in the virtual world (e.g. a physical compass etc)?


The official Google Cardboard SDK works with either the Android development environment or Unity (and iOS and Android by extension). I still have a bit of phobia to development environments such as Unity. It may be that VR will give me the push I need to really get into Unity.

For now, and for the purposes of this project, I wanted to try A-Frame (created by Mozilla’s virtual reality research team). A-Frame is framework for creating web-based VR experiences.

So far, the experience of developing with it has been pretty good. There are a number of examples on the website, a relatively clear and well laid out set of documentation, and a friendly slack channel (frequented by the A-Frame developers).

I’m still learning the in-and-outs of the framework. It relies heavily on HTML markup and I’m currently finding the balance between that and Javascript.

Streaming levels

One of the first challenges I tackled, for the start of this project, was the presentation of levels. I knew I couldn’t render the whole level at once so I needed a way to define a renderable area.

My current implementation consists of a 3×3 grid of entities representing N, NE, E, SE, S, SW, W, NW and a central entity. Additionally I’ve added 4 extra entities at NN, EE, SS, WW – these are to extend the players visibility in these directions as the 3×3 grid was too limiting.

I’m using JSON to define the room data. This consists of x,y coordinates beginning at 0,0 and extending both negatively and positively. This represents the room position from a top-down perspective. I then define which walls, ceilings, and floors to draw, per room, using zeroes and ones.

It’s in this way that I can load the data into the visible entities and then simply change the data in the 3×3 grid as the player wishes to move. The entity positions are static and so is the player camera.

I’m still playing with this solution as A-Frame does have a “visible” component, pointed out to me by one of the developers. It may be that I could create the markup of the whole level first and then just add/remove the visible component. Or indeed some other combination of the two solutions.

Cardboard Dungeon Grid

The Compass

I knew I wanted a compass in the game as soon as I started to walk around the dungeon. Even with the relatively small size of this test dungeon, its easy to get lost. It was also an opportunity to create a piece of interface as a 3D object in the game.

This was relatively easy to achieve by assigning the “look-controls” component to a box primitive representing the compass casing. This will turn with the camera. The needle is then a fixed primitive pointing north. It never moves, its just the casing that rotates. A pretty simple solution.

Cardboard Dungeon Compass


The issue with the 3×3 grid of rendered rooms is that you can clearly see the missing planes for rooms that aren’t being rendered at the edges of the grid. You can see this in the image below…

Cardboard Dungeon with no lighting

The solution to this is two-fold. Extending the the number of rendered rooms directly north, east, south, and west of the player helps to lessen the effect. Additionally, adding a point light to the players location places the distant rooms in shadow. This obscures the room rendering such that you are unable to see the missing planes. See the image below…

That’s all for this first devlog. Feel free to check out the current development version here (You’ll need a reasonable powerful mobile phone and, ideally, a Google Cardboard headset). I’ll have another devlog, with more progress, soon.

]]> 0
Equaliser – A Pebble Time Watch Face Mon, 22 Jun 2015 11:42:08 +0000 Read More]]> I’m not quite ready to put aside £300+ for an Apple Watch. I’m not yet convinced that a smart watch has a place in my life. That’s why I jumped on the Pebble bandwagon with their recent Kickstarter campaign for the Pebble Time. £100 seemed like an achievable amount of money to see if a smart watch was for me.

Fastforward to a few days ago and my Pebble Time arrived in the post. It looks a little nicer in person than it appears in the marketing material. I’m still getting used to it and don’t yet know if its for me but I have taken the SDK for a spin :)

The SDK is fairly straightforward. Installation is taken care of by Homebrew (at least on Mac). I’m using Sublime Text for writing the code (wriiten in C). Usefull command-line commands are:-

pebble build – to build the binary
pebble install – to test the binary on the default emulator (Basalt)
pebble screenshot – to take a screenshot through the emulator

(Adding the –phone switch to these and specifying the IP performs the commands via the physical watch rather than the emulator).

Its fairly simple stuff, fathomable within an afternoon or so.

What I’ve ended up creating is a new Watch Face for the Pebble. My goal was, first and foremost, to create something that looks good.


Equaliser works like this:

– Rows are hours. They fill up from the bottom to the top. Each full row is an hour past midnight. So two full bars is 2am.
– Columns are minutes. These fill up from left to right. Once 60 columns are filled, an hour is complete, and a new row starts.
– Seconds are represented by the vertical line that sweeps across the display.

Whilst the Watch Face is intended as something fun, I have worked on readbility with the following:

– The black vertical bars are 15 minute increments. The thicker black vertical bar is half past the hour.
– The midday row is highlighted orange.
– Orange graduations are visible on the left every two hours.

Equaliser also has the following:

– Support for both 12 and 24 hour time formats
– The ability to suppress the second hand
– Date (day name, day number, month name)
– Battery percentage
– Bluetooth connection indicator (with vibrate on disconnect/connect)
– Support for the original Pebble

I’ve also made the source code available here.

]]> 0
An excursion into the world of Arduino Sun, 31 May 2015 18:51:32 +0000 Read More]]> It’s fair to say that electronic prototyping and the creation of custom hardware at home has exploded over the past few years. As a developer, the idea of combining my programming skills with electronics to create a physical object is intoxicating.

But where do you begin?

Arduino has become synonymous with electronic prototyping (For example, the prototype for the original Pebble smart watch was built with an Arduino). Its pretty much the go-to platform as an entry point into this exciting world.

There are companies making this even easier by producing kits that contain all of the components necessary to get started. I happen to own one such kit (a present from my wife a couple of years ago) – the DIY Gamer Kit from Technology Will Save Us. Kit in hand; I set out to make something…

Building the Gamer

The DIY Gamer Kit is a lovely thing. The packaging is great and the components are all interesting and shiny. You get all sorts of stuff:- Buttons, switches, a light sensor, LED’s, an infrared transmitter and receiver, a buzzer, an 8×8 pixel screen. Honestly, just spreading out the components is enough to get you excited. Here, see what I mean…

DIY Gamer Kit Components

You will need a few other things. You may have these – I did not and, with UK high street prices being the way they are, they set me back another £40 or so. Basically a soldering iron, solder, wire cutters, a flat-head screwdriver, Blu-Tack, a 9v battery, and a de-solder pump. You could probably get away without that last item if you’re careful but its useful if you do mess something up.

You start with the printed circuit board which has pre-punched holes for the components. You just pop the components in, solder them on the back, and snip off any excess.

DIY Gamer Kit Printer Circuit Board

DIY Gamer Kit with buttons

DIY Gamer Kit with all components

The finished item a few hours later. You can see the Arduino plugged into the circuit via header pins on the back. The 64 pixel screen is also plugged in. The whole thing is fairly solid. The battery connections are a bit of a pain and result in a setup where the battery just sort of hangs in place. I’d have preferred some sort of bracket in the plastic housing and a snap connector.

DIY Gamer Kit without surround

There is some plastic housing provided to protect the components. You can see it attached here. This was one of the trickier steps as it uses nylon nuts and bolts which are incredibly fiddly and unfortunately easy to cross-thread. The final kit does look rather nice though :)

DIY Gamer Kit in plastic housing

Writing Some Code

With the Gamer complete, its time to write some code. Technology Will Save Us provide their own library to interface with the Gamer Kit. It doesn’t do a whole lot, just provides some convenience methods for you but is useful nevertheless.

The Arduino IDE utilises the Wiring framework which itself is based upon the processing programming language and tooling. The best reference for it is directly on the Arduino website here.

Technology will save us provide a handful of sample programs too which are very helpful and where you will learn the most.

I quickly cobbled together a very simple program intended to display a ball with a basic bouncing animation. The code is very simple and I’ve also uploaded it to GitHub here.


Gamer gamer;

byte bounce1[] = {

byte bounce2[] = {

byte bounce3[] = {

byte bounce4[] = {

byte bounce5[] = {

byte bounce6[] = {

byte* frames[6] = {bounce1,bounce2,bounce3,bounce4,bounce5,bounce6};
int initial_volume = 5;
int initial_speed = 300;

void setup() {

void loop() {
  int min_frame = 0;
  int volume = initial_volume;
  int speed = initial_speed;
  for(int max_frame=0; max_frame<6; max_frame++) {
    for(int x=max_frame; x<6; x++) {
      if(x!=5) {
    for(int x=4; x>min_frame; x--) {

void beep(int duration) {
  digitalWrite(BUZZER, true);
  digitalWrite(BUZZER, false);

And here it is in action on the device itself…

I certainly plan on exploring some more of the Gamer’s capabilities and writing some more significant code. Who knows, it may eventually lead me into building my own circuits :)

(A quick note about Technology Will Save Us: I actually had a bit of a false start with this kit as it didn’t initially work. A few email exchanges with the guys at TWSU to diagnose the issue and they ended up replacing the kit – very kind of them and they were very pleasant through the whole thing :) )

]]> 0
2014 in Review and Plans for 2015 Mon, 29 Dec 2014 11:45:41 +0000 Read More]]> Each year I write a post looking back at the previous year and talking a bit about my aspirations for the new year.

It’s actually incredibly insightful to take stock of what you’ve done in the past 12 months. When I start writing these posts I really don’t have much idea of what will be in them. I tend to begin by reading my blog posts over the past year. Its an opportunity to review and reflect.


As tradition dictates, lets take a look at some website stats first.

9,334 sessions from 7,124 users
16,084 pageviews
Most visits in a single day: 250

The top 5 most popular posts were:-

The downward trend of visitors continues albeit at a much slower pace than last year. I think I have to put this down to my reduced interaction on social networks and the like. I have to say that this has been purposeful and taking a bit of a step back from Twitter has helped me personally.

One heartening stat is the peak number of visits in a day (250) which, whilst not stellar, shows that a single article can still bring traffic if its linked to by another high traffic website.

Procjam 2014

I really like game jams. This is only the second one I’ve participated in (the first being ludum dare) but they are great fun. You have to get into a totally different mindset to creating a game normally. What I end up with is usually very basic but functional. Its nice to have a sense of achievement no matter how short lived it is.

Procjam was all about procedural generation and gave me an opportunity to try the Phaser JS framework. I’ll definitely pick this up again for game jams and prototypes.

A new website

It was finally time for another new website design this year. Once again I built my own theme but this time from the ground up. It’s responsive and a much better base from which to extend. There are some things I want to tweak and improve but overall I’m happy with it.

All Apps pulled from the App store

This was the big one and unfortunately not necessarily positive. I think when you post an App on the App store, you also have to commit to updating it fairly regularly to keep pace with Apple’s changes and users’ expectations.

Ultimately I made the decision that I no longer wanted that responsibility and pulled my 2 remaining Apps.


Okay, I have a confession; I actually renewed my App store contract late last year having let it elapse a few months prior. My old Apps are still no longer for sale and I have no plans to re-instate them. They were great experiences but they are in severe need of redesigning and I don’t want the pressure of maintaining them.

What I have done is to register a new App with the name of my new game.

It is still the Puzzle RPG that I’ve been working on in dribs and drabs for the past few years. I actually picked up work on it again towards the end of 2014 and continue to make slow but steady progress.

I’ll only share information about the game on this blog at key milestones so as not to disappoint. My goal, for what its worth, is to release it in 2015. If you want to follow the progress at a more granular, but raw, level which may include varying degrees of disappointment, you can do so at the devlog here.

I will say that I’m happier with it than I ever have been. Things finally seem to be falling into place.

(Current status – WIP)

New look

So, 2015 could be the year.

…and I expect I’ll dabble in a few game jams too :)

Have a great Christmas and a Happy New Year.

]]> 0