Have I mentioned how much I love MMF recently? Ever since I discovered it through its predecessors, I've just taken it completely for granted that I can put sketches of applications together almost instantly without needing to worry about the underlying engine, and it can do a surprising amount in terms of complexity before it begins to get unwieldy. If regular programming languages are a blank canvas with which you can do anything, and most game creation systems are colouring books, MMF just hands you some brushes that might be a tiny bit large for very specific situations. (While ZZT gives you some potatoes.) And in theory, soon you'll also be able to change the export settings and have things immediately in Flash and Xcode (although the instantness of them may be some way off yet).

Blame it and the fraction of a gestalt entity known as teogames, then, for this (if it makes you or me feel any better about it). When a discussion about a sliding puzzle on Professor Layton got started, I recalled that I had gone as far as to write a tree-based solver to get past it for me. I then realized that in the solver, I had the perfect tool with which to create my own diabolical challenges and verify they were at least possible, and a competent recreation of the puzzle style was done in just over an hour.


I'm not really sure how I got here

I have called this FISP for now. Three of the letters stand for "Impossible Sliding Puzzles". Drag the shapes about with the mouse, with the aim of squeezing the yellow one around to the goal space - the one available level is what I would consider one of the easiest puzzles that I'm going for with this project, and it's solvable in at most 19 moves.

The dragging of the shapes is still a bit tuggy if you get caught on other shapes... I'll have to put a bit more effort in to get rid of that.

Marking about the fifth game that I've released since starting my alleged current project, I battered this puzzle/observation thing out in MMF over the last week after taking the concept from a game that I was doing for another site. Buying the Commodore 64 book had got me in something of an 80s mood - I came up with the entire "storyline" for it on Tuesday morning and it was done by Friday. I wanted it to be a bit... crazier and take itself less seriously than some of my other games, striving for a mood that was something like the random shareware games that I was fed on while growing up.


Special Agent Bunnet versus Doctor Dishwater

The aim is simple, as described in the story - deactivate the bombs by finding the buttons that don't have duplicates anywhere else - but the field you have to search through gets gradually larger throughout the game. About ten people have reached the end so far - one of them in four minutes, which surprised me as my own record's closer to five. Hopefully it's the kind of thing that you can use to distract yourself for lunch - then to forget that lunchtime ended an hour ago.

