Back from sabbatical

For anyone following previous posts, you may have noticed a distinct lack of activity for a long time. This has mainly come down to a couple things:

1. Launch Frenzy

Launching a game is stressful business, you gotta create press kits, draft press emails, register as a business owner, taxes and a whole lot of other boring adult stuff.

2. Burnout

I’ve spent the good part of two years plugging away at this little project on evenings and weekends. I’ve missed an Australian Summer (as an Irish person, that’s quite a sacrifice) confined to a text editor, chasing the idea of seeing a game through to completion. When I had the realisation that I wasn’t an overnight millionaire post-launch, I decided to take a step back and enjoy my freedom for a while.

I’ve finally been able to read again, play video games (I might finally complete GTA) and staying out late on a weekend. While all of this has been great, there’s unfinished business. I’ve created a playable game and have received some good [albeit mixed in a few circumstances] feedback on it but it’s still missing some finishing touches. It’s time to give it one last go before moving on to new projects.

More blog posts coming soon!

Indie Games Festival - post-mortem

Last Saturday I had the opportunity to showcase my game to the public for the first time. A few days before I was looking through gamedev posts on reddit and stumbled across a post about open spots for iFest, a free-to-the-public independent game festival in Melbourne. Now I’ve never heard anything about the event before, there was next to no press for it and a worrying lack of followers on the official Twitter page so I assumed that it was going to be pretty small-time. It was no PAX for sure; but showcasing here offered a couple of opportunities:

1. Publicity

Raise a little more awareness about the game and gain a few more followers on Twitter / Facebook

2. Feedback

Up until this point, the only people that had played or tested the game were friends or colleagues. I’m not saying that they aren’t capable of giving constructive feedback but first impressions from random punters are going to be a lot more honest, and more accurately reflect the initial reaction once the game goes live on the app stores.


The timing was actually pretty bad. I had no paraphernalia or expensive, flashy banners and with a couple of days to prepare and a house move happening on the same weekend the stand wasn’t going to be the most professional of displays. It was literally a few hours to mock up some pretty crude posters from existing in-game assets with some social media links on them and rushing to OfficeWorks to get it all printed. The result came out at AU$60 for posters to hang off my stand, 150 business cards (cut up by hand from A4 card prints the night before) and a t-shirt, because that’s how professionals roll.

What 3 hours accomplishes in paraphernalia

The event

I arrived at iFest around 10am, just in time for it to open to the public and expectations were pretty much accurate. There were about 20 stands there, some of which were flashier than others depending on the studio. I happened to be placed next to a small indie team of five, some of which were ex-EA developers. They were working on a Kickstarter called Space Dust Racers. Their setup was pretty decent compared to what I was about to pullout of the bag. They had a big widescreen TV with multiple X-Box controllers but most importantly, they had a really polished, playable game. It looked closer to a AAA studio game than indie, which made me quite nervous about setting up my stand and how small-time it might look in comparison to others.

iFest at Federation Square in Melbourne

I had a shitty old 13” monitor (which I never even ended up using, partly because of embarrassment) and my MacBook Air for showing my first-cut launch trailer. I fired that up, plopped a test device down on the table with a couple of stacks of business cards. The first half of the day was a slow trickle of people walking through the event, some of which had no idea what the festival actually was. It got busier after lunch time but overall I had only about 30-40 people visit my stand over the course of the 4.5 hours there, which pretty much representative of the event itself.

The lemonade stand - we all have to start somewhere

Public reaction

So my Twitter following wasn’t really going to take off. As uneventful as the day was, none of that really mattered because once people started approaching my stand (no matter how small in number) and started playing my game it really changed my perspective of my own game. I got a range of different demographics from parents and children to software undergrads but pretty much everyone seemed to really enjoy playing Cosmic Badger. I saw people smile while playing the game, or laughing when the game mechanic finally clicked - that “Ah!” moment that I wanted people to figure out on their own. Some kept playing for 5-10 minutes at a time, one guy even came back for a second go half an hour later.

Some slightly paraphrased quotes from memory:

