I seem to be at one of those stages where I keep on meaning to write things in here but other things (like work!) have got in the way. What I did in most of my spare time last week was polishing the Crystal Towers 2 demo for Clickteam's disc next month - after releasing the first test of the demo to testers, I've made some slight changes such as ripping out and replacing the entire sound and online communication objects and changing the way that the whole save system works.

Briefly, then - the sound change was from ModFusion to Onu, something that I'd tried before but abandoned when I found that Onu couldn't play music over separate frames. But it had been updated a lot since then, and with ModFusion's reputation for crashing a lot on computers that weren't mine, it was worth a try replacing it. That process went fairly quickly and gave me the chance to neaten up how music is loaded as well, with all the incidental music put on to separate tracks when the game is started up, rather than loaded on demand - now only the level music has to be loaded when one is entered. Curiously I found that like ModFusion, Onu can't change MOD orders correctly, but it just ignores the action and does nothing rather than crashing, which is a vast improvement as you can imagine. There was a brief panic when I realized that it wasn't looping music correctly, but it turned out that you just needed to turn MOD looping on specifically when you start playing one.

The online object is now the Get object instead of the Live Receiver - it's a sign that I've been taking too long that the earlier object has gone through its entire birth and death during the course of the development of the game, and I'd previously used it to replace the Moosock object that I used in Special Agent. I hadn't noticed any instability with the Live Receiver, but the author said that the Get object was a lot less prone to crashes, and it brings the file size down an insignificant amount, as well.

I've also succumbed to the will of Microsoft and changed the save system so that all of the game data that needs to be changed is now stored in the Application Data folder. It's ironic - for many years we tried to beat the idea into independent game makers that you should never touch the Windows directories and everything should be provided as a self-contained folder for ease of installation and deletion, but now we're all having to do the opposite and treat the user's Application Data folder as a sort of giant memory card. This has to be done because under certain circumstances, Vista and above won't let applications write to folders in Program Files, so players might be stuffed if they usually put games in there - this is the reason why you see some games putting a "My Games" folder into your My Documents, too.

Looking at it now, I can't imagine why I thought this diagram would be helpful

While doing up the site for the game, I ran into some issues caused by how I'd set up the online accounts in the game at first. The idea of the online feature is that you can submit your save to the site through the game, and have your progress displayed among other players. To do this, when you create your player you provide an online key that's meant to keep your account unique, and when you update, the game sends the information off to a script on the site and creates or updates the account (sending back a message saying whether it succeeded or not). There's even a dynamically generated image near the bottom of the page that you can display on a forum signature and so on.

Because I was just about feeling my way as I went, there were a number of problems with the way I did all this at first - one of the biggest was that accounts were identified by name. I did this deliberately at first because I didn't want two players to have the same name, but it made things more inconvenient than anything else, needing a whole extra process to check for existing names and then informing the player that someone was already called that, then providing a chance to change it. The other was the separation between creating and updating an account - if somehow something went wrong (like me fiddling with the database, which I frequently did during testing) then trying to update a player record that didn't exist would produce a cryptic error. Once you'd taken a name, you were stuck with it, too - you couldn't delete your save and start again with the same name, because that name would already be taken.

Shows about as much as you would expect.

