Table of contents
Introduction
Considerations
Approach
Implementation
Examples
Future
Introduction
I have started working on a remake of the Zool game, if you don’t know it you can see some footage here. Before starting the coding of the game itself, I’ve decided to do some investigation to assess the complexity of such project. And from the results of this investigation a couple of things emerged. To address this aspect I’ve decided to craft a specific software and I am going to present it to you now.
Considerations
Since this project is a remake, I had to get hold of the original assets of the game. Considering the original platform of the game, the Amiga, there were a couple of hurdles in accessing them. Beside the characteristics of the platform such as the usage of planar graphics, there was the fact that this platform used custom file systems and crunchers. In addition to these issues there was also the topic of understanding the game’s internals and mechanics.
Approach
I have set up an environment consisting of a virtual machine running an Amiga along some tools. The task of this environment was to retrieve the assets and decrunch them. Once done, the next step was to reassemble these raw assets to their original form before they got packed, for instance, graphics meant to be sprites with animations.
This is where the software I have mentioned plays a key role as it greatly simplifies this process. In addition to addressing these aspects there was another to consider; the fact that these assets were going to be used in a modern game framework. The software addresses that point by re-packing them into modern containers.
Note : an aspect that I haven’t covered regarding the reassembling step in this section is the fact that ‘parameters’ must be retrieved from the game in order for this step to be successful; I will cover this aspect in the next section.
Implementation
Software has been developed using WPF and uses features such as data-binding and commands. Of the challenges encountered there was the definition of the different types of assets along their parameters, their final form and their representation on-screen. Below you can see diagrams about how these parts have been represented in the system.
Figure 5 : the final form of a raw asset that has been processed and will be further exported
Figure 6 : different types of assets along their parameters
Figure 7 : presenters which are responsible for previewing the assets in the UI
Regarding the parameters needed for each type of asset, they all have been reverse-engineered from the game, whether by debugging the in-game memory or by deciphering the different file formats.
As the software is now mostly finished, I have started packing all these raw resources to form a ‘catalog’ that I will use when coding the game. Obviously they will be in a format easier to manipulate as this was the primary goal.
Examples
Below some screenshots of the different types of assets currently decoded by the software.
Figure 1 : a level which needs an associated tile-set and palette
Figure 2 : a tile-set, in fact packed in a well-known container (ILBM)
Figure 3 : a set of sprites, packed in a specific format
Figure 4 : a palette, a key element mostly retrieved from memory dumps
Future
Right now the software fulfils its role. There are still a few things that needs to be implemented such as higher levels objects like characters and interactions to really represent the whole content of the game.
When this is accomplished, I will complete the cataloging of all the game’s assets and everything related to the in-game experience as suggested above. Finally, I will start the coding of the game itself and once it is mature enough, the project will go public and will be open-sourced.