Positive feedback

  • “that was actually fun”
  • “that’s a really cool mechanic, I don’t think that’s ever been done before”
  • “I can see myself getting addicted after a while”
  • “I love the pastel colour art-style”

Constructive feedback

  • “Some of the obstacles look like they’re in the background”
  • “Needs some cooler space / time rift effect between the portals”


  • “So it’s portal meets flappy bird?”
  • “Why a badger?”

The things I felt when I first started playing my initial prototype (before the two years worth of work where I had become completely impartial), the things that I wanted others to experience when they picked up the game and started playing were happening, and this was one of the most satisfying and reassuring moments since starting this project.

Most of us indie devs spend months to years working on our own pet projects. During which we constantly doubt ourselves and our abilities, and become almost apathetic to what we’re working on. Some of us have seen and played so much of our own game that it’s hard to tell if it’s actually good any more. Getting strangers’ feedback was one of the most important realisations in this project.

I’m hoping to submit my game for app store review this weekend. When it finally releases I have no idea how many people will download it, or even realise it’s out there, but at least last weekend I realised that I’ve accomplished something. I’ve finished a game, someone played it and someone liked it.

Special Mentions

I want to give a special mention to the two stands each side of me, one which was hobby dev Hemmingway Games like me, taking every opportunity outside of his day job to work on his passion. The other is the kickstarter team of 5 working on Space Dust Racers, who have really earned my respect. They quit their full-time jobs while supporting families to work on their own vision. Asking for a modest amount on Kickstarter, these guys seem more focussed on achieving their goal and earning enough to survive than being greedy. I’ve played their game and it was actually really fun, so check them out when they launch.

Bringing sketches to life

There’s nothing more satisfying as an indie dev than sketching down an idea and then implementing that idea in your game world. In this post I wanted to pay tribute to some of the earlier sketches and how they turned out, being implemented in the Cosmic Badger universe.

The grass stage were the first levels that I worked on. I had very little experience as a “pixel artist” at this point and I actually went through a couple of iterations of the sprites before I got it to a state that I was happy with. I’ll cover some of those in another blog.

Concept art for the grass themed stage

The industrial stage took a day or two to complete the background for. I hadn’t really gotten a grasp on gradients at this stage and was changing the variation in shadow manually by changing the brightness/contrast. Everything was very much a learning process.

Concept art for the industrial themed stage

Despite its simplicity, the toy stage came out as one of the best. The varying colours made it much more of an interesting level, landscape-wise. Some of the sketches were crudley drawn and then done properly from scratch on computer, others were scanned and then inked.

Concept art for the toy stage. Some of these sprites are still a little rough as I never re-touched them later. I’ll get to them.

The black and white levels were some of the hardest to get just right. The foreground obstacles had to contrast enough from the background to be visible but that’s kind of hard when you’re working with the different tones of the same colour all the time.

This came out as one of my favourites

How much has your own concept art reflected your final game? Could it still be improved or are you happy with the results?

Level design of an indie game

Designing your game is probably one of the most crucial parts of the game development lifecycle. It’s an iterative process, for sure, but design documents have to start somewhere. In this post I’m going to talk about the initial designs of the levels in Cosmic Badger and the inception of the tilesheets used in the game to date.

With a clearer vision of how the game would look, it was now time to start designing the levels. There was no real complex workflow to this. I bought a load of graph paper and sketched out the general layout of the terrain and obstacles, keeping the game mechanic in mind. I’d then build the level using the level editor and test it on the laptop (with play-testing coming later on mobile). In hind-sight, it would have been nicer to set up an easier deploy process to prototype a section of level and test on the fly via mobile, but that’s really a lesson learned for next time.

The layout of one of the later levels for Cosmic Badger

I wanted 7 distinct stages with 3 levels per stage, so I came up with a list of themes that might be cool. Out of those themes I picked my favourite according to how varied I could make the obstacles and how interesting I could make the tilesheets. The list was stripped down to the following -

  • Grassy / forest
  • Snow
  • Industrial
  • Toy room
  • Black & White
  • Asian / oriental
  • Some crazy checkered terrain stage that I didn’t have any specific label for (this was more based off a random sketch that I did)

