Jump Cat

Ugh. Another horrible day.

I started off trying to do some weird flappy bird – just for a laugh. But (surprise!) it ended up being a ridiculous amount of visual effort. Uhh, coz of the way I wanted to do it.

So, that wasn’t going to come together.  Then, I discovered how to do joints in Stencyl. That is – items connected together by a single joint. So, you can have swinging motions etc. That got me a little excited.

Here’s the problem though. Jeeze, I hate platformers. I suck at them. I’ve just never liked that whole twitchy finger juddering pixel-perfect nonsense.

Needless to say, this has come through in this game. The cat jumping animation is.. hmm.. it’s ok. Not great. I didn’t have a running sequence, so I just re-used the jumping. Which means the cat’s in the air a lot of the time. Which makes jumping precisely a LOT harder.

The other thing this game had was multiple levels (a first), so, tons of tedious-but-necessary subtle issues with interactions between the different scenes.

*sigh* anyway. Glad to see the back of this one. It’s… mildly interesting. And tricky.


Kow Klicker

Ok, time for the silliest game ever.

Mainly because I found a super cute sprite set for this lil guy:


And seriously. He’s so damn cute, how could you NOT immediately say “That’s it! I’m gonna put him in a game!”

So I did.  Now obviously, this is a ridiculous homage/rip off of this glorious work, by Ian Bogost – who, by the way, is a mad genius for thinking of such an ironically brilliant/awful game.

The world needs more cow clicking, I reckon.

So this games has sound control (find icon, tune, sort out graphics + internal behaviour etc etc) – not a complicated thing, but a general necessity.

There’s all sorts of cute easter eggs with this one too, if you leave it but don’t actually click the cow. In fact, it’s almost more fun NOT to click the cow. Uhh, an anti game?

Needless to say, I have a high score of, uhh, 216. I would have got much higher, but I had to go out.




After yesterday’s debacle – spending waaaayyyy too long on Live Long, I had to do something simple so I could catch up.

Hence, a silly little memory game.

It gave me a chance to re-use those cards from Hi Lo that I spent forever creating (although my photoshop skills are better now, so I tidied them up a little). There’s a bit of a splash screen (although it’s mostly hidden, and nowhere near as slick as the Live Long splash screen).

Wasted about an hour figuring out why I couldn’t create/move actors (the tick marks) when the game was paused. Silly thing.

Basically this is all pretty simple. About as much fun as playing it by hand, but you don’t have to find  a deck of cards.


Live Long

I have a many-decade history in Artificial Intelligence.

Now, in gaming terms, AI tends to be VERY sparse – there just aren’t the cycles to devote to seriously in depth AI. So, what you’re seeing is usually incredibly optimized heuristics – clever rules of thumb that simulate AI without being particularly ground breaking. This is, of course, perfectly fine – it gets the job done after all. Plus, as computers get faster, even this bare bones approach is getting more and more sophisticated.

This game (Conway’s Life) however is the simplest of the simplest.  Basically, each square changes colour depending on what its neighbours are doing. That’s about it, more or less. There’s some simple rules, but they are VERY simple.

So, mostly this will be tricky for me because there’ll be a LOT going on on the screen. It’s too much for Stencyl and Box 2D to handle in the default manner, so I’ll be doing a lot of manual drawing and calculating. It’ll be interesting to see if I can keep the frame rate up (since typically, once you add more than about 20 things on the screen, the whole thing grinds to a halt).

Ok, so I have the design box (top right) you can click (or drag) a pattern. It gives a satisfying alieny sound, then when you move over the main grid it shows a HUD like representation of your current design:


And it runs at a pretty reasonable framerate too (my biggest concern with all this hand drawing – super easy to screw that up with bad code).

Next up is to actually place that mini image onto the grid at the location, when the user clicks. Plus to do the regularly ticked update of the entire grid pattern. Now doing that efficiently will be interesting.

