Refocussing After A Month

It’s about a month into this game-a-day project. It’s time to assess.

  • My sound and graphics skills are improving. That’ll continue. I’m happy with that.
  • Finishing a complete game in a day is not always possible (and is often VERY stressful)
  • I’m starting to hit a number of key (but significant) algorithms that I’ll be able to use a lot. However, they’re subtle enough they’re definitely going to take more than a day to get fully debugged. This includes path finding (any time any enemy is chasing you – Make A Maze), flocking (groups of enemies – Flock), even just seemingly basic stuff like sorting out reliable and intuitive collisions (Sugar Rush), and collision avoidance (the path finding again). Procedural terrain generation (Terrain) is probably not so useful, but the general concept of procedural content is VERY helpful (eg random dungeons). These are the kinds of core algorithms I’ll end up using all over the place. They’re worth taking a few days to get right.
  • Since the aim of this project is to create mobile games, I’m going to need to take some time simply focussing on the mobile side of things. I wouldn’t be surprised if that takes a week, across a few games.
  • If even a moderately good game is not going to be ignored on initial impressions, there’s a basic level of polish (splash screen, credits, links to online stores/reviews, feedback links etc) I’m going to need to figure out how to efficiently apply to every game I create. I’ve been patchy and inconsistent about this so far.
  • Taking a couple of days to polish a game to be significant fun and clean up around the edges (ie, an actual playable fun game) is time much better spent (and more fun for me) than leaving a trail of half-finished games behind me – which is what I have been doing, more often than I’d like.
  • I need to get more focused on the specific attributes that make a good mobile game (rather than just a good game).  Namely – immediate fun, easy to learn but hard to master, very simple interface, simple concept, low complexity (battery life), ideally language independent

To be fair, given my background in artificial intelligence and finance, I’m something of an algorithm geek. I love love LOVE tweaking and perfecting algorithms. So, I’ve been having fun with all these larger scale projects (flocking, path finding, swarm intelligence – and biomimetics in general.They’re useful, but I am getting a little off point. I need to refocus a little more.

However, these are generally useful algorithms, and most of them are near done, I reckon.

So, from here, my immediate path is:

  1. Get the flocking, path finding and ant algorithms working satisfactorily (and put them into the appropriate games so those are closer to done/fun/useful)
  2. Devise a consistent and decent structural polish for the games (opening screens etc) and retro inject them into all games (and my templates, of course).
  3. Finish up the specific games which are “almost done”, but which have decent potential – Relaxing Fishing (maybe), Bukowski (definitely), Sugar Rush, Space Inverders (maybe), Boring Tennis, Make A Maze.
  4. Start building for the mobile platform. I need to start skilling up in that area

I still believe I can get to the point of hammering out a decent game in a day. My skills are definitely speeding up. However, now is a good time to regroup, get some solid structure in place, and tighten up a lot of the core assets I’ll be using dozens or hundreds of times a year. It means a shorter term delay but getting these core elements optimised will speed things up immeasurably over time.

The trick now is to do it while wasting the least amount of time possible.


a) ants are cute

b) ants are super interesting how they optimise large scale problems (like finding food)

So, following on from my flocking experiments (although hopefully a bit simpler) I’m mucking around with ant hunt algorithms.

The basic gist of how ants find food and tell their buddies where it is is – they walk about, leaving pheromones behind them.  If they find food, they then follow their own path back to the nest, strengthening the path. As the other ants are walking about, they’ll tend to follow a stronger (more smelly) path than a less smelly one.

This is all really rather cool. I like the idea of second-order control. You do things to the environment to try and improve the ants’ behaviour, in order to achieve a goal. Should be fun.

Ok. So I have the ants appearing, walking around randomly, and (when they reach the edge of the screen) retracing their path back to base and dying. Awesome. Their trail gets printed out – which is kinda cool, so you can see where they go. There’s an ugly big bit of apparently unidentifiable food (it was supposed to be a sweet, dammit, time for a new image) in the middle of the screen.


  1. Make previous paths influence path choice (ie, if there’s a strong pheromone laid down, other ants will follow it)
  2. Make the “found the food!” thing a thing

The second one is trivial. The first… a little more interesting.

