Gordon Madness is an arcade level based on the game Marble Madness. The player navigates through three stages of increasing difficulty, guiding a helicopter bomb down ramps, trying get the fastest time possible. The player must avoid perilous drops, deadly spiked crushers, and moving platforms in order to achieve victory.
The primary goal of the level was to recreate an experience akin to Marble Madness. In order to facilitate this, I had to implement a new control scheme and camera system. I also wanted to have the player transition between normal gameplay and the arcade view in a natural manner, so a lab setting was ideal.
Over the course of development, playtesters enjoyed trying to beat stages in the fastest amount of time. This led to the implementation of a clock in the main stage. This was later added to each individual stage so players could get an idea of how they were faring mid stage.
The clock is made of BSPs which are switched on and off by a series of math counters. Separate versions of these clocks are parented to the cameras in each stage, so they follow the player.
Stage 1 allows a perfectly safe environment for the player to learn the controls of the bomb and how to navigate the levels that follow. It is a simple, introductory stage with no hazards aside from getting a fast time.
Stage 2 allows the player to fall off the map, which presented an interesting problem with regard to resetting the player on death and resetting the camera. The ball is destroyed and respawned via an env_entity_maker, as teleporting the player back caused issues with control bindings. This stage also makes use of more camera movement than the first stage and needed a series of triggers to keep the playing area visible as the player moved.
This level also introduces the three major hazards in the level: the spiked crushers, the movers, and the pushers. Pushers attempt to push the player off the map. Crushers kill the player if they impact the spikes on one side of them, but act as pushers on the non-spike sides. Movers cause parts of the map to temporary move to a new location, either providing a risky jump or making the player pause to wait for them to return. The hazards are introduced in small doses to get the player used them to and hint at things to come.
Stage 3 ups the challenge by adding in sequences containing multiple hazards chained together as well as sections comprised of only hazards. The third stage challenges the player, but provides brief safe areas for the player to assess the situation before diving headlong into the unknown. The pushers can take up the entirety of a platform, so the player needs to either time their movement correctly, or find more risky ways of avoiding them. The theme of the third stage is timing, with the rows of crushers and platforms consisting of multiple movers, the player needs to learn the pattern of the hazards and then move through during the safe points presented in those patterns.
As my first proper foray in the Hammer Editor, I was not knowledgeable of all of the capabilities and shortcomings that come along with the editor. The primary point of contention came from trying to implement a camera system that would follow a rotating object. I tried various methods after scouring online sources and colleagues, but the only viable method was to use a series of triggers that the player would move through and move the camera along a fixed path that was set up prior. This made getting the camera looking just right very challenging, but ended up giving me a greater knowledge of the scripting capabilities of Hammer as a result.
The other unexpected outcome of the project was trying to use rollermines follow paths. This isn’t something they like to do as a rule, so they would just aimlessly follow the player without knowledge of the stage around them. This lead to them falling off the stage most of the time and not providing a sufficient challenge. I later replaced them with static objects that move in patterns to combat the player’s progress, which worked out well as it was easier to know exactly what they would do and they were more readily modifiable in the editor.
During the course of Gordon Madness I learned a lot about trying to create an interesting series of mini-games within the engine of another game and I hope to carry that knowledge forward in my pursuits within the industry proper.