Wacky Wheels

 

Following my previous experience with Zool, I have started another game project in parallel; a 3D version of the Wacky Wheels game. With Zool, the main challenge was the acquisition of the game assets, for Wacky Wheels however, it is an entirely different story as the differents formats of the game data files are well documented.

I have therefore been able to get started pretty quickly and within hours I could see some results.


Figure 1 : the first track of the first class, with a naive implementation of the background


Figure 2 : the second track of the first class


Figure 3 : the fourth track of the first class


Figure 4 : correct implementation of the background (preliminary)

From the lessons I’ve learned while working on Zool (and the time I spent on it), I have decided to delegate some of the work on this project for the following reason : it is an unrealistic task as a one-man job (to be done in a realistic time frame). Ultimately I can realize that project from start to end, but how long would it have taken ? Hence my decision of splitting up the job.

I guess that it is certainly the best decision for this project to be up in a reasonable time frame. There is a part of the project that I will first finish however; the low-level plumbing. I think this is an essential aspect for making it incentive to potential contributors.

Obviously there is still a lot left to be implemented so it looks like the original game. But in my opinion, there is less work to be done than in Zool as I will reuse some of the components I have developed for it and there is less interaction in this game compared to it.

 

Zool

zool-transparent-150

 

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.