Ha ha. So, I’m making the ants a bit smarter – they’ll smell a pheromone trail if they run over it, plus run less distance away when they’re following a trail. Previously they’d just target roughly the same direction (but a bit finer tuned). The flipside is, they’re now behaving like maniacs. Ha ha.


Sugar Rush

I had an idea for a cute little game. Race around a shop eating candy, while avoiding the shop keeper. Pretty simple stuff, but with some nice added twists (sugar rush and sugar crashes screwing with your ability to see/control yourself). It had the potential to be actually quite a lot of fun.

I found & tidied up some cute characters. Got a base environment sorted. Draw a maze.

Here’s where it all fell apart. Collisions. Specifically, the player character getting stuck on walls.

Oh. Man.

I spent, literally, hours, trying to get this to NOT suck. I don’t think I quite succeeded.

Specific problems:

  1. Despite square collision shapes, I would often get collisions on both the side AND top of a tile (at the same time) that was part of a long flat wall
  2. There’s no way to tell if there’s a tile in a specific location.
  3. Even with rounded (or softened cornered) collision shapes on the actor AND on the wall, they would “get stuck” on the edges

#1 just makes it unnecessarily harder to tell HOW we’re colliding with a wall. Also, how is it possible to hit the top of a tile in a vertical wall (ie, collide with the -inside- of the wall)

#2 is a problem because if we walk into a long wall, we can’t tell if we’re trying to walk around an edge, or walking perpendicular in to a long wall. The former we should edge around, the latter we should just stand next to/collide with).

#3 is just frickin’ tedious

So really, despite spending the whole day writing code, I couldn’t work my way around this sucking. Simply trying to control your guy moving around the maze feels ugly, difficult, painful. NOT FUN. It’s subtle, and I’m sure to some people it’d be fine, but to me? It sucks. And I can’t fix it. Frustrating.

If I can’t move a guy around a 2d space without these kinds of horrible things making the whole control system ugly, it pretty much screws any kind of 2d top down game. And we’ve already discovered that platformers are horrible.

I feel like the design environment is pushing me into building a very specific set of games. Also not fun.

Oh, it also meant (because I couldn’t get the core loop de-uglified) I didn’t get to building any of the actual real game play. I shouldn’t be wasting so much time battling these super fundamental aspects of game building.

So. An interesting epilogue. I went back the next day (today) and had another look at things. a) I discovered that I can tell if tiles exist (VERY helpful), but b) I tried ripping all my code out, and using a diamond shaped collision zone (among ten or so other things). Turns out, that actually worked pretty well. It’s not super great – you can still get your head stuck on walls etc (which is tedious) but it’s “good enough”. So, while the game itself isn’t really there, at least that’s core progress.



I’ve wanted to do this for years now, since I first heard about them.

And by “this” I mean have a play with flocking algorithms. What’s a flocking algorithm? Well, ever see birds in the sky? How they move around, kinda altogether, but not too close, not too far away? Yeah. This is like that.

These algorithms CAN get very complex, but I’ll just start with something relatively simple. See how they’re all bouncing around the dot? The dot is the centre of mass for the group. What I’m trying (and failing, currently) to do is get them all to point where they’re going (ie, towards the dot). So, more geometry for me!

Now unfortunately, I lost most of today getting my Haxe build cycle sorted out. Yes, I spent a day to cut my build time down from 10 seconds to 0.3s. Worthwhile? Well, when I’m working on complex code (which so far has been Terrain, Make A Maze and Flock – but is going to be increasing chunks of games in the future), I could be running this compile hundreds of times a day. Being able to do it in under a second instead of ten makes a HUGE difference. Not only does it radically speed up the write/test/debug cycle, it also minimises interruption to the thought processes – the key bit. So yeah, a bit tedious, but worth it long term.




Initially this was going to be a “run away from the raindrops” kind of thing. Something simple.

However, now I’m just thinking I might just try to make something beautiful and peaceful.

At present, the rain sound is obviously a lot heavier than the actual rain you’re seeing.  The plan is to have smaller droplets as well, not just the widening circles. So far though, I quite like it. Oh, you can click and create your own raindrops if you want. And all artwork by me (for a change). So, slowly improving. Not a heck of a lot, but I’m learning – which is what this project is really all about.

So I now have an absolute ton of raindrops – which is very satisfying. Not having to worry about them colliding with anything speeds them up enormously.

