November 1GAM – Five Man Team

Given that it is still October, it is perhaps premature to be releasing a game for November. However this project came together rather quickly so I saw no need to delay. Plus my December project is quite ambitious and will coincide with a time of year that is rife with interruptions so I thought it best to leave myself some contingency time.

My November project is a simple top down real time strategy game called Five Man Team. I did consider naming it Five Person Team or similar but it just didn’t have the same ring to it.

In a series of matches you face an opponent who is leading a team of five units that are identical to your own. Both the computer and yourself have the same units, the same rules are applied to you and you have absolutely no advantages or disadvantages over the computer opponent.

You control the unit’s movements but not their firing. I did actually have code in there at one point to allow the player to set targets but then you get odd situations where a unit is ignoring incoming fire while trying to chase down some fleeing target and it just felt more and more like you were controlling mindless automatons who did not care if they died, which you essentially are but there’s no need to highlight that.

The shots fired by units are most accurate when the unit is stationary. They become less accurate if they are moving. They are less accurate again if they are moving while firing at a target off to their side. They are really really inaccurate if they are moving while firing at a target behind them. To figure out the direction of the target versus the direction of movement I used dot products.

This has the unfortunate side effect that the best strategy is to “dig in” by clustering your units together and sitting and waiting for enemy units to wander into range. This seems quite realistic from what I know of modern warfare. Better to be the guy hunkered down in the defensive position than the guy charging into a hail of gunfire. This kind of sit and wait, sentry duty simulator style of play just isn’t particularly fun. To make this a better game I would need to either add some reason for the player to have to move or tilt the odds, perhaps by having a small team facing waves of attackers.

I did have plans to implement both obstacles and A* path finding to allow the units to negotiate those obstacles. I’ve implemented an A* algorithm in Java but never in Javascript. The reason for abandoning this idea is primarily excitement about my December project. I am drawn like a moth to a flame to things I have not implemented previously.

So, finally, here is the game. Hopefully someone out there enjoys it if only for a few minutes.Five Man Team

The code (such as it is) is available on github.

October 1GAM – Endless Goblin

A while back I happened upon a great tutorial from Lost Decade Games about making a simple HTML 5 game. It’s a simple tutorial but I wanted to have a play with it to make sure I wasn’t missing anything obvious about this HTML 5 business.

A few days of sporadic tinkering later and I’ve got something mildly entertaining (I think). The code is completely unrecognizable. Basically all that remains is the hero, the goblin and the background graphics.

I called it Endless Goblin because, well, it needed a name and Endless Goblin struck me as kind of amusing.

It’s pretty crapulent as a game. It desperately needs some variety among the enemies and probably some pick ups. Different weapons and what not. The collision detection with the fireballs is also a little bit dicey. I do however now have a bit of a framework should I decide to come back and have a more serious go at making an “arena” style game.

Anyhow, I’ve probably talked it down enough. Play Endless Goblin

The git repository is at

The fireball animation is from

The explosion animation is from

September 1GAM – Ascent Part 1

This month I’ve cheated a little. Although I’m passing it off a game its more a of a playable prototype. Truth be told this is the beginnings of a much larger and more ambitious project. Initially I had grand plans about getting that whole project done in a month but I quickly realized that that wasn’t realistic if I wanted to keep my job, keep my wife, make some progress in my other projects and also get some sleep and maintain a basic level of personal hygiene.

One fairly cool feature that I did get done is the automatic generation of the cave structures. The code is based on a tutorial on It’s pretty neat. Partly because it provides some replay value and partly because it spared me the task of manually creating levels.

It’s possible for the cave generation process to create a system of multiple caves that are completely independent ie not connected at all. To make sure that the player is not being placed in a cave with no possible path to the exit I’m doing a non-recursive flood fill. If the exit and the player do not cohabit the same cave the level is thrown away and regenerated. Simple but not super efficient.

To provide a little bit of challenge the cave is populated by UFOs who charge the player. Right now their AI is abysmal. This will definitely be improved. I haven’t had much experience with game AI but now is as good a time as any to learn.

I think that’s pretty much it. I still have a few more months to go before I have completed my twelve month run in One Game a Month. Many months ago I made a commitment to produce something every month for one whole year and I intend to stick to it. However my attention is increasingly being drawn to projects like this one that I intend to revisit after the year is up. Projects where I can see the potential to make something I can really be proud of. For the rest of 2013 I’ll be sticking to the one game a month format but after that I’m looking forward to picking a larger project and sinking my teeth into something more substantial.

Oh yeah, the game… Here you go. Ascent Part 1.


The art, music and sound effects are not my creations.

The fighter and UFO graphics are from Open Game Art.

The UFO attack noise and the explosion noise are from Freesound.

The music is from

August 1GAM – Run Block Run

