AIR Ambition program

What I've worked on:

•Ten multiplayer missions
•Two singleplayer (training) missions
•Three aircraft
•Six panel gauges
•Management of over 20 artists and developers
•Procedure and tools documentation
•Configuration macros
•Integration of P3D software with on-site hardware
•In-session management
•End user training
•Post-deployment support (patches, etc.)

This project represents the lion's share of my time investment for my first year at TEQGames. I started working on this when I was brought in as an intern for TEQGames and saw it develop through many different conceptual iterations, but one of the first things I started working on and easily the most ambitious single piece of this project - one that persisted as a feature through every iteration - was the notion of a "transforming" aircraft.

The first "winning" concept
Originally, the goal was to design an aircraft that could handle three distinct modes of operation - air, land, and sea. We spent a lot of time in this concept phase (concepting from strictly a visual point of view) before we learned that it was outside the scope of the planned engine to have an aircraft that also functioned as a submersible (the engine in question is Prepar3D, a Lockheed-Martin licensed version of Microsoft's ESP engine). We could look around underwater, but for the vehicle to act as an aircraft, it couldn't travel underwater.

The same concept, adapted for the first prototype
Rather than completely going back to the drawing board, we used some of the less-submersible-like transformer designs and adapted an early version for a playable prototype. This prototype was a short obstacle course that led the aircraft through its various capabilities - floating on water, short-takeoffs-and-landings, and high speed travel. What we took away from this test was that it would be best to get rid of the driving/boating aspect of the plane entirely and instead focus on what aircraft are used for - flying.

Second "winning" concept

This led to a complete visual redesign of the aircraft. We went through several base designs until we eventually decided on a design I'd put together as a blended-wing combination of an F-35 and a B-2. There were a few prerequisites given for this design - it had to be able to hover based on deflected thrust and it needed to have a set of landing gear that would allow it to land anywhere - and these eventually bore themselves out as a set of tracked gear and a set of folding wings (it was to my great chagrin to see a very similar design in the Avengers movie six months later!).

Final aircraft design
After the artist assigned to work on this (the very capable Nick Collins, to whom I am indebted for his patience on this project!) finished the model, I was responsible for integrating it with the engine. This is a simple process that I usually go through for every aircraft I bring into the flight simulator environment, one that involves bringing the model into Gmax (the stepbrother of 3DSMax), assigning any flight-simulator-specific attributes (material flags, special collision, etc.), and setting up animations. Usually animations are fairly simple (often just control surfaces and landing gear), but in this case they took extra work - I had to write specific cases for animations and then design them to be hooked on to by events in the gauges.

Which brings me to the big part - the gauges. There aren't a lot of avenues to get my (script) hooks into the flight simulator environment, but gauges represented what was easily the most flexible one. I learned early on that if this program were going to meet some of its lofty goals, that the features those goals required would have to come through more than the basic features offered by the SDK. The scripts I was able to piggyback into the game via gauges were my means to adding those features. These features included:

1) Animation state control
This aircraft operated in what were essentially two "modes" - hover mode and airplane mode. Hover mode acted like a helicopter, and it used some different animations than the aircraft used when in normal flight. Aircraft in this engine can usually only have one set of animations for one thing, so to get around this limitation, I assigned the extra animations to be switched on by dummy conditions - placeholders set through the gauge.

As long as control for the aircraft rested solely with what was presented on the gauge (and it did, thankfully this was a tightly-controlled ecosystem), I could be 100% sure that my gauge represented the sum total of what was going on with the aircraft.
2) Droppable objects in multiplayer
One of the quirks of developing in this flight simulator is that, while available in the singleplayer version of the game, droppable objects (ordnance, weapons, etc.) were not available in multiplayer. This was nearly a "must-have" feature of this program, so I had to work it in somehow.

Like the above, I knew that as long as my features could exist solely within the context of the player's UI they'd be fairly easy to control. The problem here was that, for the same reason droppable objects were so necessary (they represent a means to interact with the game world), droppable objects must not exist solely on the gauge. They had to exist in some manner in the mission, otherwise I couldn't demonstrate their effects to every player.

What I did here was a combination of simulating ordnance and simply deceiving the player about what was going on. To make my aircraft interact with the environment without having any true dummy conditions to test in the mission, I set the gauge to fire off a bunch of disparate conditions in a combination that was unlikely to take place when they were being used (e.g. wheels down, tailhook down, cockpit open, etc.) and then asked the mission to test for these conditions happening all at once. Because these conditions were all tied to animations acting on a delay, I could save the previous state, set the conditions, and then set them back before the user ever saw these actually happen to the aircraft.

3) Mid-air refueling
"Target" gauge, used for refueling
This was a really fun feature to create, as it was a fully-working feature that acted almost exactly as it appeared (instead of just being a patchwork solution) just by virtue of what the gauge script controlled. I was able to use several of the built-in components of gauges designed for airport towers (instead of airplanes) and graft them in to an airplane gauge, which allowed me to test for relative proximity of two airplanes.

Because I could, more or less, test for the "class" of aircraft, I could verify that the aircraft I made as the refueling airplane was the one that had to be proximal to the player's aircraft (and then made fuel increase a function of the player staying a certain distance away from the aircraft).

What was really fun about this feature was the UI I got to make for it. I tapped in to designs used in the space combat genre for targeting computers and built a gauge around that. The goal was to provide something that would:

a) Let the player have some means of tracking relative proximity to set up for the requirements of the refueling procedure, and
b) Create something extensible enough to serve other purposes (like formation flying), or even serve potential future features (like air-to-air combat, which isn't a feature we were asked to develop)

There were several other incidental gauges I got to make to meet minor feature requirements, each of which were also a lot of fun. I got to build a calculator as a fully-UI element, a moving map display with taggable waypoints, and a gauge designed to set the player up for aircraft carrier landings. The calculator was as easy to script here as it would have been to script anywhere else (all I really needed was the ability to display variable data, which is core to the gauge system anyway) and the moving map display was built around the structures designed to support GPS in the game.

The carrier landing gauge was slightly more of a challenge, but again the controlled ecosystem came to my rescue - because I knew exactly where the carrier would be at any point during the mission(s), I could extend on the variable data I was able to receive from the points of interest that defined the carrier (I was already getting position and altitude) based on the name of the variable - because I had a limited set of variable names that were to be meaningful, I simply predefined an image that represented the orientation of each carrier deck to provide the player with a full top-down view of the landing theater.

The final piece that I was able to contribute with regard to the airplane was the "user's manual." For me, documentation is a ton of fun to write - it's like the icing on the "finishing a project" cake. I actually created user's manuals for all the aircraft for this project, although the manual for the transforming aircraft was the most in-depth, and consequently, the most interesting.