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!

Crystal Towers 2 has a Steam page and everything now! All the checks by Valve are out the way and I have the freedom to declare it ready whenever I like - it won't be long until it's set live and purchasable.

Here's the trailer on Youtube, at a better resolution than the Steam one.

In the process of making the new edition, I've come across and fixed several amazing bugs that apparently went unnoticed the first time around, including:

- In the introduction, I forgot to turn off the keys that let you look up and down - so you could cause earthquakes by holding either arrow key and getting the scrolling to start moving then rapidly twitch back to where it was supposed to be.
- In the non-Desura releases of the game, the Cubombscus boss had a very obvious red and yellow detector object left on-screen which should have been made invisible. People seemed to just assume it was meant to be a flag, which says something about my drawing skills.
- Magma Lizard was unfortunate as well, as the background on the surface of his level was a terrible-looking mountain-shaped placeholder that I forgot to replace before releasing the game.
- Midway through the game you get an upgrade to your navigation in the Music Castle, with little text labels showing the nearest levels to you. These didn't appear if you had just come out of a level towards the right of the hub, because the objects were located at (0,0) for a split-second before being moved, which was deemed too far away and they were automatically deleted.
- The "mosquito" type creatures throughout the game are drawn as dragonflies. This is I forgot the sodding difference between dragonflies and mosquitoes.
- The Lava Tank boss was terrible. This isn't really a bug. It just was.

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

For a few weeks now, I've been saying that I'll put something playable of Todo up, but I just never got it into a position where it felt remotely presentable, even with the caveat that this was not complete work. However, tonight I think I've got it to a pretty good place to call a first prototype - most of the interface works and you can complete a task, so you can see the rough mechanics of the game. Have a go at this!


http://www.clickteam.info/davidn/games/todo/zip/todoprototype1.zip
Your mission, should you choose to accept it, is to acquire a "PipeBit" (which you can't use yet) and collect all 71 available Quest Points. Use the arrow keys with X to jump, and Up to interact with things - Q brings up the menu. You'll find that the game has some holes of varying degrees of hilarity and you have a couple of abilities which you won't really have from the start of the game, but feel free to poke around and do the unexpected - you may be surprised at what I've thought of (or more likely what I haven't).

It may seem slightly disappointing that I've been working on this for a few weeks to achieve roughly three minutes of gameplay, but so much of that time has gone into the backend - taking the base Crystal Towers 2 engine (which you'll see evidence of) and doing it... right. I've grown to love the Hatogate scripting engine as it grows more and more into what the game needs it to do - the game is pretty easy to expand now, and the game so far serves as a decent showcase of what it can do in terms of interacting with objects and characters. The scripts and rooms are all plain text in the "rooms" folder, so you can open them up and fiddle around with them if you like. Best of luck with that.

I haven't been as pleased with my game creation in a long time!

• Drew quite a lot of this stuff:
  


• Wrote procedures to save a compressed level format - instead of saving every value, it does what CDs do and saves them as strings of identical tiles - this can cause massive savings on blank spaces, which are recorded not as 208,992 zeroes but as "[repeat tile 0 208,992 times]"


• Realized that this method of loading was much slower - about four of five seconds a room, which wasn't crippling but was annoying


• Worked on improving the loading procedure as well, so that it completely skipped over stretches of blank tiles, calculating where it should land in the level array rather than stepping through (240000*SaveZ( "SaveVars" )+600*SaveY( "SaveVars" )+SaveX( "SaveVars" ) + Gap, then translated back into coordinates)


• Thanks to that, got even quite large rooms to load instantly!


• Realized that one day's work of patching up all of the above later, I'm now exactly where I started the day, except with level files that take up 2-4KB instead of 2MB. This could have been quite important in 1997

Still, I like the cave texture.

In the interest of keeping this going, here's a screenshot of a test room I've been building - click to expand it!



I had a fever dream about this a couple of days ago and had to write everything down before I forgot it all - the monk-mouse's name is now Todo the Tea-Mouse, and the adventure is based around completing his list of things he has to get done today. He comes from a village of mice who are experts on the growing and preparation of exotic tea, but he dreams bigger and has moved out of the village to take advantage of the lower property prices - though his family is doubtful of his chances, he has the aim of one day opening a 100% organic vegetarian cafe.

I've noted down a fair amount of subsystem stuff like how I'm going to handle storing room layouts and saving the game state - the platforming is a modified Crystal Towers 2 engine ("modified" in the sense of cutting out the utterly rancid parts) and the interaction and scripting is actually the engine from Hatogate. I've got a couple of objects and events set up now, but I keep on getting inspired to go off and do utterly pointless things like drawing the other character at the top left (who some people may recognize) instead of actually writing the vital stuff to support the continued expansion of the game.

I'll be writing a proper editor some time this week, though. It's odd making a to-do list for a game about a to-do list.

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 )