The initial concept art of that same later level

I started sketching the ideas on a notebook, which then became a strong basis for how the sprites would evolve during game development. Photos were taken of the images and then inked/edited on the computer to become proper sprites. The images weren’t perfect by any means, but they were legible enough to fit in an indie game, and something that I would later improve upon with practice (I’ll show some examples of that evolution in a later post). This notebook became a bit of a bible during development. I know you’re dying to see how this actually turned out, which is why it’s being covered in the next post.

What process do you have for designing your levels? Add your insights in the comments below.

When to pivot on a game idea

It’s not uncommon for indie developers to be working on a game when fresh ideas/features start to interrupt their train of thought. But what happens when an entirely new game concept altogether manifests itself? Do you scribble it down and carry on until you’re finished your current project, or is the idea so captivating that you just can’t wait to work on it, ditching your work in progress? This exact scenario happened to me during my first game, so I’d like to take the opportunity to explain the path that was taken and the reasoning behind it.

The road so far

As previously mentioned, my game engine was up and running and now work could finally begin on the design of the ballon game. Five weeks had already gone by of the original estimated 2-3 month project so this was a good time to do a roadmap check. The following were the key points that needed to be achieved in the next month:

  • Tilesheets to cover roughly 12 levels
  • Design the levels to sprawl over both X and Y axises
  • Enemies with different behaviour to make the game challenging and varied over the levels
  • Sound effects for enemies, weapons, the player, etc.
  • Music for all the levels
  • Some sort of storage to track progress, collectables, etc.
  • A menu system for selecting levels, pausing, etc.
  • Design tutorials for the start of the game

The first thing that became apparent was that most of this would not be achievable in just a couple of months. The biggest hurdles would be designing the levels and creating the tilesheets for everything, I wasn’t even so worried about the coding. This was never going to work, and as advised in the last post I needed to cut my scope drastically to meet my deadline, but what could be cut? As far as I could see this wasn’t going to be possible unless I released just a couple of levels. That just wouldn’t cut it for the app store. Thankfully there was a backup plan that [in my mind] was achievable in this small amount of time.

The balloon game as it currently looked

A new game idea

One routine I had gotten into the habit of doing was to leave a notepad by my bed at night. I’ve always been a little bit of an insomniac and when I’m lying in bed after putting in a 10 hour day of game coding my mind was always racing with ideas. Sometimes the thoughts that came to me were just tasks that I had forgotten to take into account, other times they were new gameplay mechanics, enemies, puzzles, etc.

One night, lying in bed, the completely unrelated thought of using portals in a game popped into my head. Now it’s not like this is a revolutionary idea by any means, but after some brief app store searching I came to the conclusion that this hadn’t been implemented in the mobile space to great effect. I had this idea of a platformer/auto-runner where your character had to teleport around obstacles. I switched the light on, wrote it down in my notepad and went back to bed.

With the burden of the scope on my current project, the next day I was keen to prototype my new idea and see if it was any fun to play. I chopped the balloons off my character and used my first crappy tile sheet (effectively some sort of hexagon manhole cover?) to create an auto-scrolling level. I had to add the auto scrolling, change the game mechanic and controls to use portals instead, and then add gravity to the game so the player could fall onto the terrain. This was the finished prototype and the idea was surprisingly fresh and fun to play.

The game after the idea pivot and the first Cosmic Badger prototype

The road beyond

This new game concept was going to be a lot easier to implement. It was an auto-runner so the level design could be constrained to the x-axis (like the early Mario games) and there was no need to add different enemy behaviours (at least for the minimum viable product). Design-wise, the balloon game was a much more interesting project to me, but realistically it would take too long. I decided that for my first project I needed to start small, and pivoted to the new portal project.

The message to all other indie devs