So I’ve got the base algorithm calculating. It’s not super great, speedwise, but it’s ok. Major issue is I have a ferocious memory leak. Garbage collection isn’t freeing the arrays up, I suspect. However, it’s all working quite well other than that. Currently looks like this:


Note the memory – top right. It should be about 30-50M tops. It was going up about 20M a second. Oops. So no, I’m not going to make this live JUST yet. Not until I find+fix that.

Aha! Ok, I have it at a nice steady 5 updates a second, and rock solid at 26M of memory (about normal). Fixed all the memory issues. Performance isn’t super great, but now I can add some neat features to the base system. Awesome.

Right. I have now spent WAY too damn long on this (as a result I’m now running a day behind). It’s quite insane. However! This is frickin’ awesome.

I realised I was spending way too much time creating buttons for each new game, so I built a nice modular way to have generic (and reasonably good looking) buttons trivially. Like, in seconds per button. So that’s cool. I also added a splash screen (first time ever) so that should be easy to do for each game now too. Oh, and there are example patterns you can add with a single click.

Oh man, this whole thing is great fun. I love it!



Along with the pathfinding (which I still haven’t got back to yet), there’s a thing with forced perspective platformers.

I think I can have some fun with this, as a technology, but there’s a few key bits I need to get sorted:

  • Tiles that look correctly perspectivised (that a word? is now!)
  • Lining them up programmatically (so I can generate the play area from code, not pre-built)
  • Accurate movement, without ruining the 3d effect (ie, instead of moving left right, you have to move on angles)
  • Collision detection. This is slightly tricky, because if a char is standing ON a tile, it’ll actually be overlapping it, but in a specific way.

So, some interesting math to get “just so” in order for it all to work. Gonna be a push to get it together in a single day, but so far so good.

My plan is (for this game) to just have a super small play area – only a handful of tiles. But moving, with jumping between them.

Oh, and of course, I then also have the long winded process of getting a decent looking character, static, moving and jumping in all four directions. Tedious.

So I figured out a cool way to a) store information about grid layouts and b) test them super fast. Basically, spin up a local web server, do a call to get the config (have to do it this way since Flash can’t easily access the local filesystem). That way I can test and retest new levels without having to restart the app – a major time saving. However, given that I only have a day, I have to put that to one side, and just work with something crude and simple – for now.

Right, basic tile movement is in. Now to get a jumping character. If I’m smart about this, I’ll swing the whole thing around to the right (ie, typical left-to-right movement), so then I can use any of the old school platformer right facing characters – they have heaps of available jumping animations. That should save me a bunch of time.

Eg, a typical character: facing L, R, U, D standing = 4 frames. Walking in each direction = another 4 * 2 or 3 frames (ie, from 8-12 frames in total). Now, there are some dupes there, but still, you’ve gotta wangle them all. Make a mistake on one frame and you may have to rebuild 3 full animation sequences. Add jumping in there (four directions, 3 frames per) and you’ve got another 12 frames. If you spend ten minutes per frame (quick, but possible), we’re talking 10 * (4 + 4*3 + 4*3) = 280 minutes = 4 and a half hours. For one character. In one outfit.

Now obviously, as you get better, you can speed this up – but not much. You’ve still got all the little details – and I’m only talking about key frames here. Even if you were tweening (getting the computer to draw the in between frames) you’d still need those key points – start and end of each movement. If there’s a faster way out there to get characters drawn, I’d LOVE to know about it, but right now, I’m stuck with the super slow way.

Ugh. Ok, so diagonal movement is fraught with subtle complications. Stopping the guy falling off. Moving from tile to tile (without getting stuck on a corner). Jumping – which direction? Identifying when we’re on a tile or not, etc etc. None of it is particularly complex, but there’s a LOT to consider. It’s not going to get done today – not if I have any chance of getting today’s actual game done. Lame.


Boring Tennis

Just a boring tennis game.