What I'm interested in is whether this sort of anti-pairs game is something that anybody's done before - it's such a simple idea that I feel that they must have, but I can't name anything myself (though perhaps you could argue that it's just a variant on the hidden-object click-em-up genre).

I'm also aware that this game's title starts with "Special Agent", further cementing the theory that I only have three game titles that I'm going to be using for the rest of time.

UPDATE lcmr.content_relationship SET content_entity=
(
	SELECT TOP 1 ce_id
	FROM lcmr.content_w_xms_name newContent
	WHERE newContent.content_type=130
	AND newContent.xms_name='Badger Mushrooms'
	
)
WHERE id IN
	(
	SELECT lcmr.content_relationship.id
	FROM lcmr.content_w_xms_name newContent, lcmr.content_relationship
	INNER JOIN lcmr.property_value
	ON (lcmr.content_relationship.id=lcmr.property_value.id)
	WHERE property=13
	AND lcmr.property_value.content_instance NOT IN
		(
		SELECT pvForExisting.content_instance
		FROM lcmr.property_value pvForExisting,
		     lcmr.content_relationship crForExisting
		WHERE pvForExisting.id = crForExisting.id
		AND pvForExisting.property = 13
		AND crForExisting.content_entity IN
			(
			SELECT TOP 1 ce_id
			FROM lcmr.content_w_xms_name newContent
			WHERE newContent.content_type=130
			AND newContent.xms_name='Badger Mushrooms'
			)
		)
	AND (newContent.content_type=130
	AND newContent.xms_name='Badger Mushrooms')
	AND content_entity IN
		(
		SELECT TOP 1 ce_id
		FROM lcmr.content_w_xms_name oldContent
		WHERE (oldContent.content_type=130)
		AND oldContent.xms_name='Cow Exploding'
		)
	)
;
DELETE FROM lcmr.property_value
WHERE id IN
	(
	SELECT pv.id
	FROM lcmr.property_value pv, lcmr.content_relationship cr
	WHERE pv.id = cr.id
	AND property=13
	AND content_entity IN
		(
		SELECT TOP 1 ce_id
		FROM lcmr.content_w_xms_name oldContent
		WHERE (oldContent.content_type=130)
		AND oldContent.xms_name='Cow Exploding'
		)
	)
;

A masterpiece. (This is just one of them - it has to do all this about 32 times for different locations.)

Note the fair amounts of repetition - SQL is not my strong point, and this probably does things 100 times slower than they could be. It might be possible in about four lines, I don't know.

Coders, help me out by confessing so that I'm reassured I'm not the only one...

If you're working on a project that has a significant compile time (say, five minutes or so), and you set it going and then realize that you've forgotten to change one thing that you want to get in... do you stop it, or do you - as I do - seize the opportunity to prove your superiority, leave the compile running, zoom to the file in question, and race the computer to make the change and save the file before the build grabs it?

My giant floppy ears were alerted to a promising development in the MBTA yesterday by the Livejournal community that was set up to moan about its usual ineptitude - they've got together with some sort of national online service provider called NextBus to provide an experimental feed that makes the GPS locations of its buses freely available.

Come on, 111! Come on, 116!

What this means in less dull terms is that it's now possible for people who are web-inclined to tap into that feed and find out where buses are and how long it's likely to take them to arrive at their destinations - and therefore yet another project has been added to my already groaning pile. Only five routes are represented during the trial period and none of them are anywhere near the places I actually travel in Boston, but I spent some time yesterday creating a small page to collect the predictions for individual stops together, then didn't sleep at all due to having some terrible nightmares about buses.

I'm very much looking forward to it being expanded to the rest of the system and taking the guesswork out of the CT2's largely fictional timetable - for now, I've tragically been spending my compile time watching the 111-117 buses race each other to Broadway and Fourth Street remotely via the Internet.

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.

The trouble with having gone with MOD as my music format of choice nearly ten years ago is that almost immediately when I started, it became obsolete and every other popular music package sprang up using MIDI-based formats. Even though you would think that music formats couldn't be all that different from each other, I haven't yet found a MOD to MIDI convertor that does what I need it to (Modplug's own MIDI import and export is particularly awful), which is a problem when I put up tablatures of my songs because I have to convert them all by hand. Often this results in being able to improve on some parts of the original that I might not have got quite right the first time, or introduce a couple of new ideas, but it's the sort of thing that's very programmatic for the most part.

So I invoked my philosophy that the good thing about computers is that you have the tools to automate repetitive tasks on them already at your disposal, and decided that I could at least attempt to get it to lay the groundwork itself and rewrite the drum parts in MIDI for me. So the idea for a new Java project was born in the form of DrumWriter, and the basic plan was simple - find something that could read MOD files, find something that could write MIDI files, and then nail them together into a sort of musical chimera.

Reading a MOD

My first target came in the form of a library called JMOD that seemed incredibly difficult to get hold of even though it came up on a search - the best link I found was to that beta version of it. Almost immediately I came across one of the disadvantages of unfinished open source software, that being that it was unfinished - I spent a while wondering what I was doing wrong while loading my .IT song files until I went in to check exactly what it was doing on loading them, which was to make up 64 completely blank tracks and then return them without so much as looking at the actual structure of the file. I didn't have a way around this because adding that would have required a knowledge of the IT file format, which is what I was using someone else's library to avoid - instead, it's not too much of a bother to use Modplug to save them as the very similar XM files (which JMOD can actually read and not just pretend to) before using them.

The second problem was that the format of the samples within the file wasn't what JMOD was expecting - I'm not sure if this is an oddity of Modplug compared to the original Impulse Tracker or not, but it made it just throw an exception on trying to load them. This was a bigger problem, and I ended up just completely removing all attempts to load any samples from the code and recompiling JMOD into my own patched version, seeing as it was just the song layout that was important to me and I wouldn't actually be using it to play back the file. After those two fairly major obstacles were out the way, I could load in a finished MOD file and run through it to recognize when individual drum samples were played, constructing an internal sort of piano-roll arrangement.

Writing a MID

The second half of the exercise required taking the drum pattern that I'd gathered in the MOD and then writing it out to a MIDI file. My first choice for this was Java's own MIDI library in javax.sound, but I quickly learned that this was not intended for humans to understand - adding notes to a file involves constructing a MIDI message byte by byte and then inserting it manually into a sequence, which isn't the most intuitive of ways to work. (Despite their simple sound, MIDIs are very complex and hold a lot of information - MODs are solid and wonderfully logically laid out by comparison.) After searching for an alternative I quickly came up with JFugue.

JFugue uses a rather unusual string notation that isn't at all far removed from ZZT's idea of a music format, a set of characters that together represent notes and durations (though it also has to worry about instrument, channel, and so on). As you can see from the examples, it even provides special methods for writing percussion tracks, inventing the concept of layers to get around some awkwardness that MIDI usually has with this. It's a free library, but gets you by putting a price on the manual for it, so I just muddled through with the Javadoc of it to help me through. And after some hammering, I got it to generate a set of rhythm strings based on the drum patterns I had from the first step (one for each type of drum), convert those to a combined music string using the relevant drum instruments, and export the whole thing to a MIDI file (a step that took me much longer than you'd expect, because it's curiously a method of the Player class and I couldn't find it for ages.)

The combination of the two

There was one last oddness that I had to get past, and that was in the import into Guitar Pro 5, which uses its own format but can import MIDI (making the entire chain IT → XM → JMOD → DrumWriter → JFugue → MID → GP5). For some reason, the MIDIs generated by my program come out far too fast when imported - and not just in tempo, it was that the notes are treated as hemidemisemiquavers when they should be rather a lot longer. I got around this by simply making the conversion step with JFugue output notes with the duration of crotchets when they should be semiquavers (therefore four times their intended length), which works when imported, though I'm not sure why.



This is part of the result of running it on a song that I'd converted to tab myself previously - the one that I did by hand is the lower score, and the upper score has the same piece of music converted by this new drum writer. As far as the notes played go, they're aurally identical - you can see a slight difference at the end because the drum writer only ever treats anything as a semiquaver (I think Guitar Pro combines long stretches of rests itself), but this doesn't make a difference to the sound because percussion instruments don't have a concept of how long they're played for, and I only ever made them longer in the original version to make the score more readable.

Another problem with its readability is the way that the events on the tab layout below the stave are scrunched up together, without having a line for each drum like I laid them out when I did it myself. This isn't a huge issue because I shouldn't need to edit them a whole lot - it's something that would be nice to correct, but I can't see a way of doing it, because representing drums as a tab is a feature of Guitar Pro 5 that I can't directly save when I output a MIDI, and it seems to just put the drums in numerical order from the top down on every beat.

The other large detail missing is the dynamics, which are generally handled a little differently in MIDI compared to MOD, but I might be able to just convert them over note by note (GP5 does it this way as well - the more faded a note is on the score, the quieter it is).

Since last night I've also completely misnamed it by extending it to handle melodic instruments in a basic fashion as well - this is the result of running it on a song that I have in progress at the moment, with just the drums, bass and harpsichord parts turned on. For something automatically generated from a completely different format it's pretty convincing.