Another month, another game. I figure it was about time I tried my hand at an endless runner. It’s implemented in Javascript/HTML5. Its a pretty simple game called Run Block Run.

Run Block Run is very simple to play. There’s only one button involved. J to jump. At first you can only jump once. After a minute you can double jump. After two minutes you can triple jump and so on up to five.

There were no major headaches with this. The usual collision detection bugs to iron out but nothing major. There’s no music or artwork to load which avoids one common source of issues, downloading and managing files.

I took a slightly novel approach to development. First, I built each major visual element as a standalone project. Once that was done all I had to do was gaffer tape the whole thing together. Here are links to the individual components.

This style of development worked quite well and helped me focus on completing one thing before moving on. Otherwise I’m inclined to hop around. Ultimately the work still gets done but taking it piece by piece certainly gave me a strong sense of getting stuff done.

Now that its finished, to be honest, I’m not particularly happy with how this turned out. I feel like my projects are progressively becoming more polished but I just don’t feel like Run Block Run is actually that much fun. I don’t actually play endless runners much so maybe that’s the issue. Don’t try to make a game you wouldn’t normally play yourself.

You can play it on New Grounds, Game Jolt or Kongregate.

Things to discuss before you get married

As a way to learn node.js and to get familiar with Heroku I recently built Its a simple piece of software that randomly outputs a topic for conversation between two prospective partners.

It works fine on a desktop but is primarily meant for mobile devices which is why it looks rather sparse.

It was a good learning experience and, in my opinion, its easy to leap into marriage without having had serious conversations about important topics. Learning new technologies and solving relationship problems. Look at me go.

Things to talk about before you get married

July 1GAM – Mine Runner

Another month, another game. This time it’s a Boulder Dash style game called Mine Runner.

I previously posted a prototype version of the game and attempted to find an artist to collaborate with (the prototype post). That was completely unsuccessful and I was forced to press on using free resources available on the net.

Before I dive into what I learned I feel like I should just cut to the chase. Here is the game.

Mine Runner is now playable on several other sites.
Mine Runner on New Grounds
Mine Runner on Kongregate
Mine Runner on Game Jolt


All programming, writing and anything not specifically mentioned below was done by me.

The dirt image is by Axolotl and is available from

The diamond image is by Sekulus and is available from

The boulder and brick images are by thomaswp and is available from

The monster is by qubodup and is available from

The three characters are modified versions of characters by “/usr/share”. The originals are available from×16-8-bit-rpg-character-set

The death sound is

The rock fall sound is

The music is from

What did I learn?
In a Pygame platformer that I made previously I stored my map data as a small image file, a png specifically. Determining what is contained in each tile of the level is simply a matter of retrieving the pixel data from the image.

To get this to work in Javascript it appears to be necessary to draw the image to an off screen canvas. A slight annoyance. I spent a bunch of time convinced there must be a way to directly retrieve pixel data from the loaded image but apparently not.

I also ran into this curious message. “Unable to get image data from canvas because the canvas has been tainted by cross-origin data” This is because I was loading the web page from a local file path but the image was being loaded (apparently) via a web style URL. Simply switching from accessing the page via the local file system to accessing it via http://localhost/blah made the browser happy.

I’m quite happy with how it turned out. It’s not a long game. Hopefully it’s challenging. I tried to inject a little humour and to introduce a more relate-able story line. Have fun 🙂

Game Portal Post Mortem

A month ago I posted my first HTML5 game Blue Ball Defender to three different web game portals. Game Jolt, New Grounds and Kongregate. A month has passed and I thought it was time I reported what’s happened.

Number of Plays

How many view/plays did each portal deliver.

Game Jolt – 37 views 10 plays
New Grounds – 1403 views
Kongregate – 76 plays

I’m not entirely sure what the deal is with Game Jolt providing two numbers. Perhaps they’re detecting the user moving focus to the game. I haven’t investigated.

The clear winner here is New Grounds. New games on New Grounds go through an initial period called “under judgement”. During the under judgement phase your game is rated by users interested in seeing the newest games. Eventually your game is either accepted into the main collection of games or “blammed” and removed from the site.

During the judgement process Blue Ball Defender had approximately 1000 plays in 3 days. After that the number of people playing it took a major dive. This may not have occurred if my game was better and thus received higher ratings (I’m realistic about the game).


Which site provided useful feedback?

Game Jolt – No comments. Absolutely nothing.
New Grounds – 8 comments. These included some useful suggestions for improvements.
Kongregate – 1 comment.

Again, New Grounds comes out in front. The New Grounds commenters made meaningful suggestions and even returned after I had acted on their suggestions.

Cold Hard Cash

All of these sites provide revenue sharing for game makers. I was never expecting much and given the modest results that was probably a good thing.

Game Jolt – $0.02
New Grounds – $0.0
Kongregate – $0.05