Im sure there’s a graveyard of unfinished titles sitting on different developers’ hard drives, simply because they were too ambitious, or maybe because that person got bored before they could finish it. Pick a project that’s achievable given your timeframe and if it’s possible, cut your scope down to a minimal game. You don’t necessarily have to sacrifice the quality of the game but a basic game on an app store is better than no game at all.

Top 9 tips for indie game developers

Two years ago I started prototyping a html5 game as a side-project while I was in between jobs. Today that project has evolved into a complete game and now it’s roughly […hopefully] about a month away from app store submission. Over that time I’ve come up with a lot of advice that I wish my past self knew when I started and I want to share that information with new and experienced indie developers alike.

1. Don’t design everything at once, play-test early and often

This is really something that tripped me up. This may have not happened to everyone, but I’m sure others have encountered it too. I spent a long time designing my levels up front without properly play-testing them one-by-one first. I found that once I had become familiar with the game mechanic and difficulty of one level, the other levels were a little tedious and I had to design all of the levels again, causing a lot of wasted time and effort. Play-test your level the minute you’ve finished designing it, it may influence how the rest of the game evolves.

2. Ask for feedback

I’ve seen some great games that have been shared on Reddit and IndieDB (I mean, what the hell is this?). Some of which started as a rough concept and then evolved into a great idea by user suggestions. We’re not all product managers or professional game designers - ask the public what they want, don’t tell them what they want.

3. Be humble

This is a follow up on the previous point. I posted a few images of my game on Imgur and Reddit a while back to get some public response. Some people criticised a few of the backgrounds saying that they were too simple or boring. Initially I was a bit annoyed because I’m not a sprite artist and it was the best I could do, but I had to really take a step back and put myself in the mind of the consumer. Are people really going to pay money for a game that is sub-standard given everything else on the market right now? Get feedback, but try not to rubbish people’s opinions simply because they’re negative or not constructive. Try to take something out of it and don’t take it too personally.

4. Decrease your scope

It’s great to have so many ideas that you want to implement but that doesn’t really matter if you have nothing on any app store to show for it. Start with a minimum viable product and iterate on new ideas later. Chances are that someone playing your game might even suggest a better improvement than your original ideas.

5. Give yourself some time off

I’m just going to go ahead and make the assumption that the majority of people reading this will be indie developers working on a personal project outside of their daytime job. Setting goals and deadlines for your game is important, but so is the need to re-energise. I’ve rage quit a couple of times and then ditched my game development from a period of weeks to months, simply because I never took a break. Chances are that extra two hours you spent awake last night didn’t take much of a chunk off your work. You probably even may have introduced bugs because you were burt out. Watch TV, take your dog for a walk, or just go to the pub for a pint. The work will still be there tomorrow.

6. Ask for help

When I started working on my game I had an stubborn sense of pride regarding doing absolutely everything and being able to claim the credit for it, but we can’t be good at everything. If you know a someone that’s good at making sprites then ask them if they can help improve on what you have, ask someone to make music for your game or make a trailer for your app store.

7. Estimate work for each task and then multiply it by five

This isn’t really an indie dev problem but a software dev problem. Have you ever said that some new feature was easy to implement and would only take a few hours only to still be swearing at it a week later? I remember telling my work colleagues last September that there were roughly three weeks before I was ready for release. It’s now February and I still have bugs to fix and marketing to do before submitting to the app store. Moral of the story, be realistic with effort involved and how much free time you’ll actually have on weekends/evenings.

8. Give feedback and engage with the community

Some people might feel like they’re fighting an up-hill battle with so much competition out there, but the way I see it is that there’s AAA game studios and then there’s us. We’re not really in competition with each other and there’s so many awesome ideas out there that just need a little re-enforcement. Engage with other indie devs on Reddit or any other forums. Tell them how they can improve their idea/gameplay/trailer/marketing, or just tell them that you like what they’re doing and to stick with it. You’d be surprised how far it goes, it may even give someone the motivation to keep going when they’re doubting their own work.

9. Know when to call it a day

