Just Some Johnny Saucep'n

While still working hard on the Opera StumbleUpon widget, I've recently returned to tinkering with Repton Fusion, and implementing my master plan - the reason it's called Fusion in the first place.

I started refactoring a lot of the code a while ago - I wanted to separate out all the game-specific code so that I could re-use the engine core for other purposes. The aim of this was to quickly add new and different game types, and I'm glad to say this is finally becoming reality!

Two new game types are in development, both will be recognisable
to BBC Micro and Commodore 64 gamers, and possibly a few others - Bonecruncher and XOR. Although superficially similar, they differ quite radically in how they behave, and how they differ from Repton.

First, a little background - I have currently two 'types' of game object, firstly the tile-based MapObjects (like Repton rocks or diamonds) that are only ever on one square or another, and all behave alike. This allows me to use a Flyweight design pattern - instead of storing the state of each individual rock, I can have one object storing the properties of 'rock', and only store references in the grid. This saves memory and time, but doesn't allow any rock to be different from another; I would have to change the grid square reference from a 'rock' to a 'bouncyRock' or something similar.

The second type are Characters, which are allowed to smoothly transition between squares, have their own internal state, decision-making processes, and so on. Repton, monsters, spirits are all examples of these. They also have the advantage of being able to move 'over' squares if necessary - they're not stored in the grid, but keep their own x-y coordinates.

These types are the key to all the future design decisions - will they be flexible enough to fit the different game types?

I initially started with Bonecruncher, and made pretty good progress. But it became clear that the specific mechanics of the game required a lot more thought and planning - particularly that, where Repton only 'activates' the content of the square when the character or monster finally moves fully onto it, Bonecruncher activates when the character first starts moving towards it. Althought that's easily remedied, it has had a knock-on effect on other game mechanics.

The worst part appears to be Glooks - they smoothly slide between squares, but need to be thoroughly solid to each other and to other objects, and there can be an awful lot of them! So, they end up somewhere between the two camps.

Since I'm still wrestling with these dilemmas, I realised that XOR would probably be the easier option, so I started on that. And I'm glad to say that, after only a couple of hours work, the engine is 80% complete! Masks, fish, chicken, dot, waves, maps all implemented and working. Bombs move as required, but don't explode. I only need to add them, dolls, frowning masks and teleporters, and we should be in business. XOR is simpler because all objects are MapObjects - the player characters are the only Characters.

Dolls might be a pain - one they start moving they don't stop, but I don't know if it's required that they only move one step at a time. If it is, then I would need to store the state of the doll, or at least define 'dollMovingUp', 'dollMovingLeft' and so on.

I even have the multiple-character support - since I've abstracted out the controller from the game itself, I can attach that controller to the current character, then detach it an attach to the second character at will, and refocus the camera on that character.

In fact, there's a heck of a lot of functionality that isn't currently used but was put in for future expansion - let's hope I get to exercise it.

For anyone who is wondering, switching between the game types is easy - I've implemented a Factory pattern which calls the specialised createGame, createLevel, etc. methods for each game - all you need to do is set a reference to the correct GameFactory and the shared code does everything else.