Hopefully, starting from a straight forward concept, I can add a bit of sparkle, a little pizazz, enough to make this not totally suck. We’ll see.

A lot of previously seen concepts (paddles from Bounce Ball Bounce, reflection from Crazy Pong, AI tracking similar to Crazy Pong), but put together with slightly larger smarts. It’s not just about aiming it back anywhere at this end, but enough to make it bounce in the right place (and not out of bounds), plus there’s that nutty tennis scoring.

Ok, have an interesting bounce on the racquets. At this point the enemy AI does exactly nothing. Would be nice to have a gently parallax background – but I don’t think that’s possible with this framework – or maybe just with my current level of knowledge with Haxe.

Man, trig is tricky. Have been trying to get a more interesting game – allow more control over bounce. I spent ages trying to get the horizontal velocity in as a factor (ie, so you could move the paddle left or right to hit it farther or nearer) but wow, no matter HOW I shoved that, I couldn’t get it to work.

Turns out a better approach was to simply use the relative x position on the paddle, and vary not only the x velocity but also the y (up/down).

Right. Tricky things with tennis: defining who gets the points when the ball a) hits the net b) hits the ground c) goes out of bounds, d) goes straight up and back down on the same racquet – relatively straight forward. A lot of rules, but simple enough. Complicated thing? Displaying the bloody score!

It’s done enough for now. It’ll play a game, but no match or set scoring. You always serve. It’s.. a little uninspiring, but kinda soothing in a way. I like the gentle back and forth tennis sounds.


Make A Maze

I’ve always loved mazes.

I’d also like to build something a little more sophisticated (eg, an RTS). However, anything with that many pieces in play will require some kind of pathfinding. Ie, a pretty major project in itself.

So, in order to get the pieces together such that I CAN start to build this kind of thing inside a day, I thought I’d start with this. The idea is – you build a maze, and my little dude then tries to find his way out. At the moment, it’s a case of letting the user define the play area (an interesting challenge by itself). Thus: click the pieces on the right to define what kind of wall you wish to build, then, click or drag to put it down, creating a maze. Click any positioned wall again to take it away. Pretty simple.

Ok, have a little wizard character in there. There’s some horrible edging around the character – part of the issue with shrinking a slightly larger character down to size. Less important than the pathfinding, so I’ll get to it later.

Right, the wizard was getting a little stuck on the edges of the maze, so I redefined the collision shapes (making them slightly angular stops them getting hooked on the corners). It’s now looking pretty snazzy. You can zoom around with the arrows, and define the maze.

Next up, allow the user to reset the maze, and to hit go, automatically sending the wizard hunting for the finish line.

Reset and Go now work. There’s no path finding (ie, anything in the way will stop the wizard), but it IS moving – in a direct line. Which means a guaranteed score of 27 every time.

Hmm. Interesting. Turns out there’s a bug in the Stencyl Tile API (if you add a tile, then remove it, it leaves the collision box behind). Which means if you change your maze, you have invisible walls. Helpful. I had a look at the source, but it’s too much of a mess for me to easily grok and fix in a few hours.

On top of that, the Haxe pathfinding library I downloaded – which after a bit of fiddling about I managed to get to compile – doesn’t take into account walls. The code is SORT of there (you can add a cost for each node in the grid), but it’s ignored.

Also not helpful. So I’ll have a look at some of the other libraries I’ve downloaded. There’ll be a better one there. This is a bit tedious, but critical. Pathfinding is an absolute core of any decent NPC AI.

Ok, so after a few hours of battling this third party library I was working with, I thought I’d just hack something together to get something out (given that I haven’t even started today’s game yet, and it’s almost 6pm). So, the classic “if you hit a wall turn right” maze solving algorithm. Crude, but it works.