I think that most developers can relate to the fact that there’s always something that still needs to go into their game, but if it’s playable now and it’s actually a game now then why not just release it and push the update later? Great things happen in the arena, not when you’re in the stands.

That’s just a few things that resonated the most for me. Can you relate to any of them? What advice can you give from your own experiences?

The level editor - make ALL THE THINGS!

Map editors are the bread and butter of game development. Without a decent one you may drastically increase the amount of time that it’s going to take to build your levels. I’m not the most experienced in discussing what’s out there but I’m going to go ahead and re-iterate the lesson from the last post. If you can get away with it, don’t bother making your own level editor, use something that’s already out there. I didn’t listen to this advice at the time because I was a n00b, so I can at least share my creation with the internet.

As discussed in a previous post, I had just completed a bare-bones html5 game engine and was ready to start designing and populating my game world. Terrain data would be stored in a 2d array and entities would be stored [initially] in a 1d array. This was going to be a game that would move across both X and Y axises so there was no way I was going to hard-code every single level. I just needed a means of building the levels and outputting the JSON representation afterwards.

As I didn’t really plan for a level editor in my road map, I was reluctant to put much effor into it though; so here’s what it looked like -

The level editor used for the initial balloon game and the later Cosmic Badger

Adding tiles and entities

The editor initially only displayed the tile sheet to add terrain to the game, but it soon occured to me that I’d need to add the ability to add entities too. The whole thing was just a second canvas element. I could pick individual tiles to add to a grid co-ordinate, or select a group of adjacent tiles to drop in the world in one chunk. I could move around in the game world (i.e. the first canvas element) either by using the mouse controls or by using the keyboard up, down, left, right controls. Once I was happy with my world I could print the output to the web console and copy the JSON into the map using the “Entity map” or “Tile map” buttons. In retrospect I should have added functionality to auto-save the whole game world without copying and pasting the JSON but like I said, it was a rush job.

Adding boundaries

Then I would have to configure boundaries for each individual tile and entity. I had a debug button to display where the boundaries were (the red squares in the screenshot above) and I would have to manually change each boundary co-ordinates and dimensions until I was happy with them. Apart from making the actual levels, this was one of the most painstaking and monotonous tasks I had to do. I wish I had improved the editor to do this drag-and-drop style.

The task of adding boundaries to the game made me die inside a little

Displaying the grid

Nothing much to say about this, I just needed a means of knowing how much space I had between land masses for judging the game reaction time and therefore the difficulty.

Expanding the game world

This wasn’t really built for the purpose of the balloon game, but more so for later on when the game evolved into Cosmic Badger. When I would playtest levels and realised that there wasn’t enough distance between obstacles/terrain. I wanted an easy way to split the game world by 32px by adding a new vertical row of tiles to 2d terrain array.

Lessons learned

As much as I play down what’s there, the features actually came in really useful for debugging issues in the game. The editor and game logic was being run in real time with boundaries and normal controller input. I could effectively move to any part of the level (albeit slowly using the keyboard controls) and play test the area. I’m sure others have different opinions on this, so feel free to start a discussion in the comments section.

Now I had everything I needed to start building a game, time for the “fun” stuff.

Technical implementation of a game engine

I don’t really regret building my own game engine given how much I learned from the experience. I do, however, feel that the quality of my game has suffered from not using a framework such as Phaser.js and if I ever [hopefully] make another game one day then I’ll be going with something like Unity instead. Why all the negativity, you ask? Let’s take a look at the implementation and see.

I chose Javascript to write the engine and game logic as that’s the language with which I was most familiar. I also used a few libraries/tools, which helped me greatly -

  • RequireJS
  • jQuery
  • Underscore
  • Class.js
  • Grunt

RequireJS and jQuery are pretty explanitory, and I just really like Underscore because standard Javascript has such rubbish methods for iterating collections. Class.js is just a slightly nicer looking wrapper (if you don’t know what you’re doing) to implement inheritance in JavaScript. It was already there from the existing game skeleton and if I wasn’t a bit of a n00b at the time I would have never used it and stuck with Prototype. Grunt was used later down the line to minify and zip up the source code for deployment. I also started the project with the best intentions of TDD’ing the whole thing, but with a lack of experience at the time and an eagerness to see results in my short time-frame this never quite happened.

