Just Some Johnny Saucep'n

Well, I've just released a new widget, hopefully in the running for the Wii competition.

Technically, it's the most ambitious widget I've ever attempted - I originally started it well before the current competition, as an attempt to learn the canvas tag and to get the feel for the more object-oriented features of Javascript, and how they map to existing OO design patterns. As a side-project, I also wanted to test how compatible advanced Javascript and canvas code can get. More on this in a later post.

The aim of the project was to produce more than just a single game, Repton Fusion is just the start. Basically, it was designed to allow an infinite range of similar puzzle games to built with the same core, despite some fairly extreme variations in the game logic.

I hope to roll out XOR, Bonecruncher, and versions of the Repton Infinity games soon.

To achieve this, most things in the game are built as extensible classes, and the use of globals set to an absolute minimum (usually just the main 'game' object). This allows multiple main characters (such as in XOR), multiple viewports (for example, the Repton map is drawn as a new Camera object pointing at the hero), multiple linked areas in the same level (allowing for Repton 2-style linking maps). There's a abstract Controller object, allowing other methods of communicating with the hero. There's the beginning of a class for a Wii remote control, but I can't currently test it!

Each area in each level can have its own scenery graphics, and each episode can have different object and character graphics. I decided not to allow changing object/character gfx between levels, as this would make things impossible for the player! This allows new themes for the games, such as the Around the World in 40 Screens and Life of Repton expansion packs for Repton 3.

The level-retrieval system caches the entire episode and level data files in widget storage, relieving the network pressure of repeated plays. I can also hardcode levels into the widget itself, which I will do when I'm sure any teething troubles with the level designs are ironed out! All episode Catalogues, Episodes and Levels are described in XML - either retrieved by AJAX, or parsed from strings using DomParser().

Also in the pipeline is a visual editor for creating and submitting your own Repton levels.

I use a Factory design pattern to produce game-specific Level, Area, Character and Object classes for each game, and Flyweight objects for the invidual objects. The Area maps are simple 2d arrays of references to these flyweight objects, allowing the whole level to operate much like a cellular automata simulation.

The various Areas are held continuously in memory during the course of a Level, so a player can jump in and out of Areas while maintaining the state of each. For speed reasons, any Area the hero isn't in doesn't get updated, but this could be overridden for a different game type.

Because of the rush to finish for the competition deadline, there's a lot of functionality in the ReptonGame object that should eventually be moved to a base Game class once I can generalise it, and much that should be in completely different classes. The Game object should really only concern itself with the operation of Levels and Characters, with some kind of UI object handling the level selection process.