WWII Pilot Training Created for The Bob Bullock Texas State History Museum

W/A/S/D to navigate. Mouse up/down to throttle. 1/2/3 to toggle quality. Space bar to pause/continue.

Form

CLASSIFICATION //

Flash, web-based, installation, kiosk

Format:

Flash SWF, AIR

Deployment:

Run on dedicated Windows computer encased within custom-built arcade cabinetry. Custom controls were installed to simulate varying gameplay mechanics between each computer's assigned game. Hosted at The Bob Bullock Texas State History Museum, as part of the Tango Alpha Charlie: Texas Aviation Celebration exhibit. Computers run all day in kiosk mode, except automated daily startup/shutdown.

Components:

  • Restarter.exe - AIR kiosk shell I created to lock the user out of the OS while the game is running and load the game automatically at computer start-up
  • game.swf
  • Total Game Control - Game controller input mapping software to generate Flash-compatible keyboard/mouse events.

Language:

ActionScript 3.0

Size:

~16MB

Function

CLASSIFICATION //

game, 3D, flight-sim

Theme:

Military AT-6 airplane pilot training. An instructor guides the player through an obstacle course of rings. The player must take off the runway, fly through all the rings, avoid obstructions and land on the landing strip at the end of the level.

Behavior:

HUD

Altimeter, Altitude Indicator, Horizontal Speedometer, Timer, Throttle Indicator. These aren't an integral part of the game, but strengthen realism of the simulation.

Controls

Mouse Y coordinate controls thrust to simulate an aircraft throttle. Museum technicians built a custom piece of hardware around a mouse to more closely resemble a real throttle.

Mechanics:

Project Source Code

79 classes were created for this project, broken down into 14 packages. Top-level packages: "ui", "game", "shell" and "audio".

Papervision3D 2.1.932

ActionScript library for simulating 3D environments. Used as backbone of game's physics and rendering. This was the most popular library for 3D scenes at the time, before Flash had direct access to graphics processors.

MP3Pitch class by André Michelle

Used for jet engine sound that changes pitch with thrust. I modified this to work with MP3s embedded by the Flash authoring tool.

Level editor with custom components

Levels are drawn into the 3D Papervision world from top-down 2D maps drawn within the Flash authoring tool, turning Flash into a very easy-to-use level editor. Custom components were created for different level elements like buildings, rings, runways, and collision boxes. The 3D objects generated from these elements map their 2D x and y dimensions to their 3D z and x axes, respectively. 3D height (along the y axis) is specified by component properties. Other component properties include:

  • buildingType - what skin is used on object
  • collisionEvent - what event gets triggered when a collision occurs with player. Used to create un-rendered "trigger" objects that exist only to signal game-changing conditions based on the player's position.

ShadowCaster by EverydayFlash

Utility class used to project ray-casted shadow of airplane model to the ground surface.

Decoupled GUI

GUI layer is encapsulated and decoupled from game layer code so it can be swapped or detached.

Requirements:

  • Easy for anyone to play, including very young and old people
  • Maintain educational value by providing aviation-specific facts
  • Some degree of realism in plane behavior and appearance
  • As part of a museum exhibit, historical accuracy was very important

Creation

CLASSIFICATION //

powerhouse-animation, team-project

Completion Date:

2010-08

Duration:

~3 months

Collaborators:

1 3D modeler, 1 environment artist, 1 UI artist

Process:

Job

This was 1 of 5 games our studio, Powerhouse Animation, created for the Tango Alpha Charlie: Texas Aviation Celebration exhibit. I was assigned to develop this game along with XV-3 Landing Course. Our other resident coder tackled two other games. We hired a third programmer during the project's lifespan. He was tasked with the other game.

Production

Our client gave us creative freedom over the game's design. Myself, one of the environment artists, and the other programmer we had on board sat down to write the initial game design documents. I was given authority over what was done on the game before handing it off to the client. From artwork approval to programming decisions, I was guiding the standard of quality and making sure client needs were met. I was responsible for gathering all art assets from the artists and oversaw production. Lead transition of our team as the former supervisor was leaving at the end of the project.

Artwork, Sound

I did all the sound by selecting music and effects from a library of purchased stock material, using sound editing software to tidy things up. When adding the artwork, there's always a bit of artistic touch that needs to go into making everything work at the correct size, removing repeating shapes, optimizing vector art, rearranging text and components that won't fit together onscreen, aligning objects to a common center, deleting things that just won't work, etc. I created some of the artwork, myself, and delegated things to people around the office. I created the instructions screen, mouse cursor guide, buttons, background arrangements, HUD lights, etc.

Controls

The client gave us freedom to decide on what kinds of input devices would be used. I lead discussions with their technician to make sure our decisions weren't too costly or outlandish. Then I wrote out specs on how the controls should work and made suggestions on how they should look.

Deployment

I was the primary technical contact between our studio and the museum. Our development team installed and tested the games on the destination PCs purchased to house the games in the museum. A week before the exhibit's private showing, we all went down there and got the machines situated. There were some unexpected hardware incompatibilities, but nothing too surprising. After the exhibit's debut, we uncovered a slew of bugs that caused us to make several trips back to the museum to update and test the software. This process took considerably longer than we anticipated due mainly to the need for an OS-lockout mechanism, which I eventually made.

Tools:

FlashDevelop, Adobe Flash Professional CS4, Adobe Photoshop CS2, Sony Sound Forge 8.0, Adobe Audition 3.0

Challenges:

Kiosk mode

Locking users out of the OS was a real problem. I once walked into the museum to make some updates and found a group of kids huddled around Fuel Mileage, our touchscreen-controlled game, playing solitaire. I solved these problems by creating Restarter to run these games safely on a Windows PC.

Airplane physics

There was a lot of tweaking that went on here. Took longer than anticipated.

3D graphics

When writing the flight simulation aspect of the game, I tried several different strategies before settling on Papervision3D. For the first attempt, I created a navigable 3D space using a few pseudo-3D functions I found, but the difficulty I had rotating the ground plane properly lead me to give ActionScript's new Matrix3D class a try. All my variations of the game using Matrix3D came close to accurate, but insufficient documentation on the class, and a very meek knowledge of 3D coordinate spaces prevented me from achieving our goals in a timely manner. I finally adopted Papervision3D and decided to stick with it through the long haul, since I had seen some promising prototypes that other people had made online. I was staying away from using a proper ActionScript 3D engine because I felt an engine might be too much overhead in regards to performance overhead as well as the development learning curve. We only needed a few simple 3D elements for the game to accomplish what it needed. Papervision was ultimately functional, but disappointing due to the rendering load it puts on the CPU.

Papervision3D Performance

I played with all kinds of graphics variations to get optimal performance with this engine. Biggest hurdles in achieving reasonable performance:

  • Developing for a resolution of 1280 x 720
  • Needed detailed airplane model to maintain historical relevance for museum
  • Needed a large, open world
  • Needed increased subdivisions on ground planes since they are viewed up-close and Papervision3D has a strange quirk of warping textures on objects with a low poly count.

Research:

  • Papervision 3D
  • Matrix3D
  • 3D coordinate space translation and rotation