I changed this to work in much the same way that I remember Unreal Tournament handling it. You can use any name you want, but the combination of the name and the online key has to be unique. As long as nobody chooses a painfully obvious online key and also has a really common name, this prevents collisions (and if two accounts do collide, then they just save over each other, with no need for an error message). It does leave a few menus I did up completely unused, but it works a lot more smoothly than the old idea. Because there can now be two players with the same name, the update script (which now creates an account if it isn't there already, rather than just throwing up an error) now passes back an ID to the game, so that it can use it to directly open the player's scorecard from the game itself.

What also happens now, when an account is updated, is that the differences between that account and the last time it was updated are also recorded in a separate "events" table - a new row is added for every update. Having a record of the differences recorded recently in these little 64-byte rows means that the site can parse those lists of numbers into something resembling English (which is more difficult than you'd might think) and display a news feed of what players have been doing recently in the game. It really is quite fantastic staying on the page and watching updates go past when people are playing it.

I think all the best online features are written because of people's love for spying on others.

Unlikely as it might seem for me to be saying this, I'm now at the stage where I'm putting the finishing touches on to a demo version of Crystal Towers 2, after being spurred on by a suggestion that it should go on to Clickteam's monthly disc. Previously I've been able to release things to testers with provisions that "this doesn't work right yet" or that things will be finished later, but I don't have those excuses now, so I've spent the last couple of weeks polishing up things so that they're presentable. And the results are looking pretty encouraging so far.

The only thing that's getting to me now is the storyline section - there's a visual joke that I quite like and want people to see, but it's really a direct choice between taking the time to do an entire intro or just putting a quick slide in to explain the story for the demo, and I'm not sure I have the drive (or graphical ability) at the moment to do the whole thing up. We'll have to see about that.

Otherwise, I'm at the stage where I'm comfortable putting little finishing touches in. This is something I like that I wasn't sure I would be able to do, but it turned out to only need a couple of hours' work thanks to PHP's versatility - signature images for player accounts. So you can put an img tag on to a page and link to your account's URL, and have it update as you play through the game - it's all very dynamic and Web 2.0 and... all that. With any luck, you should be able to see it happening here as I test it now.

Boss monsters are usually a bit of a headache to write. You have to think up a cocktail of attacks, weak points and strategies that are balanced to be difficult to cope with at first but possible to learn through experience, and then write the whole thing's behaviour, which can often get quite complex. As evidence that I'm still working on the game, this is the seventh of the bosses I've made, and at the moment it's called Beam Stack.



The general approach that I'm using for bosses in this game is treating them as loose sort of state machines, with one string called State which is the main thing that decides how the boss should behave at any time, along with a heap of other variables on the object that describe more of the details of those behaviours. By making at least one of the possible actions in each state being to change the contents of State to something else (and having what it changes to possibly dependent on other conditions), the boss can move between behaviours in sequence.

( A more in-depth explanation of how it all works, for the benefit of those interested, coders, ZZTers, and the insane )

And all of that goes together to form the thing that you see in the video. After I first set it up it took me ages to get past it the first time, but now I can do it fairly reliably - if other people find the same thing, then that's just the right difficulty of boss I'm aiming for.

I don't really know why I bother announcing that the game infrastructure is ready in these posts any more, because it never seems to make much difference in terms of how fast I ever progress with the actual building of the game. But this weekend's been different - Whitney's been away at a conference and I resolved to ignore all the minute details I keep worrying about and bang out some actual new content instead.

While their actual mechanics may need some work yet, the game now has four levels that it didn't have at the beginning of the week. Here's the proof in the form of some maps, under a cut - unless you're reading this through Facebook. Then I've honestly no idea what it'll do.

( Proof )

This brings the level count to 22 (or, counting each objective as a level... 154). I never thought I'd say this, but as a result the hub level is actually looking pretty crowded - I'll probably have to pull that to pieces and redesign the whole lot of it somewhere down the road.

Not to make an extravagant claim or anything, but I think I might have just solved all the game's speed problems in one go. (Not that anyone else was reporting any, that is. It seems that only I have a computer too poor to run my own game.)



I had a look at that after noticing that a level that I'd sat on without quite completing for ages slowed down drastically after I scattered collectible gems throughout. Disabling their collisions when they're not near the game window doesn't have an impact on gameplay because you're always on the screen when you hit one, but it's made performance leap from a snail's pace on some of the more complex levels back to completely normal and fast again. It's just slightly annoying that I discovered this only after a whole lot of other performance-related effort.

Work on the game has sped up again after I released a half-finished version to some testers selected for their interest, game design knowledge or lack of more important things to do, and I'm once again feeling that it's actually going to be quite good - they've been keeping me busy with suggestions for improvements in all areas. I'm quite pleased, also, that the game seems to be taking about as long to play as it did to create.

( Anyway, have some screenshots )

I know that my project supervisor in the last year of university told me never to say this and everything, but things are really going quite well now. After where I was heading was very vague for a while and feeling my way while writing most of the game, my increasingly bulky notes.xls file now contains a solid tree of enterable levels and obtainable abilities that eventually lead the player to getting to eight bosses that will together allow you to finish the game. I'm filling out the actual content in the form of the levels now, and once a skeletal path is walkable with those, then it's finally, finally a matter of polishing up the existing content of the game, then adding as much extra content in as I can stand before releasing it at some point before I retire.

Right back at the start of the project the decision was made to make interaction with external files a large part of how it worked, rather than just having a monolithic and difficult-to-change MMF game file - this was something that I'd experimented with all the way back when I made Treasure Tower, but not on anywhere near this scale. As the hub-based platform game I was making began to mutate and accidentally turn into more of an RPG by the week, it got to the point where even my external rules files were too unwieldy and incoherent to keep track of, and an effort to try to lay the whole thing out in a spreadsheet led to the whole thing becoming a large collaborative effort between Java and MMF - the Java portions of the project are there to process and keep track of the information in the game rules spreadsheet, telling me about the game's balance as well as actually writing the rules files for the game to use. The process isn't entirely outsourced to Java because the game's physical layout still has to match up to what the spreadsheets says should be there - an extra synthesis recipe, for example, has to exist in the level for the taking and be obtainable by the abilities that the spreadsheet says it is for the whole thing to work, because it doesn't have a concept of the layout of levels. That connection has become my main role in making the game now, with the statistics and data being handled by three Java programs.

The Rules Writer

Oddly this wasn't the first bit of Java that I put together for the game, because it certainly makes the most sense. For a while the spreadsheet existed just as a convenience of layout for me, and the game didn't reference it at all - but what began as a convenience of layout quickly became an inconvenience of keeping anything up to date or resembling anything to do with the game at all. That changed when I realized the stupidity of having to copy every change I made in the game to the spreadsheet that described the plans that I'd made, which led to the idea of instead making the game rely on the spreadsheet itself. Of course, making the game rely on data direct from an Excel spreadsheet would make it too easily editable (and parsing through it every time would be prohibitively slow), so this Java portion takes the spreadsheet and interprets it into a set of separate "rules files" for the game to reference - which can then be encrypted for the final release.

The Rules Writer is actually composed of several different parts, each of which loop through pages of the spreadsheet and gather data from them, referencing other objects as they're needed - one class writes out the matching of synth ID numbers to shortened item names to full item names, and later on another one would use some of this data when writing out the possible items that can be dropped by monsters or picked up on certain levels. In this way the spreadsheet is acting as more of a database, with the references between the tables only picked up on by this program when it tries to interpret them. My error checking routine could be better - in fact when it encounters something that's missing it'll just give out a couple of co-ordinates of the cell that went wrong and leave me to work out why myself, but it's adequate for what it does.

The Player

What the Java section of the project was originally written for was simulating a player going through the game, to explore what was possible and what wasn't at each point - when you have even just a few levels open and multiple different things to do in them, each of which rewards you with a different item, it's difficult to keep track of the routes that a player might take to progress, or make sure that there aren't too many or too few avenues to explore at any time. I realized this a while ago and created the Player, which reads in all the available data from the spreadsheet and uses it to construct a State, a representation of the state of the game when the player is in the hub level that keeps track of the player's inventory as well as how many objectives have been completed on each level. By using the same criteria as the game itself for whether a player can enter a level or not, it's possible for it to run through the game automatically and point out if something that's meant to happen is impossible or whether there's a way of getting somewhere that I hadn't expected too early.

This was all automatic until recently - the computer would build up a list of possible moves it could make and then pick one at random. But recently, I reworked it to present its list of possible moves and ask which one to do, turning into something oddly like a text adventure version of the game. It's a way for me to check the available paths through the game much more quickly than playing through the whole thing, particularly if I change one detail and have to go through it again to check that it hasn't wildly upset the balance. (I might release this version as a pointless extra!)

It still isn't a substitute for playing the game itself to check the actual difficulty of the missions that you're sent on, because the Java player can just call them done if they're logically possible - balancing actual difficulty, particularly on a game that you've been familiar with for the last two years, is a different challenge entirely.

The Statistician

This is the newest addition to the family, and also the simplest, as it uses a lot of the functionality of the two parts that were written before it. The statistician is another aid in balancing out the game - it simply takes the initial state of the game, as used by the Player, and looks at every objective and level available, counting up the occurrences of each item and the use of each ability to report on how often each appears, to make sure I'm not overusing or underusing anything. If I get really ambitious with this I might also give it the task of looking at the various synth recipes and calculating how likely you are to find the necessary items for them given the possible value of the Luck statistic at the time (which is increased as you get further into the game), but that's become something of a secondary consideration for the moment because it really needs the rest of the game finished before I even have a hope of deciding on the possible recipes.

Basically the development of this game is all a vicious circle with each part relying on everything else, and that's something that I can't really escape. But with everything outsourced to a data spreadsheet and giving myself as much help as possible, I can at least make it fluid enough to easily play around with as it takes shape. For now, more levels are the objective - I'm faintly optimistic. Not of finishing the game at any time soon, that is - just that it might theoretically be complete at some point in my natural lifetime.

Almost unbelievably I had a useful dream last night, after being unable to sleep for about two hours, in which I managed to conjure up an entire new level style as well as a couple of its slightly unusual inhabitants. I had to go and preserve this in the actual game as soon as I woke up, then downloaded a video-GIF converter to pull a captured video of it crudely on to this journal with a massive watermark over the top.

Behold!

It is a FLYING CARROT.

Like everything I do it needs a bit of extra graphical work to make it look a bit more threatening (and that grass certainly looked better in my head last night), but I think the mechanics of a pointy root vegetable with helicopter blades on its stalk are already an achievement in uniqueness.

This weekend I've been playing through Crystal Towers 2 - something that I haven't done in about a year. That may sound odd considering I'm writing it, but I hadn't realized until a couple of days ago that all my playing of it for ages now has just been little tests of individual levels and objectives, without stepping back and looking at the big picture of it to see how it's actually coming as a game so far.

The most striking thing was that ever since I accidentally started making an RPG instead of a platform game, I had no idea how big the whole thing had grown. When I thought up the basic game structure ages ago, with eight individual objectives per level (one of which was just completing it and the others were completing it in some special way, or doing something completely different) it seemed like a good way of adding legitimate content with the minimum of level-designing effort, but I hadn't considered that this would result in a sort of multiplicative growth that would put the number of individual "levels" currently at 128, with sixteen physical levels in various states of disorganization. Added to that are the rewards that can be collected on each level (four on each, and they can be a number of things - simple synth items or upgrades to your statistics or abilities), and the trophy items that you can get by collecting recipes and making them up using the Music Castle's central Synthesizer (get it?). And you're also awarded a little medal for completing a level with over one hundred of the little gems strewn about.

One of the sheets that the rules writer program looks at to generate the rules files for the game. It's much, much worse than it looks

So I don't think that longevity is something that I need to worry about (indeed, I'll have to cut back the time involved in getting some of the objectives if the number of levels grows much more) - the biggest difficulty I found when I played through the game was the balance of it, the times when you have the means to get new abilities from somewhere or other and their relative difficulty and obviousness. With so many different routes through it, this is something that's going to take some careful thought, and it'll probably be upset all over again each time I add any new levels. There needs to be a balance of feeding the player with new levels, and encouraging them to go back to the ones they have open already to explore them and put in some effort to gather items. With most of the game's numerical data (like the items required to enter each level) coming from an intimidating titan of a spreadsheet, those can be changed around as much as needed, which is just as well because it was completely off when I played it - the worst example was that you could get the first instrument of eight without a hope of actually being able to put it in place for hours.

Even though it's been ages since I worked on it and doesn't really have any features that wouldn't be achievable by using a couple of Post-It notes, BugRIT has been indispensable this weekend - having it up on one monitor and putting issues in as I found them made it much easier to keep track of what I needed to do, and it's nicely encouraging to see just how many little things I've fixed in a short time - though I have to make sure that I'm concentrating on fixing vital things instead of putting in anything new that's going to cause even more problems later on.

The best bug I've found so far is that you could only earn Medals if the game's music was turned off. This is the thing about computers - a lot of the time, completely separate things can work together to produce something that seems to have a mind of its own.

Once again I haven't had much to say for ages here, partly because of working on a large new feature at work and being a little too preoccupied with it to come up with any interesting commentary. But at home, I seem to have entered another game-making phase and Crystal Towers 2 is once again looking like it might be completed at some point within my lifetime, with an actual level tree now drawn out and some real progress being made for once.

Polishing up my existing levels and getting them up to a presentable level, as well as finishing off the last bits of the underlying engine (as I have been doing for the last two years) will be an ongoing project that I'll pick at in between creating actual new levels - when I actually lay them out I'm fairly energized by how far the game's actually come since it was started, after continuous rewrites and reworks. Over the last couple of days I've been working on the progress-keeping and online submission feature...

This project's been a sort of weight hanging at the back of my mind for ages, mostly because I've been completely unable to decide whether it's actually terrible or not. I was also a bit put off it when I tried twice in a row to carry on with it only for the computer to explode in similar ways, but after a while away, I was more enthusiastic this weekend about setting myself a goal of polishing up the first level enough to be presentable as a video.

This clip shows Walnut Creek area A (named after a town next to where Whitney's parents live that I thought was the best platform game level name ever), demonstrating a complete graphical change from last time I showed this around, the little details that I've been putting in to polish it up, and the emphasis on stringing your jumps on enemies together.



The structure of the game's going to be around a central hub, from which you can unlock and enter levels by collecting items to open teleport rings. Each level has a number of challenges in it, which you're given if you go back in after finishing it once. A bit more like Mario 64 than I had first intended. You can probably work out the other influences from just looking at the video.

Slightly higher-quality version with the &fmt=18 trick

In between being my graphical consultant as someone who can see in colour, Whitney has been on the sofa all day with a cold and has started talking to the frying pan - I think I might need to give her some more medicine soon.

Me: I have an inexplicable urge to work on Crystal Towers 2 again after not touching it for ages. Playing Ratchet and Clank all week's given me even more ideas to start putting in and then have a crisis about the likelihood of ever completing.

To keep the streak of Crystal Towers 2 work going, I decided to see if I could work out a second boss (out of at least eight) - a centipede type affair. To test out the idea I did up a small proof-of-concept application that had a "head" freely moving and an arbitrary number of "tail" objects, put in place by checking their unique IDs against a hidden string of points that the head recorded as it went along. (And that worked out rather well - it's here, if you can open MFAs.)

With that done, my computer obligingly threw itself off a bridge, in that the power cut out and the PC speaker screamed an alarming alarm at me. This is the sign of the safety cut-out for the processor running too hot, so it seems that I had been stretching its abilities a bit by running it pretty much non-stop as a BitTorrent seeder for a couple of months. I tried it again an hour or so later and the innards are all right, but the temperature was definitely climbing steadily (to 70C before I turned it off). I'm hoping that all it needs is a dust, because being under a desk for that long must have blocked it a bit.

So the rest of this post is going to be about Okami instead. We joined Gamefly, an online game rental place, this week, and Whitney had been wanting to try this for a while. Unusually for our game playing I've only been involved very loosely, with Whitney doing the vast majority of the playing, so I can only describe it vaguely, but in today's increasingly genreless definition it seems to be an action RPG steeped in Japanese tradition and culture. Not falling into the traditional "start totally useless" tradition of most games like these, you play as a wolf-shaped sun god called Amaterasu.

You wander from place to place, being given various odd jobs by various odd people and having to clear them to get the ability to progress further, fighting monsters and clearing evil mist along the way. The fighting is sort of a combination between something like FF12's seamless battles and more traditional separate-screen ones - when you get too near a monster a fiery arena grows up around you and you can only then escape by defeating it (in which case you'll then be rewarded depending on your time and damage taken, both represented as various bits of tree of varying desirability for some reason) or finding a gap in the arena to run away. The game's real draw (aha) is the special mechanic of being able to hit R1 and paint on the screen at any time.

Not that it actually does anything, most of the time - you can't draw up a couple of giant bipedal robots to help you vanquish the marauding evil - but it works based on patterns that you draw around certain objects. Your main objective, as I mentioned, seems to be to remove the evil mist and enemies and turn it into puppies and butterflies by use of the Celestial Paintbrush - drawing circles around things causes them to grow and gets you more Praise points from watching cute animals, drawing squiggly vines connects things, and you can also summon bombs by drawing a line through a circle, if you can muster up the dexterity to do so. And it's all very interesting - the way that the screen dissolves into a drawn scene when you prepare to use the brush is particularly incredible.

As you may have gathered from my last post if you somehow hadn't noticed already, the Japanese seem to be good at unintentional strangeness, and this has got that in spades - you're accompanied by a talking flea called Issun who acts mostly as your voice as Amaterasu is mute throughout, and all talking is represented as a sequence of insane squawking noises that sound like what would happen if you took all the vowels out of this post and fed it into one of Microsoft's text-to-speech tools. Backwards. With the speed turned up to maximum. Often people won't bother to animate talking at all and their hats will bounce about a bit instead. It's definitely stylistic, but sounds disturbingly like Weebl and Bob.

That's about as far as I can describe it, because I haven't really played it myself. But I'd like to, because it looks really clever. And as I type this my laptop is now at 167F, so it might be about to explode in my face as well. Our flat isn't a good environment for computers just now.

Crystal Towers 2 seems to put me in one of two opposite moods at any time - there are times when I see that it's really coming together and going fantastically, and there are other moments when it seems like I'm running a marathon with my feet on backwards and the whole thing is an insurmountable task. Hoping to reduce that last feeling a little, I poured all efforts into putting some sort of cap on the game last week, and the game is now completable from start to finish.

Some more work may be required here

That's very different from being complete, though - all it means is that I've set up some levels in the hub room that go to placeholder bosses and levels. (The model I used for the levels, disconnecting the actual frames entirely from their objectives or level names, accidentally helped out a lot here, as you can just point a heap of things to the same in-game level and it'll track progress through each of them separately.) These placeholders allow you to start the game, wander around the very much under construction Music Castle, gather up items through the levels, collect the all-important Music Crystals from the bosses and deliver them to the roof.

This summary screen's quite nice, though

Once you have at least eight of the crystals you can fight the final boss (again, a blank but unique placeholder frame at the moment) and, from there, get to the end sequence and summary screen, which will allow you to upload your progress again and then dump you back at the main menu to try and get 100% completion (a handy device - thanks, modern gaming concepts).

I should admit that very little of this is actually new, but it's caused a huge shift to the process of making the game - mentally, at least. The process now isn't primarily one of trying to get something that can be called a full game (although this can't, yet), but instead an exercise in polishing things up and filling in the blanks. Once I've got the obvious gaps crossed, such as real cut-scenes, an actual collection of bosses, and so on, the focus will shift again to having a game that can be called "complete" at any time that I happen to get fed up of adding extras. Hopefully that'll happen later rather than sooner, but at least this way it won't get stuck in limbo like one-man projects tend to do when that one man can't stand it any more.

Taking a break is always healthy, though, so with this milestone passed I'm allowing myself to start a new experimental project or two. Neither of them will be gigantic, but one in particular is becoming far more interesting than I ever thought it would be.

"Ooh, yes, I've finished all the backend stuff and I can get to work on seriously making the actual game now" is what I've been saying in virtually every entry on this for the last year and a half. But it never really stops - if MMF has one specific weakness it's its modularity, in the way that for the most part event lists are tied to frames, and the result of this if you change something in one game level you need to go and copy and paste it into all your others (not to mention keep track of which one has the most up to date list that you want to synchronize). But this weekend I've been trying to make things easier for myself in that respect.

You really need to plan a game of any decent size from the beginning if you want to finish it within your lifetime, and Crystal Towers 2 has gone through a lot of changes that would have been much easier to cope with if they were in from the start, so I'm performing a great refactoring to speed up the rest of the game and this time really have something I can just add on to. Initially, the game relied on itself for its data - abilities, items that monsters could drop, and so on - with a couple of external plain text rules files for things that I wanted to be able to change easily, like the missions for each individual level. That was fine at first, but as the game began to balloon up beyond all proportions that I ever imagined it to have, I started an Excel spreadsheet detailing all the data in the game as well. And as I realized I kept having to replay the game to keep track of where I expected the player to be in terms of progress at each point, I then wrote a Java solver that used yet another version of the data in the game to tell me the possible "moves" from each position (with a completion of a level or gaining of a new item counting as a "move"). So up until last week, I had to keep four copies of the game's data up to date with each other, with only a slight link between two of them offering any sort of intelligent reuse of information. This is what we in the computer science world call "a nightmare".

It was actually when looking at the external rules files for Civilization II that I realized how stupid my current situation was, and decided that I'd better do something about it. I had previously thought to myself that it would be nice to read all the game data in from the spreadsheet that I was using to stop myself going insane rather than having to copy it all in manually afterwards, but I had dismissed that as being too insecure a way of doing things and I didn't know if MMF's database connection object could read Excel files without Microsoft's additional gubbins installed. But those Civ 2 rules files gave me an alternative idea - I was fairly confident that somebody in the world must have put together a way of reading Excel files from Java, so I could get that copy of the data into my solver fairly easily, and once I'd got that, I could get Java to write out the rules files itself to be read by the game.

So this is roughly the alternative communication between files that I have going on now - everything is connected and sourced from the same place instead of having each part hovering around looking lost. Thanks to a bit of planning ahead when I converted the save files over to a better system, I also have the option of encrypting the data and making it uneditable while still allowing the game to load it (which will be very important for the online scorecard system) - this happens through a separate MMF translation application. The parts of the game that used rules files already have been easy to convert, as all I've had to do is write a translator in Java to gather them from the database and put them in a form that the game can use. There have also been parts that relied directly on data in the game, which were more difficult to convert as I had to come up with ways to externalize them.

For example, one of the biggest problems I had with the old system was the list of items that each enemy could drop. I had initially written it so that each enemy detected when it was about to be destroyed, picked a random number and dropped an item based on a list of hard-coded chances. With the new system, it instead leaves behind a "SynthCreator" object, gives it its name, and allows a global function to take care of the rest. This function performs the dice roll, looks for any entries in the "drop" rules file that match the name it's been given, and creates a dropped item accordingly. The whole process is so much simpler, even if it did take a weekend to convert everything over to using the new and much easier way - all I need to do now when an adversary is destroyed is create one object and start the function. While I was at it I also externalized the damage that different damage types cause to each monster type, the amount they take off your own health when you blunder in to one, and so on.

Changes like these, along with trying to move everything possible into the global event editor (which I was wary of as it was rather unstable in earlier releases of MMF, but it seems to be absolutely fine so far) make the events of each level much simpler to understand and work with, as they just need their own unique events rather than a copy of the ones that are used throughout the game. So this time, I really am confident that it's taking shape.

It helps that the graphics I have from Jay Frudy are fantastic, too. I'll put a video up at some point to save you reading all that.

As I haven't updated on this in over two months now, you might have thought I'd forgotten about it - but I haven't! My creativity for it seems to come in bursts, and while it's still a much larger project than I ever intended it to be, I've finally got down to planning out a definite list of collectable abilities. Even putting a cap on those is a large step in working towards something that's finishable.

The really exciting news is that I've secured a new graphics artist. He's the same one who worked with me on Special Agent a couple of years ago - the fact that everyone else who has offered to do the graphics for this game so far has gone into severe depression shortly after starting hasn't discouraged him at all! And as a result, Bernard has had an overhaul. I can't quite express how exciting it is to have something this much more animated compared to the original sprite - it really brings the game to life instantly.

On my end, a lot of work recently has gone into the planning side, which is sometimes dull but necessary. Previously, I had four separate things to update - my plan spreadsheet, Java solver, rules files and the game itself. This was naturally terrible. However, after getting an Excel parser working in Java the other day (which was triumphant until I remembered I use OpenOffice), I have the Java solver getting almost all its data from the plan spreadsheet itself. Now, if I can think of a way to get enemy drop rates read from an external file, I just need to write a similar parser to write out rules files from the spreadsheet as well.

In short, I must be mad. There are times when I wonder why Whitney married someone who does this kind of thing in his spare time.

billy1987_1994 often mentions that his iPod has developed a strange sense of appropriateness in its song choice depending on mood or location. And it seems that my iTunes has become similarly self-aware - putting on As Long As I Fall while I was yet again struggling to get vertical platforms working can only be attributed to malice. After hearing the line "I don't hit the ground" while watching your character sail right through your carefully constructed detector you aren't sure whether to laugh or cry.

But after a lot of frustration this week, and even more whiteboard note-taking (Whitney got me a whiteboard for Christmas, and it was fantastic, because I'm miswired like that) I think I might have just got them working. Nearly.



I was always pretty fascinated by the state of whiteboards in the CS department after someone had been working on something for ages. Presumably every fragment of information on them is in some way useful, but altogether they always look like unorthodox impressionist paintings born from too many packs of Wine Gums.

Anyway, the real point of this overambitious week is that I now have a grand unified Platform object that can move horizontally, vertically or any direction in between. Have a look at the practical demonstration - graphics are very much temporary, but it shows the kind of thing that can be done, starting off with dull simple left-right movement but gradually introducing more elements such as vertical movement and movement by sine waves for swinging platforms.



Vertical platforms sound simple in themselves, but it took ages to get these working at all - with plain horizontal movement you only need to worry about moving left and right in the same way as walking normally, but if the player is to be moved vertically, you've got to work against the gravity that you've written and build in support for that. And as much as you know I like MMF2, there's something very wrong with its detection of collisions of objects that have moved during fastloops - the whole thing works by looking at one invisible detector underneath the player and another one on top of the platform, seeing whether they match when the player is moving down and while the platform is moving in any direction. But as collision detection was so erratic I had to switch over to looking at the positions of each object instead and decide whether they were overlapping based on that information.

Another problem was that as I was moving detectors and objects around so much on each frame, it became very difficult to keep track of where objects actually were during it, no matter how much I put into debug information during the loops. (MMF2 provides a debugger for examining each frame, which helps a bit, but it's actions before drawing a frame that I was worried about this time). So in the end, I made it up to the player object to decide whether it was on a moving platform or not - that's what the "OnVert" property that's still in the text at the top right of the screen is for. When a platform is told to move, it checks whether the player is over it first and sets the OnVert property to its own ID value before doing so, and this is later used to decide whether to allow gravity to affect the player or not.

The trigonometric movement of the platforms is done by giving each individual platform a "Type", and writing a special-case set of pixels to move horizontally and vertically for each of them (I finally had to remember differentiation again to work out how the swinging ones should move). I might be able to simplify it a bit by putting another couple of values on the platforms to specify where they should move to on the next frame, and let the game work out the actual distances itself from there.

Frankly I'm very surprised that you've read this far.

After a long period of inactivity, I've revived Crystal Towers 2 and over the past week I've been working to get the interface looking a bit less hideous. Most importantly I've thrown out the OCR Extended A font that I initially thought looked "retro" but have recently reassessed as "ugly", and replaced it with some alternative more acceptable fonts. I've also been using the Text Blitter object a bit to include bitmap fonts, but it's doubtful that you actually care about this, so here's a video.



That shows the player setup and tutorial, as well as a bit of what I have of the online scorecard system - the idea is that you'll be able to upload data from computers within the game and then visit a site and compare your progress against others. I know that the sooner I find a video codec that doesn't mangle pixel art the better, but you can just about read it if you squint a bit.

Well, I have to say that I'm beginning to regret not buying a whole lot of furniture last Spring. But at least Boston's decisive win against Colorado in the World Series (which doesn't actually invite competition from more than one country) means that there won't be any massive crowds of people in red shirts during my commute home in the next while. It's almost enough to get you to start caring about baseball - I'm only vaguely aware that it's nice that a team that previously seemed to be totally useless have won twice in such quick succession.

For carefully thought out attention-getting reasons, I'm going to stop putting Crystal Towers 2 progress posts exclusively in its own journal and include them here under a tag instead (I'll backdate them when I shovel over the rest). To give the best impression of what the game looks like to date, I have hit a new low and posted a video on YouTube.

This video shows a weekend's work on the first boss of the game, which I finally sat down and wrote after weeks of not doing anything. Most of the graphics are yet to be drawn, but it shows what the general gameplay of it will be like, and I'm rather pleased with the result. Bosses are very difficult things to program, needing a complex attack pattern based on several different states and branches, but I think this is the most competent one that I've done yet. The only bit of this one I'm not totally happy with is the large length of time that it spends just sitting on the ceiling if you destroy all the bouncing bombs quickly, so I might have to think of something to do there.

You can also see two transparent areas on the left and right of the playfield, which restore the magic points you have available. Usually you restore your magic in-game by picking up white vials, but this situation needs something to allow you to rapidly get back to full magic and back to attacking again, but I don't want them to make it too easy (particularly as you can also use magic to heal yourself, and if you have an inexhaustible supply the boss becomes impossible to lose to). I could either disable curative spells or make them affect the boss as well so that there's a disadvantage to using them. I may replace the restoring fields with one "magic field" that floats from left to right, then reduce the hit points of the boss a bit to balance things out.

The eventual goal of the game is to find eight instruments and restore music to the Music Castle (an idea that I only noticed I'd stolen from Zelda well into making the game). The instrument carried by each boss is random, and as luck would have it, on that attempt I got the only one I hadn't drawn. The name of the instrument is chosen at random, too, which explains the strange names that appear at the end of the video.