XV-3 Landing Course Created for The Bob Bullock Texas State History Museum

W/S to switch aircraft modes. A/D to tilt aircraft. Mouse up/down to throttle. Space bar to pause/continue.



Flash, web-based, installation, kiosk


Flash SWF, AIR


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.


  • 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.


ActionScript 3.0



game, physics, flight-sim, side-scroller


Military tiltrotor aircraft pilot training



An aircraft must be maneuvered quickly through a training course to pass each round. It must land safely at its destination, so that all HUD indicators measure acceptable landing conditions. User can switch aircraft between airplane and helicopter flight modes. Airplane mode propels aircraft horizontally, making it cover more distance faster. Helicopter mode propels the aircraft along its vertical axis, providing means to land safely.


Altimeter, Altitude Indicator, Horizontal Speedometer, Timer, Throttle Indicator. Each of these devices measures a different set of properties about the aircraft, determining whether those properties are at acceptable levels for landing.


Project Source Code

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

Simplified Physics

Made using simple variables for velocity, friction, speed, etc, to emulate real physics. Getting these to look right was a very iterative process.


GUI is encapsulated and decoupled from Game so it can be swapped or detached. Objects like screens, dialog boxes and panels extend GUIComponent class to inherit common functionality like keyboard compatibility.

State Pattern Flight Modes

Helicopter and airplane flight modes are encapsulated as state objects, inheriting from a FlightMode base class.


The inheritance chain for Level objects looks like Sprite->CameraSpace->GameWorld->Level. These four levels of abstraction define:

  • Sprite - display properties
  • CameraSpace - display manipulation
  • GameWorld - game behavior
  • Level - level properties

The Flash authoring tool is used as a level editor. Each level is a library symbol linked to a class storing level-specific data.

HUD Indicators using Template Method

The HUD indicators exist as components on a HUD object. Each inherits from a base HUDComponent object. Each has a small set of conditions it reads from the player. Most importantly, Player is decoupled from these; they are strictly views.

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.

Greensock tweening platform

Used to animate airplane propeller transition animations.


Scoring is based on how quickly each level was completed. Completed level scores are aggregated and resolved to produce a final score at the game's end.


  • 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


  • Physics on Player could be abstracted into components.
  • Too much inheritance. I'd prefer to not be in the habit of doing things this way. During this project, I would create a new class for anything that needed to be displayed onscreen and add functionality to that class.
  • Premature optimization. Too much object reuse. I was aiming to reduce the creation of new things anywhere in the program for fear that Flash's garbage collector would cause lag hiccups during destruction.
  • I was experimenting with a pattern of my own where nearly every object has a reference to its creator, but I didn't realize the danger of circular references.
  • Overuse of observer pattern and dependency inversion principle. I was trying too hard to make things changeable and reusable. I mistakenly used unnecessary listeners that only complicated the design.
  • Too much striving to keep object count down. I was still under the impression that fewer classes would make things easier.



powerhouse-animation, team-project

Completion Date:



~3 months



1 environment artist, 1 UI artist


Fostered development of a new coder we hired. Our lead developer had announced his departure, so I stepped into his role towards the end of this project.



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 WWII Pilot Training. 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.


Construction went really smoothly. I wasn't trying too many new things. I was making small, incremental steps, checking everything along the way.


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 put together the instructions screen, mouse cursor guide, buttons, background arrangements, HUD lights and other small things.


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.


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.


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


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.


  • OOP principles
  • Physics