The Breaka Jetski Game Engine Explained
(written for Cru Digital)

Games are a powerful medium. While a film can only provide a few hours of entertainment to a group of people, a game can provide potentially limitless entertainment to a potentially limitless audience through the lure and viral spread of social competition. When Breaka commissioned us to create a microsite, we put a game front and centre. A good game needs a great idea, a tonne of play-testing, ten tonnes of optimisation and a solid framework. In this article I’m going to introduce you some of the processes involved in creating the Breaka Island Jetski Challenge.

The First Step In Creating A Jetski Game Is Creating The Jetski

The Jetski Challenge was born as a playable proof of concept, the demo. The demo featured a jetski driving around an infinite spread of water. During this initial phase of development, the most important aspect was making the Jetski look, feel and control like a real jetski, through real water.

Jetskis tilt, roll and flip. With this observation we knew immediately that the jetski had to be represented in three dimensional space (3D). Early tests showed that placing entire 3D worlds in Flash put a heavy burden on even the most powerful computer processors so we had to find a way to respresent the game’s world in something other than 3D. To achieve the look of 3D whilst maintaining the computing performance of 2D, we decided to place the Jetski in a small 3D box and place that 3D box inside a top-down 2D environment. This gave the game its bird-eye-view aesthetic. To render the 3D we used Flash 3D framework Papervision3D. To host it, and eveything else arround it, we wrote our own 2D framework – which would later become the game’s engine. With rendering sorted, we moved onto control and physics.

Jetskis drift, glide, carve and jump. The next step was to give this control to the player and have it reflected in a realistic way. As the jetski speed up we tilted the 3D model’s hull back. As the jetski turned left or right we tilted the model’s hull left or right to imitate lean. We forced the control to lag to give the illusion that the jetski had ability to generate momentum in the water. We zoomed in on the model whenever the jetski jumped and moved a shadow up and left to create the illusion of height. We placed a spray particle generation system at the base of the jetski to imitate the wake. Once each of these techniques were combined into the demo, we had a pretty sweet drivable jetski on our hands.

The Second Step In Creating A Jetski Game Is Creating The Game

While burning around an infinite pond with a turbo-charged jetski may be fun for the developers in the Flash Department, it may not be enough to win over the discerning player. The game needed an angle – a world to drive through and a challenge.

To create the world we crafted a tool. The tool was similar in functionality to the Breaka Island Flag Designer and allowed us to drag and drop checkpoints, obstacles, bonus items, sand banks and trees, amongst other elements, into the game world. With the tool we created three separate tracks: one focused on speed, one focused on stunts and one focused on survival. The aim of the speed track was to design the track with a clear driving line in mind. The aim of the stunt track was to place enough jumps to give the player ample air-time to perform stunts within. The aim of the survival track was to pump the world with enough obstacles to make it hard for the player to navigate.

With each track we crafted a matching game mode. The speed track was given a game mode that recorded the player’s time for three laps. The winning player would have the fastest time around the track. The stunt track was given a mode with a set amount of time. The winning player would be the player that could obtain the highest score from successful stunts. The survival track was given health and a small countdown timer. A player would slowly accumulate score based on the time the survived, dying if they lost all health. Each checkpoint would award them a time bonus allowing them to play for longer. The winning player would be the player that had survived the longest.

With these tracks and modes we built an engine.

The Biggest Step In Creating Any Game Is Creating An Engine

Game engine development is not for the feint of heart. The process can take weeks for even a small game and the only time it works is when its finished. Rather than babble about the process we went through to develop the engine, I thought I’d instead list the technologies we used and developed. A forewarning: This is some technology enthusiast stuff – if the terms ‘byte data’, ‘input events’ and ‘z-indexing’ don’t mean anything to you, you may want to skip this bit.

Input Management
While AS3 has improved control where Keyboard Input is concerned, AS2 was easier to use. An input manager was created to keep track of which keys were pressed and which actions they corresponded to. The net benefit of creating our own input manager is that it allowed multiple key inputs to register as pressed, overriding the caveat of the operating system level key repeating.

Map, Entity, Obstacle Management
A map able to load and house the tracks created in the world designing tool. The map contained the ability to house entities and was in charge of testing collisions, running the game loop and culling off-screen objects. The map also had the ability to draw the water texture according to position co-ordinates, giving the illusion that the water was infinite in all directions and a cool script which turned any vector shape into a sandbank with feathered edges. As all of the games entities and obstacles are contained with the map, the majority of the distance and angle calculation, collisions, depth swapping and camera movement are be handled by it or delegated to it.

Sound Management
To house the rocking soundtrack, sound effects and engine noises, a multi-track sound manager was created. The sound manager allows sounds to be grouped into tracks in a similar fashion to that found in DAW software. The sound manager could loop sounds, play multiple sounds, maintaining track volume or sound volume control.

3D Rendering
To render the jetski we used the popular Papervision3D libraries. PV3D is an invaluable tool for 3D in flash, maintained by the Flash Community. Those interested should also take a look at Away3D, which we used for the rest of the Breaka Island website.

Asset Management, Zip Compression
To store the game’s assets we used the NoChump Zip Compression Library. This allowed the games assets to be of minimal file size and embedded directly into the SWF file. The zip data was managed by a custom asset management library.

Game Over, Man, Game Over

All of these elements tied together with some Cru magic are a part of what allowed the game to come to life. Make sure you have a play through of the end product on breakaisland.com.au. See if you beat the high score.