New Grounds is in last place here but you’ll notice that the amounts of revenue are so small that it’s pretty much a tie. We’re talking about the difference between zero and one ad click. All of them have a minimum payout threshold of around $25 so I’m not holding my breath to see any money appear in my bank account.

Final Thoughts

Overall New Grounds appears to be the most useful portal however there’s no reason not to use all 3 sites. I’m not suggesting you use only one.

The initial big surge of views on New Grounds during judgement followed by a big drop was interesting. Given the constructive nature of the comments I received during judgement I suspect that New Ground’s users consist of, in large part, fellow game makers. Fellow game makers who periodically check in to try out the latest submissions. After the game was past judgement they moved on.

Mine Runner: The Prototype

Here is the prototype of my July One Game a Month project. I have tentatively named it “Mine Runner”. It’s a homage to two games. The well known Boulder Dash and the less well known FlaschBier.

For those of you who don’t know them this is Boulder Dash

And this is FlaschBier. I played this quite a bit on an Amiga 500 when I was a kid.

And this is the prototype version of my attempt at a similar game. There are only two levels. If you die it instantly reloads the level. There’s no sound as yet. The red squares are impassable. You will notice, I’m sure, that it is ugly as can be. The orange circles are boulders and will crush you if you venture beneath them.

It’s ugliness brings me to the point of this post. Previously I’ve either gone with free art found on the Internet or come up with project ideas that allowed me to get away without art. This time I’m wanting to try something different.

I’d like to find an artist to collaborate on this. I’m not offering any payment nor do I expect this to make any money. I feel like I’ve got a basic workable structure done but I need someone to help me make it look presentable. Plus I’ve never collaborated on a game before and this is as good a time as any to start.

Oh, also, level design. Currently there are only 2 levels and they’re not particularly great. It would be nice to have 20 or so. If the other half of team Mine Runner would be happy to help produce levels that would be awesome.

Level design is easy. Each level is an image. Each pixel represents one tile in the level. Blue for diamonds, grey for boulders, red for impassable stone and so on. Green will be monsters but they aren’t implemented yet. To edit a level you open the image in gimp or whatever, zoom way in and get editing. The game loads maps from the maps directory. It starts at 1.png, then 2.png and so on until it runs out of map files.

That’s pretty much it. Make nice graphics. Share level design. Help make it as awesome as it can be in the time available. I’d like to have it all done by mid July.

A little about me. Click here for my profile on One Game a Month. I’m also magictravelblog on reddit. Magic Travel Blog is a travel blog run by my wife and I. I’m a professional programmer although I’m a newbie at game development.

I’m happy to share 50% of any revenue, should there be any. I don’t expect that there will be. It would be nice to be able to see some examples of your work but I don’t care how experienced you are (or aren’t), how young or old you are or where you are in the world.

This is all an ongoing experiment. If either of us is unhappy at any point we can just walk away. Me with my code, you with your art. But hopefully it doesn’t come to that. Messaging me through reddit is probably the easiest way to get my attention if you’re interested.

June 1GAM – Blue Ball Defender: Web Edition

For my June One Game a Month project and my first every HTML 5 game I’ve reused a little trick designed to make it easier to learn a new technology. My May project was a game called Blue Ball Defender implemented in Python/Pygame. Having made the decision to transition to HTML 5 I decided to simply reimplement Blue Ball Defender in the new language. There will be plenty of time to tackle exciting new projects once I’ve got to grips with the basics of HTML 5.

To make the transition even easier I completed the HTML 5 game development course on Udacity. I’m a big fan of online courses and have completed quite a few of them. Sadly, I was not particularly impressed by this one.

It appeared to be run by a group of Google developer outreach people, not teachers, which probably explains why there was very little teaching going on. It was more like an extremely detailed code walk through. It was useful for me as I was able to collect some useful looking bits of code but unless you have done a little game development before and have a pretty solid programming background I would not recommend it. One minute we’re learning how to display an image, the next we were talking about multi-layered map data.

If you’re looking for a course to get started making games check out Coursera’s interactive Python course. It offers a far smoother ramp up and you’ll build a series of increasingly complex playable games which is far more enjoyable than plugging away at the pieces of a single large project.

Back to Blue Ball Defender. The process of actually recreating my game in Javascript in Chrome was relatively painless. I find the syntax rather unintuitive but you get used to it. The inheritance, or lack thereof, is also a hassle.

Fortunately Blue Ball Defender is relatively simple and only uses a handful of resources. Dealing with images and sounds is a real pain in Javascript. You need to be conscious of whether or not the resource you need has loaded yet and be aware of the loading process. Compare that to a local application where you can pretty much just ignore the time it takes to load an image or sound file from the hard drive.

