Making good bosses is hard - the idea behind them has got to be varied and fun while still presenting a challenge, and there's a lot of programming for a small section of the game. Ideally, I think they should seem overwhelming at first but then become easy as you watch their movements, learn the openings and start to fight back effectively.

For people who allow their progress to be updated to the Crystal Towers 2 site, I keep track of how many times bosses have won agains the player and how many players have defeated them. "Score" is [times won]/[times lost] - I think that 2 is a pretty reasonable score to expect, as it implies that players lost to the boss twice before beating them on the third attempt, a decent balance between presenting a difficult enemy and keeping the game going.

It looks like Beam Stack is still the hardest boss, although not by as ludicrous a margin as before - in the first version of the game its score was up at 12 or so. All it took was a little change - making its laser turrets to flash before firing made it much fairer and I think it's one of my favourites. The next hardest one is Xenon Squad, which is fought in a different way from everybody else - its high score might be because players are spending lives working out what they're meant to be doing, though I tried to hint better at this in the new edition.

At the other end of the scale, The Cleaner is exactly where it's supposed to be - it's an introductory boss and even though I actually ramped up its difficulty this time around, it's sitting comfortably near 0.5 (you'll probably win against it first time, but if you don't, you'll get it next time). The absolute lowest is Lava Tank, which is easily my least favourite of the bunch - I think it was the first non-platform-style boss I made for the game and it just wasn't challenging enough despite my attempts to make it more acceptable for the new edition.

There are a couple of surprises as well - Megacarrot, despite being the last boss of the game, is sitting slightly below The Cleaner in terms of difficulty, although it could be because only the really dedicated and powered-up players get to him. I made an effort to drastically rework Sci-Fly compared to the first edition because it was too easy as well - it's only got to a measly 0.83, but I think this is actually much higher than before.

And Cubombscus is at a very respectable 1.81 now despite being one of the easiest before. In the first edition it had a bug that meant that it always remained on its easiest setting no matter how far you got its health bar down, a mistake corrected the second time around!

Someone just emailed me asking where they could download Treasure Tower, making me realize it had dropped off my site when I did the reorganization - so here's a new download for it!

If you use Chrome, you might get a "Not commonly downloaded" warning, because it's stupid - it's OK to click the arrow and "Keep" to verify you want to keep it.



Released in 2005 before independent games started to become a big thing, this was probably my most popular game in the fledgling community even though it's looking pretty simple nowadays. Climb the towers against the clock, collecting treasure and food to stay alive. You can also attempt to submit to an online leaderboard, which no longer works.

The screenshot is from a Flash version that I put together a few years later.

There's a post about its inception here, though the images are long gone.

I'm pretty sure that there's a game in here somewhere. I haven't quite found out what it is yet.

Here's a quick note about the only IDE I can actually get excited about - it's hard to believe it's been seven years since release day.



I know everyone's probably sick of Humble Bundles by now, but I have a bit of a special interest in this one! Multimedia Fusion 2 was used to make Crystal Towers 2 and some good games as well, and for the next couple of days you can get it for as low as $1 (if you’re a real cheapskate). And six to nine games that were made with it, and a heap of soundtracks as well. If anyone’s interested in game-making, it's a fantastic introduction and I can't recommend it enough. (And it also gives you a voucher to upgrade up to the new Fusion 2.5 for less, if you decide to later).

MMF2 Humble Bundle sale

Here's another GIF showing the new abilities that I put in this evening! None of which were the things that I intended to work on this evening, but still... (You might want to give it a minute, as it's 8MB - the image above is just a preview.)

I'm already beginning to see this as "Crystal Towers 2 done right" - I'm still proud of that game (after all, this one is directly based on it), but it had a lot of awkwardness in the system which came from not having any experience writing a game of that size. This time, I'm getting the opportunity to correct a lot of the mistakes - for example, the "boost"-style ability is now activated with a quick double-tap while in the air, rather than having to be selected and assigned to a spell key, and the general platforming experience is a lot more fluid as a result.

This isn't bad for an evening's work!



Rooms are currently based on five layers:

Backdrop - Large tiles on the far wall of the scene like the wood walls here
Background - Actual platforms and walls that make up a level
Decoration - Items like the desk, bed, tables that the player can't interact with but give flavour to the surroundings
Objects - Interactive objects - things you can pick up, look at, use and so on. There are none in this scene just now, because I still have to work out how I'm going to do them! Placing them is easy enough, but loading and saving their attributes (whether they've been picked up already, what state they're in...) is going to be a more difficult challenge.
Foreground - The same as the decoration layer, but these will appear in front of the player and objects.

