Turbo - Game Details

Return to Planet Zolton 2048 (team Turbo) is an arcade-style 2D spaceship shooter. It was conceived in Intro To Video Game Design (600.256) during the spring semester 2009 at Johns Hopkins University, under the direction of Peter Froehlich. The goal of the course was to create a playable and enjoyable video game. Teams in the course consisted of four members: two people to work on coding the game, and two people to work on art/sound/design. Our team consisted of myself (Jeff Orthober), Alex Heinz, Sam Messing, and Charles Chin.

Jeff Orthober - Level editor
Alex Heinz - Game engine, game logic, menu interface
Sam Messing - Sound, music, art
Charles Chin - Art, level design

The game and the level editor were coded in c using the SDL graphics libraries. Graphics are rendered in 32 bit, but the artwork is scaled to look 16 bit (we went for the retro art style). We game could ran on Windows, Mac, and Unix platforms.

Game Play:
Player controls a ship flying through levels, shooting enemy ships, and collecting powerups. Powerups include boost in ship health and upgrades for ship weapons. The level scrolls vertically at a fixed rate. Player is able to move the ship anywhere on the screen. Some objects in the level act as obstacles and block the forward movement of the player ship. Enemies move in the opposing direction, firing and moving to set patterns.

At the end of each level there is an intersection. When approaching the intersection the player has a choice of which direction to take (turn left, turn right, go straight). Different directions through an intersection lead to different levels. This was our main feature.

Level Design:
Behind the scenes levels and intersections are stored in text format files. Levels are tile based, with each level using different tilesets. Each level has an associated intersection. Each intersection has up to three levels associated with it. The Levels are composed of 4 layers.
  • Background layer - Tiles comprising of the background of the level. The background layer tiles are mapped to a tileset.
  • Foreground layer - Tiles in the foreground layer overlap tiles on the background layer. Foreground tiles have a color-keyed transparency. Mainly used to place items of scenery (trees, buildings, etc. ) without having the artists render a tile for each item on all possible backgrounds. Foreground tiles are mapped to a tileset.
  • Tangible Layer - Tiles of the level that block the forward movement of the player ship. The player must fly around these obstacles. Tangible tiles are only visible in the level editor.
  • Sprite Layer - Enemy ships and other sprites. Sprites are given a starting location, and once the player ship is in range, the sprites move and shot to a set pattern.
Intersections are only composed of the background and foreground layers.

Level Editor:
Early on in the project it became clear that a level editor was needed so that our level designer could easily make levels. The term map refers to either a level (a straight stretch of verticle scrolling) or an intersection (only serve to transition between levels). The level editor could:
  • Load/save/create maps
  • Edit map properties including the size (length) of a map and the associated tilesets
  • Edit the tiles on the background, foreground, and tangible layers.
  • Edit the sprites on the sprite layer
  • Edit sprites' movement pattern
What began as a small side-task, the creation of the level editor ended up taking a significant amount of time to design and implement properly. I had to create GUI interface controls such as buttons, labels and message boxes from scratch. I had to insure that map files were being generated properly. I had to design an interface which displayed all required information and allowed all properties to be edited. In the end the level editor, though it did provide our level designers with the basic tools to create maps, was difficult to use, buggy, and inefficient.

My goal is to revisit the level editor and rework it to become a more useful tool.
  • Change the interface and controls to be more intuitive.
  • Use screen real-estate more efficient.y
  • Add functionality to speed the map editing process
  • Add functionality to allow more properties of a map to be edited
  • Fix bugs

This spring 2010 semester, I will work with an independent study with Peter Froehlich to reach these goals.