One significant side effect of the need to more carefully manage your resources is that I have removed the music. The download time for a 3MB mp3 just seemed to slow things down. Maybe it’s just my net connection. It’s probable that there is a smarter to way to deal with music but I’m unaware of it so, for the time being, there’s no music. I’ll figure it out for my next project.

After I had it up and running in Chrome I tried it out in Firefox. Urgh, the spacebar press to start the game isn’t registering. Once I resolved that the mouse clicks weren’t working correctly. Briefly, here is what I did to get it all working in both browsers.

It appears that the keypress codes for the two browsers are different so my on key press handler was not correctly identifying a spacebar press. I read a page about Javascript key events, switched from using the keypress event to the apparently more standard keydown and that resolved one of my problems.

The mouse click was more hairy. I was originally using plain old event.x and y in Chrome and that worked nicely. However, those variables didnt exist in Firefox. Other variables do but they report the mouse click location relative to the top of the window or some other unhelpful location. I needed the coordinates relative to the canvas top left.

What finally worked was a combination of this and this. There may be a simpler way but this appears to work and will do well enough.

Here is the final version. I’m sure that we can all agree that it’s hideous.

function onMouseClick(event) {
    if (gState == State.INGAME) {
        var mouseX;
        var mouseY;
        if ( event.offsetX == null ) { // Firefox
            //mouseX = event.layerX;
            //mouseY = event.layerY;
            if (event.pageX || event.pageY) { 
              mouseX = event.pageX;
              mouseY = event.pageY;
            else { 
              mouseX = event.clientX + document.body.scrollLeft + document.documentElement.scrollLeft; 
              mouseY = event.clientY + document.body.scrollTop + document.documentElement.scrollTop; 
            mouseX -= gCanvas.offsetLeft;
            mouseY -= gCanvas.offsetTop;
        } else {                       // Other browsers
           mouseX = event.offsetX;
           mouseY = event.offsetY;

        gMissiles.push(new FriendlyMissile([mouseX, mouseY]));

Right now I’m quite negative about the whole experience. It’s certainly nice to be able to play in the browser and I suspect it will be far easier to attract players because of that but Javascript introduces new headaches without really offering much in return. It’s painful but necessary. Like a trip to the dentist.

Anyhow, enough of me banging on. Here it is.

Now I need to work out what I’m going next…

May 1GAM – Blue Ball Defender

Another month, another game. For May I’ve prepared an homage to the classic Missile Command. However instead of defending a city at the bottom of the screen you must instead defend a small blue planet in the center of the screen. I call it Blue Ball Defender.

Development was fairly straight forward. There’s a graphic for the planet. The missiles and explosions are just shapes drawn via Pygame. Some music and sound effects completed it. The only slightly tricky bit was a little bit of trigonometry. That was needed to aim the incoming missiles at the planet, to aim the outgoing missiles at the locations chosen by the player and to choose their spawn points as the outgoing missiles need to be initially positioned at the point on the planet’s surface closest to their target.

It’s pretty simple and it all came together rather quickly. So quickly in fact that I found myself wanting an additional challenge.

Rather than using a background image I decided to try my hand at generating a star field. I’m sure there are sophisticated ways to do this however I just randomly chose locations on screen and drew a white dot at each. Possibly for the first time in my programming career I wrote the code, saved it, ran the program and it worked perfectly without so much as a typo. This literally took twenty seconds although I then spent 5 minutes saying “that can’t be right, code doesn’t just work!”

So much for additional challenge. What else can I take on?

All of my previous Pygame games have redrawn the entire screen with every frame. It keeps things simple but can negatively affect performance. The alternative is “dirty rect drawing”, rect being short for rectangle. In dirty rectangle drawing you flag the sections of the screen that are dirty ie that require redrawing. This requires you to build up a list of rectangles covering the changed areas of the screen. You then supply that list of rectangles to pygame.display.update(). It then unions your rectangles together and selectively redraws portions of the screen.

Implementing this was actually fairly painless. I eagerly rushed to gather some statistics so I could see how much faster it was. The results were uninspiring. Dirty rectangle drawing caused my game loop to execute slightly faster but not dramatically. I suspect this is because either I’ve implemented it wrong or I’m simply not demanding enough for the difference to become apparent. At worst, regardless of the drawing method used, the main game loop is never being executed less than around 150 times per second on my laptop. That number can spike up to around 500 times per second during quiet moments.

The whole dirty rectangle business probably wasn’t worth bothering with for a game as simple as Blue Ball Defender. But at least I now have some idea of how it’s done for future projects.

That’s it really. This has been a really painless project.

Hopefully my next project will be a HTML 5 game. I’m just finishing up a Calculus course I’m doing on then I’ll get through Udacity’s HTML 5 game development course. With that under my belt I’ll make the switch from Python/Pygame to HTML 5.

You can get Blue Ball Defender from github at git://

Here is a Blue Ball Defender Window’s executable