This system proved to be remarkably reliable and flexible, and I maintained it throughout the development of the game, the only addition being the extraction of all game image files from my own format compressed image library, that uses a simple compression algorithm to apply a GIF-style compression to the images used in the game, substantially reducing the disk space (and download time). The files are now extracted as required out of the library, and are stored in uncompressed form in the memory allocated for graphics. The memory system had to be extended quickly after I started to apply the engine to full sized levels, but only minor conversion was required to reallocate the graphics pages to the XMS. Once the image engine was functioning, I started to consider the game engine. Whilst I had been implementing the graphical code, I had already invented some simple game engine objects, which I stored in seperate arrays and initially loaded from constants hardwired into the pascal code: later, of course, these are sourced from the graphics library. The aim, from the beginning, was to create a game engine that was truely generic, dealing with game objects as they occured and treating each object entirely individually, only interacting with the others as part of code assigned directly to them, to minimise any conflict that could possibly be produced between defined objects, and to allow any combination of objects the user specified without slowdown or errors occuring. Hence, the initial object systems, consisting of platforms, walls, stairs, ladders, springs, and teleporters could all be conserved to the end of the game, and interact completely and successfuly with all of the more sophisticated systems I later installed. The game stores the level data itself in multiple arrays: the images are arranged in layers, layer 1 being the background, 2 images that Fred passes in front of, 3 being reserved for the game engine and four as images in the foreground; and the objects stored in their respective arrays. Initially, in the spirit of the generic engine, I entirely disconnected the functional images from the objects; but in the case of common objects such as buttons, this proved unreliable and frustrating to include in the level editor, so the modern version mostely includes dependent images that are drawn by the respective objects. It very soon became apparent that the small levels I had constructed using constants were not sufficient even to fully test the engine, let alone construct complete levels, and so the level editor was born, originally by conversion of the Canvas 2.4 shell, which included mouse and menu control. The level editor was originally ran as an entirely seperate entity, recording the levels produced in level files on disk, to be read by the game. However, it was quickly realised that to construct complex, complete levels the creation needed to be playtested as it was designed, and to do this the engine and the editor had to be combined. This major reworkring of the source code was my first real inclination as to the scale the project had assumed.