The major problem I had with this game is – rain is fast. If you’re dodging it, how could you possibly see it quick enough to adjust? Not unless I had ridiculously humorous rain, of course. So, no real “game” per se was forthcoming. More of a low key art piece. That’s ok. I learned some useful skills, which I’m sure will pass forward.

Besides, my major priority with this was to make something beautiful. Also a very different art style from what I’ve done before. The pixel skills I’m slowly growing definitely came in handy making the tiny droplets (although they still ended up way too large and had to be shrunk down)


Flappy Pipe

I think you can see where this game is going. *cough*


You know, it’s REALLY easy to make a crappy version of this game. However, there’s actually an absolute TON of subtle stuff in it.

Now obviously for me, the trickiest bit is – how do I make it LOOK like there’s a shit ton of actors on the screen (I wanted it to be super threatening) without actually needing that many? So, a LOT of time in photoshop trying to get that working.

Key thing though, this really is a (not so) hidden gem. Eg, those diagonal stripes at the bottom? Holy shit they took me a long time to get (almost) right. Of course, I’ve never done tiles before, so there’s that, but still. The original game had some subtle distance-lighting going on, that I haven’t quite got right.  Of course, the images are shamelessly stolen, but really, in his own quiet understated way, Dong Nguyen is quite a subtle brilliant game designer.

Ok, so this has taken WAY longer than it should have. Almost done though. Cute animations, awful sound effects, stupidly frickin’ difficult. Just need to resize the bird bars and add a few more animated birds and I’m calling this done. My high score? 1 (my high score on Flappy Bird, I swear, was over 40). I rock!

Obviously, there’s a bunch of things the original has done way better than I have. For example – the horrible jaggedness on the tile at the bottom. The distance lighting on the city. The pipe still doesn’t move quite nicely – it’s a bit too jerky to control well. There’s no splash screen (or explanation of how to play). The high scores don’t get uploaded anywhere.

On the upside, it’s cute and frickin’ hard. Which mostly just cracks me the hell up.



Today I thought I’d have a play with procedural terrain creation. I found a relatively straightforward javascript implementation, so thought I’d have a go porting it over to Haxe.

This, of course, is vastly more complex than anything I’ve done before.

In theory, it’ll end up looking something like this:


What I have so far looks like this:


Oh, and also drags the entire machine to a grinding halt.  One key issue – much as the same problem I had with Fly Lines, I haven’t yet figured out (how/if) I can control the screen refresh. If I’m showing a static image, I REALLY don’t need to be trying to refresh that 60x a second. Particularly if the creation of that static image a) doesn’t change much, and/or b) was computationally complex to create.

*cough* I may have bitten off a little more than I can chew here.

Moving slightly forward. Things now look like this:


Which still looks like bollocks. More concerning is that it drives my machine into the dirt, and takes about 5 seconds to render. Ie, even if I get it sorted completely, it’s still going to be utterly unusable. Which is a real shame.

Hmm, closer. And re-rendering every couple of seconds:



This is getting weirder. This is now super fast (updating multiple times a second), but I have no idea why it looks like this:



Still SO many questions with this piece of code:


What the hell are those two black squares at each corner all about? Why is it only dumping out on a weird sideways angle? What’s the giant patch of blue all about? (doesn’t LOOK like there’s any “forced lake” in the code) Why is it all yellow, when the original had no yellow in it (am I screwing up alpha values?) How the hell can I store this data once generated, so I don’t need to refresh the whole thing every frame (thereby grinding the machine to a halt) etc etc etc.

Needless to say, there’s still quite a lot of work to get this game ready – let alone turn it into anything useful. That said, I got to learn a whole ton about injecting generic code into Stencyl, operating with external editors, debugging Haxe, the Haxe syntax and common objects and so on. So, definitely time well spent, even if it’s not anything particularly playable or useful.


Crappy Missile Defense

This is the core rudimental of a missile defense game.

Perhaps unsurprisingly I started with a VERY different game. One of “those” days (they happen).

I’ve always quite enjoyed playing this game. This one has some minorly interesting characteristics.

I drew all the art myself, so that’s something. It’s still not “great” per se, but I’m seeing small-but-subtle improvements from day to day – which is good to see. I quite like the city, pre and post disaster. Starting to get my head around pixel art. Or at least, the most basic aspects of it. It’s a start.