I also love how the outdoor tiles in the second half of that screenshot turned out when put together... somehow, I've managed to produce something that doesn't look dreadful.

I nearly called this entry "Technical coonsiderations" before realizing that that would put my life just too far over the edge.

The last three evenings spent on Hatogate were a great opportunity to start up MMF again and do a quick project, after not touching it for the last while (hopefully it'll lead into me completing the Xbox versions of Special Agent and Running Free). And it was an interesting exercise in doing something I haven't done with it before - I've experimented in writing adventure games, but this one felt like it really needed a scripting language running behind the game to make it easy to program reactions to commands. So naturally, I modelled it after the only language remotely mad enough to contain anything Hatoful-related.

I wrote it in ZZT-OOP.

That is, I based the syntax heavily on the scripting language that ZZT uses, as it gave me something to aim towards (writing a language from scratch at the same time as writing something in that language is like trying to handwrite two different sentences with each hand simultaneously) - and being familiar with it made it readable to me at the same time as being easily parseable, based on commands denoted by # and then another couple of tokens per line. The language is heavily based on a GOTO philosophy with programs jumping about between labels all over the place, but for small scripts it does its job very well - and this game is greatly simplified by the way that there's only one location you can be doing anything in, and one object that you can interact with on the screen ever, so it would never get too tangled.

So I borrowed most of the vocabulary - when the player builds a command with a verb and object (or two objects for USE), the game looks in the script for a label matching that command, then starts there and runs through the program. If it doesn't find one, it tries again with the object name replaced with ANYTHING, as a fall-through backup for places where you just need the same response for a variety of things (like using anything on the paintbrush).

Labels are labelled with :, comments with ', commands with # (and # followed by an unrecognized command is assumed to be a jump to the label of the same name) and everything else is assumed to be text to display onscreen. Like most good ZZT scripts, things tend to start with #END, which in this case stops running a script and hands control back to the player. #GIVE and #TAKE form a pair of commands to add or remove an item from your inventory - #TAKE has an unfortunately counter-intuitive name because it sounds like you're taking and therefore gaining an item, but I chose to live with this rather than think up a synonym. Similarly, #SET and #CLEAR are used to turn flags on and off - these are named on/off switches that just act like inventory items that you can't see or interact with. Unlike in ZZT, of course, there is no hidden flag limit, flag name length limit, or risk of detonating the flag pile by innocently setting a flag twice.

Syntax for #IF was a little more involved, mostly due to my own choice - I could have lived with just one variant, but to make scripting slightly easier, I came up with four different varieties of it. #IF followed by two tokens will check the flag list for token 1 and go to the label matching token 2 if it's found. #IF with only one token after it will check the flag list as above, but will then run the next line if it's found, and skip over it if not. This is useful for situations where you just want to display one alternative line of text depending on whether the player's done something before (I could have implemented #ZAP... but consciously chose not to). For situations where you want to check a flag isn't on, I threw in an #IFNOT command rather than force myself to think backwards. Supporting just one command or line on an #IF is still rather limiting, but it works here - and led to things like #IFNOT PUDDINGTHROWN SKIPLIZARDPUDDING, which is among the most surreal lines of code I've ever written.

Of course, I also had to make up a couple of commands specific to this type of game - #SHOW changes the screen shown, and #SPRITE followed by a name and show/hide toggles the sprites overlaid on the location on and off. #ACHIEVE turns on an achievement and #ENDING stops the game. The classic #DIE is present, but only as a label that shows the death screen and calls #ENDGAME, which displays the death text and sets the game up to restart on the next click.

It turns out that it's quite easy to create a bad language by just making it up as you go along, and I found myself putting things in to work around my own parser quite often - :END was set up as a label as well as a command for convenience at first, because the original three-token #IF lines could only go to labels and not call commands directly - and even now, you can't jump directly to a label with multiple words and have to duplicate them (:PECKMILLET). There are also a couple of special cases handled by the game and not in the code - the counter for turns before Okosan appears and the death achievement are two of them - but overall it turned into quite a neat little experiment, and I'd be interested to try making another adventure up in the same language to see if it holds together.

In doing the interface, I also noticed something very interesting about Shadowgate - the screen is arranged so that all the buttons are on an 8x8 pixel grid. Presumably for ease of laying them out?

Running Free is my latest candidate to put through Clickteam's XNA runtime! I've settled on this as a first target to complete due to its small size - the entire game is basically made up of just a level selector and gameplay frame that handles everything, so changes only have to be made to a very small area.


I was once again impressed by how quickly I could just change the application's build type to XNA for Windows and hit the Export button, going through the level select menu and everything without any problems whatsoever... though the physics of the game were completely broken when I first started it up. After some investigation, I found that this was due to an isolated but fairly severe mathematical error in the expression-evaluating code where the Min() and Max() functions wouldn't return the right values under certain circumstances. (Max(-30, -1.0), for example, is 0 - where were the beta testers!) But having fixed that myself for the time being, and then having fixed a further error caused by me getting the implementation for Min() wrong in a different way when I patched over it, the game ran exactly as it did in the EXE version, and was ready for reworking for the Xbox.

One of the most dramatic changes that had to be made was in orientation - Running Free was originally laid out to be viewed on the iPhone vertically, while widescreen televisions are decidedly horizontal. Because programmers are lazy by nature and tend to choose the path that involves the least work now and in the future, I wanted to go with an approach that would let me keep the original level layout file, and just change how I was interpreting it so that the levels were drawn in a different way.

True to the laziness theme, I never actually wrote a level editor for this game - the level layout is done on a grid in an Excel spreadsheet, and there's a small Java program that reads it and produces a long string that looks something like:

Level=?                                                       322221          6  * 4          6    4          6    4          6    4    322222X    4    6    E!    4    6          4    6*        *4    6          4    6          4    6     @    4    988888888887                                                                                                 ?

...along with a couple of other fields that store the level name, par flips/time, and so on. The game then chews through each character in order and places the corresponding tile at the next horizontal position, starting a new row when it reaches the designated LEVEL_WIDTH.

To lay out the level horizontally, the game needed to jump about a bit in the string instead of reading it from start to finish - more specifically, it needs to act as if it's read down the first column (every X tiles, where X is the length of a row) and output it as if it were a row, then start on the next one, like this:


And a quick check in Excel gives us the formula MOD(X;5)*3+(FLOOR(X/5;1)) to do this on the 3x5 set of tiles that I mocked up there. Translating this in to MMF is easy enough - you set the "next tile" to point to that instead of just increasing it by 1 each time.


Hmm. Well, it would have worked if I had remembered to replace the numbers "5" and "3" in my test formula with the actual width and height of the levels...


Which produces this. And this frilly specimen isn't as far off the mark as it might first appear - those little border tiles are represented by numbers in the level string, the number indicating which side of the square to place the border (laid out like a backwards numeric keypad - 3 draws a square on the bottom right, 7 on the top left, 6 with two squares on the right hand side...) To complete the new layout, those sides also needed to be translated.




As you can see, this technique doesn't technically rotate the level - it actually mirrors it diagonally. Therefore, I also had to adjust what "initial gravity direction" meant, as well as reversing the flag for telling the game that the player should start running clockwise. (This is fortunate because the first time I wrote the engine, I somehow got the names for "clockwise" and "anticlockwise" consistently wrong all the way through, so you could say that they're now finally correct).