So here’s a class diagram of the the main bones of the game. I’ve excluded some modules as not to over-complicate the diagram but I’ll explain the additions in a later post.

The early Javascript module dependencies of Cosmic Badger

It’s fairly self-explanitory, the Main module contained a MenuLoader responsible for drawing the menus (this wasn’t always the case but I’ll cover that in a later post). The MenuLoader was also was responsible for creating a Game. I’m not sure that was the best design decision, it’s implementation just had the least time impact a very late stage of development. Like I said, I’ll cover that later. My Game module consisted of an [initially, 1d] array of entities which made up the enemies (which were just obstacles that weren’t bound to 32px grid co-ordinates). The terrain data was just integers stored in a 2d array. The integers corresponded to an image’s position in a large tilesheet and the array slot corresponded to the tiles position in the game world, which was tracked by the Camera. This data was stored in the Map module, which is essentially a glorified var containing the JSON game config.

Both the terrain tiles and the entities had their own Sprites (in the case of terrain, a single Sprite), some of which had Animations and Boundries. The Boundry was just a simple box with a width, height and offset co-ordinates from the Sprite image. The Renderer was responsible for drawing the entities and tiles in the Game, the Updater was responsible for updating the Player co-ordinates (based on input from the Controller) and also for checking any boundry collisions via the CollisionDetector. If there was a collision then the Game state would be updated accordingly.

Right, so what’s that red box all about? This box is lined with the bleak tinge of remorse. These are my god modules that got way too big with too many responsibilities. They are very tightly coupled and more a reflection of my inexperience at the time. With more software design knowledge, proper tests and the ability to smell when the code needed refactoring then this problem could have been avoided. Changing parts of this code was time consuming, but I knew it well enough to handle it and I’m just glad I never had to show it to anyone in an interview. To quote BuildKite founder Keith Pitt, it’s not legacy code, it’s founder code. I wrote that when I founded the company!

Building a game engine from scratch is a really difficult problem. If you haven’t been in the industry for a long time then there’s going to a be a lot of things that you don’t account for; and unless you’re a AAA game development company, my advice right now is to avoid building your own game engine altogether and just focus on building a great game. There’s no shame in sparing yourself the hard work and using something that someone else has already built for you. Having said that, if you just want to learn the ins and outs of game development then doing this is a great exercise.

What about the LevelEditor, you say? Calm down, I’ll tell you about that next.

Building a game engine

A couple of weeks later I’m in Melbourne. I’m excited about the potential of my crappy proof of concept and I’m eager to show it to my old housemate, a lecturer of game design at a Uni in Melbourne. His initial reaction to the overall idea was positive. Having a lot of experience in making games, he asked if I knew about using tile sheets to construct game worlds. As hard as it might be for an indie developer to comprehend, I actually didn’t given my two hours of experience in the “games industry”. This was a good starting point. He showed me a game called Browser Quest, which was also html5 game developed by Mozilla to demonstrate the use of WebSockets. The best thing about this game is that the code was available on GitHub and it was exactly what I needed to get going.

Browser Quest, an open source zelda-style RPG developed by Mozilla. A good reference for building a game engine

Once I returned to Ireland I cloned the repo, removed all the server side code (as this was going to work locally on a phone) and stripped all the modules down to their bare bones. I wanted to write the thing from scratch but the existing software design seemed sensible to me so I left the file names there for reference. Other experienced indie developers may probably call me crazy for rolling my own game engine when there are so many good frameworks already out there, but this was a good learning experience for me and the mistakes I made had taught me a lot.

I wanted to take a pretty Agile approach to developing the game. I wasn’t using card walls at the beginning, but it wasn’t as necessary seeing as I was the only one that needed visibility. I basically had a notebook/bible (I’ll talk about this more in a future blog) where I was tracking a list of tasks in order of importance, each of which was scored in terms of difficulty in order to track my expected to progress down the line.