Annnnnd welcome to the world of path finding. Some issues:

  • The wizard randomly gets stuck on blocks (apparently turning right is difficult)
  • The wizard sometimes gets locked on start. Nothing to fix this but restart (not even reset) the game.
  • The scoring is now on high speed
  • Despite turning off ALL collisions, he gets stuck on the edge of walls
  • Despite identifying where the walls are and writing code to avoid them, he still runs into walls
  • The end game identification isn’t done, so he just runs into the wall at the end
  • I can’t get the guy to turn right. He does, then flicks back again. Or something. Very weird

So, you can see there’s suddenly a huge bunch of new bugs. All of which need to be tracked down and fixed in order for this to be vaguely useful. And this was as a “nice quick” alternative to the actual pathfinding. The annoying thing here is – things like crappy collision detection – that’ll come back and bite me even when I get this path finding library in and working perfectly. Back to fighting the environment again – game dev 101.


Ball Thing

God. What a day.

Started out thinking I’d do some kind of “growing a tree” thing. Did a huge bunch of trigonometry, but couldn’t get it to quite hang together in any kind of way I was going to get finished in a day.

With time running out, I thought I’d do some kind of Snake variant (since that was such an awesome game). That fell apart for a whole bunch of reasons (mainly technical limitations – the engine I’m using, Box 2d, isn’t well suited to a strictly tile-sized object model. It’s too fine grained). It’s doable, obviously, but would have been an ugly kludge. I couldn’t think of a way out of it.

I ended up mucking around with three or four different ideas with balls. Dunno what it is, bouncing balls are fun. Either way, I started the day without any clear idea, and ended it in a very different place but just as murky. Crap.

Well, tomorrow’s a new day. Gotta expect a few days like this.



Not sure what this one is all about. At the moment, it just lets you play tones. Maybe that’ll be enough. I’m trying to get them to play automatically, but having trouble getting the two core game objects to register collisions. Not sure what’s up with that – different layers? Confused groups? Still debugging.

Ok, so I have a pretty reliable base on this now. Click a box and it’ll keep playing that box. Click it again to stop it. So that’s cool.

It looks ok, which is good – but there’s not really any point to it. Nothing to learn. No pressure. Minimal fun.

Ok, so now I’m adding different instruments. It’s making it quite a bit more interesting. Still odd though. Not really a “game” per se, but, based on my intent to put game play first, just trying to find something “fun” in here. There’s something here that just isn’t quite clicking together, game wise.

Interesting, but not earth shattering, in any significant way.


Space Inverders

This is one I’ve had on my mind for a while. So, today’s the day.

Basically a huge rip off of the (incredibly awesome) original Space Invaders, except – you control the invaders. Hence, inverted space invaders. Golly yes, I’m so clever.

Anyway, right now I’m busy working on the artwork, so there’s not much to look at yet, but I’ve got it pretty clearly mapped out in my head (unlike, say, yesterday). Should come together pretty cleanly – although there’s a ton of slick little touches I’d like to add.

Wow, so I really fucked that. I thought, for speed, if I just used the existing artwork, that’d be more efficient. So, after getting all the key pieces drawn, looking great, in a variety of colours etc, I realised they were too big. I couldn’t scale them down without losing detail and blurring the strong contrast. So, there was 7 hours gone. Youch.

I think I need to VERY strongly focus: ugly-as-fuck-gameplay first, then polishing afterwards. Not the other way around. The problem (motivationally) is that a better looking game motivates me more to work on it. Still, in terms of hammering these things out quickly, I’m gonna need to flip my attention 100% around, otherwise I’m going to have more screwups like this.

So, as much as I liked the idea, I’m having to walk away from this one. At the moment, it’s L/R/space to fire. You’re the defender. It’s super lame. So, really nice graphics – but that was the entire day gone on those. Of course, if I had to do them again, I could whip them out super fast – so that’s a good learning opportunity, but a shitty game. I think I’d like to come back to this one though.

Critical lesson for today: gameplay first, polish second.


The mission: Create a Game. Every day.