And now the re-orientated game runs fine. Work on the interface will come next - it's strange to make the game feel more awkward after the immediacy of touch control, but now everything has to be done without the benefit of a mouse!

An old project might be coming back again (and doesn't it feel strange describing it like that) - I've submitted Crystal Towers 2 to Greenlight on Steam!


If you've got an account, I'd really appreciate a vote up and a few words, followed by optionally spamming it to all your friends everywhere. The more votes I get on this thing, the better a chance I have of it eventually seeing a release there. I would also welcome any copy-editing of the description I currently have there, because I am terrible at advertising my own games, possessing as I do the natural enthusiasm of a bag of pencil-shavings.

Even besides that, plans are also in place to have it featured as part of an independent bundle - so it may get a revitalization either way.

(Incidentally, lupineangel... yes, am I legally okay just considering your picture the official cover artwork for the game, by now?)

Here - roll a sheep around!



Sheep Roll - from an original modernist poetic composition by ravenworks. Tumble the fat sheep around and eat the flowers by planting him face down on them. As usual, I'm not really sure what the greater point of this game is yet, but perhaps one will come to me.

I can say that I thought that sketching this out would be easy - but once I'd got going, the finer points of sheep-rolling mathematics proved to be a major obstacle! I first had to work out how many different frames of animation I needed, and then spent the evening writing up all the permutations of angles, frames and directions that were needed to allow full movement (I was hoping that a pattern would emerge, but none did).

If anyone else wants to do a game involving a dice-like movement like this, perhaps my lookup list would be useful (if I hadn't chosen such a rubbish format for it):

( Lookup list )