My “card wall” prior to moving to Trello

I’ll briefly discuss the technical implementation in next post, but after about 2-3 weeks of researching/coding I had a very basic game engine which could display entities in the game world via configurable json, a player that moved around using swipe gestures (and some drift physics) and collision detection between the player and the other entities. Now I just needed some shiny things to populate my game world. Now to a sprite artist the following might be a bit of a weird workflow, and it’s justification to how much I was winging it as I went along…

Some rough sketches of placeholder characters to bring the game world to life

I sketched some rough characters in my notebook, took a photo of it and inked the rest of it using my laptop. Here’s a gif of what it looked like, it’s very rough around the edges but I thought the hand-drawn nature had a nice charm to it. This was my first tangible build running using my engine, and a bit of a milestone. Next, I’ll talk about the technical implementation.

The first semi-playable build of my engine

An idea for an indie game

The idea for building a mobile game started while I was in Bali, Indonesia, where I was coming towards the end of a five month career break back-packing around S.E. Asia. At this stage I had pretty much exhausted all of my travel funds. I had another week left there before flying to Melbourne for a couple of weeks and then finally home to Ireland. Aside from budgeting for food and shelter, there was no money left to do any anything tourist-related. In order to pass the time, this left myself with the free options of either swimming in the guesthouse pool or using the internet.

With the time I had to burn I started thinking about what I was doing with my life when I returned to Ireland. I wanted to finally break into a career as a software engineer and decided that I would spend a couple of months working on a personal project in order to have something relevant on my resume. With a nerdy lifelong involvement with video games, I already knew the type of project it was going to be. I just didn’t want to pick up a language that was entirely new to me such as Objective-C and then spend the two months getting to grips with it. I needed something more straight-forward, but something that I was familiar with. This language was Javascript and HTML5/Canvas was one of the new big things at the time.

The Balinese guesthouse where the first game code was written

All I really needed then was a game idea, and it just so happened that I already had one in mind. As a kid, myself and my brother started making a 2D RPG using an application called The Games Factory (that link shows how old it is now). The game that we made was called The Andrew W.K Saga (mainly because the main character looked like Andrew W. K.) and it was actually the stupidest game ever! There was no real consistency to any of the levels or the controls, it was just a funny to make and it got dumber and dumber as it went along. There was one boss level where a giant cow-like creature was being pushed back and forth on a wooden kart by some gimpy looking old man. There were rocks falling from the ceiling which you had to avoid by moving the keys left and right. In order to kill the boss, there was a target randomly moving around the screen which you had to click whenever it crossed over the cow thing - all to the score of that crazy cuccoo catching mini-game music from the Zelda games (it wasn’t exactly copyright-friendly). That wasn’t the idea I had in mind by the way.

Sketch of said cow - I don’t know how I came up with this and at this point I’m too afraid to ask

As ridiculous as the game was, there was one level in it that really stuck out as being enjoyable. Your character was stuck in a hot-air balloon and you had to navigate a slalom of enemies and spikes using the arrow keys to move left and right and then the space bar to hit the fuel line to go up, much like those one tap helicopter games that are everywhere except that you could move up and down in the game world too. While the idea was nothing special in terms of gameplay, I had ideas about the characters I wanted to put in it and the game world that I wanted to create which would hopefully make it stand out from other games of that kind. After about two collective hours googling html5 tutorials and hacking code I had created an extremely crude spike that verified that it would be possible to make the game.

The proof of concept for the initial idea. A friend told me that it looked like a sock puppet. MS Paint FTW!

For anyone technical minded, and curious about how I did this - the game world was basically a huge background image for the whole level with the main character always remaining in the center (edited in MS paint using a touchpad for professionalism). The game background was translated on the canvas every time an arrow key-press was detected and there was some hardcoded logic in there to determine if your character’s co-ordinates were within a single enemy’s boundary. If you were then it was game over. Now, if anyone thinks that this screenshot is an indication of the final product then please just keep reading. It does get better, I promise!