AIR
Ambition program
What I've worked on:
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.)
•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.
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.
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.
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!).
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:
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!).
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.
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.
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
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:
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)
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.