There’s more trig – aiming the missiles at each other (and getting them flying in the right direction), along with some interesting manual collision detection with the explosions (since the object size changes radically as the explosion expands – you don’t want it ‘hitting’ if the explosion is visibly small and the enemy missile is not yet engulfed by it). Oh, plus some subtlety with getting everything to align (since all the objects are different sizes – otherwise the explosions etc won’t appear to happen in the correct place).

It can be played by just spamming the fire button – which detracts a little from the enjoyment, but it’s already hard enough, without limiting how many missiles you can fire at once. It could be set like that, but I’d need to radically lower how many missiles drop out of the sky at once.

So, not great, but nice enough for what it is. A little more potential, but it starts reasonably tricky, and ramps up quickly. So, hard enough to be at least mildly interesting.


Fly Lines

One of the things I’ve always admired about games like Flappy Bird and Tiny Wings is that at their essence, they have a single control – touch the screen.

I LOVE that simplicity.

Now, so far, my control systems have been very keyboard oriented – or even keyboard+mouse, however, I’d like to get closer to that bare bones minimalism.

At this point, this just allows you to draw a whole bunch of lines on the screen. Like this:


Exciting, yes? I’m not sure where it’s going to go. I have very limited power (as far as I’m aware) given that I’m running inside Stencyl, but I’ll see if I can do anything interesting with it.

Alright, I’ve added different size lines. Which is.. mildly interesting? Dunno. I guess diff colours would be the next thing (although a lot fiddlier than diff line sizes). It bothers me that the lines are rounded on the end though. It’s not defined enough (but I can’t think of a clean way to sort that out). And really, what am I going to do in a day? Build a photoshop clone?

This happens. Getting lost in the middle of an unusual game design. I’m not too surprised by it. I’ll just keep plugging away. See what, if anything, comes out of it.

Ha, oh boy. Ok, this gets sillier. I figured out (quite quickly) an excellent algorithm for squaring those horrible rounded lines. Which works perfectly… unless the line is on an angle. Damn. So close. Well, the horizontal and vertical lines look excellent.

Wow, ok, trig. Ha, that brings back memories. I did a whole bunch of math. Nothing complicated, just fiddly, and lots of it. That got me as far as this:



Obviously the boxes are still a little large – however, the hard bit has been done – calculating the correct x,y relative positions for each of the four corners off each end of the line. In other words, the square box is on exactly the same angle as the line – hooray! Notice how by default the line is rounded? Yeah. *shudder* ugly. So, a little further on this:


Close, but still not quite right. A small revelation and voila:


Which is brilliant. Exactly the same width and orientation. Brilliant. Change the colours back and it now allows you to do neat things like this:


Which I’m sure someone of a vaguely artistic bent would be able to do something quite pretty with. Regardless, I’m happy enough with that. Plus, as a bonus, it was great to dust off some math I haven’t used in 20 odd years. Getting trig functions straight in my head will definitely be useful, since any placement, positioning or movement will use it. It’s going to come in handy, no question about it.



Right. Time for a drinking game. Hence, Bukowski.

The basic premise for this game is to balance drunkenness, thirst, inspiration and productivity sufficient to write, then sell that writing – using the money to survive.

Of course, this sort of game is going to require a LOT of careful balancing. So, rather than going straight out and building it all into the game engine, I’ve created the game in a spreadsheet. That way I can very quickly/easily tweak the settings until it starts to feel right. The spreadsheet looks like this (although I’ve hidden the values – as they’re kindofa game spoiler)

excel model


Ok. I spent a LOT of time tweaking this. It was definitely a good idea to model it as this enabled me to very quickly iterate through hundreds of variations of combinations of the influences. There are now a ton of interesting behaviours, and the whole thing is very subtle (and not TOO easy). Obviously, there’s also a ton more I can add in there.

Now, in terms of the actual game, I’ve managed to get the main interface in play and working. Essentially, it’s currently a test rig. You can click buttons to move values up and down and see how they change the interface. The core code/game hasn’t been put in there yet – however, since I’ve got all that already modelled, it shouldn’t be too hard to get in there.

That said, I’ve really gotta put it to one side and get on with today’s game. Dammit. I’ll get back to this.


The mission: Create a Game. Every day.