PORTFOLIO | RESUME | CONTACT
Project Airborn
The Pitch:
Airborn is a multiplayer dogfighting simulator inspired by a fiction and WW1.
The players roam the skies above a miniature version of earth dekorated with familiar, oversized monuments. The core of the game is fast-paced shooting action, different powerups can be picked up to change the tide of the battle.
Each player can choose the nationality of their pilot and wich aircraft to pilot. The pilot you choose determins what kind of special manuovers you can execute and the aircraft determins how fast, manouverable and resilient you are.
The battles are free-for-all deathmatches.

Plattform: PC over local network
Project resources:
Staff:
2 Designers
2 Programmers
5 3D Artist
None had any prior experience in making games, this would be our first attempt at making a game as a serious project.

Time:
5 weeks production, 1 week pre-production
Obstacles and how to overcome:
The biggest challenge was, of course, the fact that no one had ever made a game before. Not on this level anyway.
Everyone was in some way thrown into this project but once the inital confusion got sorted out things progressed quite smoothly. I noticed that once you admit to yourself that you don�t really know anything it is easier to start learning and searching information.
People quickly started to learn things with their own initative, maybe becuase we had a rather democratic organization within the group.

Another big obstacle was the programming of the network. None of our guys had done networking before and we were all a bit unsure of what to expect.
The networking problem got boiled down into a matter of necessity; what is nessesary for the server to recieve and send? What can be done locally on a klient and what must be sent?
Early on we decided to cut out the special manouver abilities of the pilots, partially because we didn�t know how to make it work with the network but also because it would annoy the hell out of players to have their control of the aircraft taken away from them during the actual manouver.

The feel of flight:
Another challange was how to make the player feel like they are sitting in the cockpit.
We had already decided that the game should be played with an XBOX 360 controller, keyboard and flightsims don�t mix.
With the left analog stick tied to pitch & yaw and the shoulder buttons tied to roll you could controll the aircraft quite easy but it felt very stiff or digital. The aircraft responded to quickly to commands and you could change your heading in the blink of an eye.
After implementing a certian inertia to the controls the flight-feel got a lot better. Every twist and turn with the aircraft needed to be first accelerated, when you pushed the stick, then deaccelerated after releasing it.
This meant that the player needed to take in to consideration the fact that the aircraft didn�t turn on a dime and changing the heading from up to down meant battling the inertia.

The next task was to make the players "roll-dive" more often.
The "roll-dive" is the cool manouver that the pilots in movies sometimes do; rolling their aircraft 90 while yawing straight up just to turn sideways.
This is because the rudders controlling the strenght of the yaw is much bigger than the ones controlling the pitch.
So to make the planes behave more realistic meant limiting the strength of the pitch, an easy change to make that gave huge changes in gameplay; players twisted and turned like never before!

Edges on a sphere:
Since combat took place around a globe rather than on a flat plane there would be no borders or edges of the map but the game would still need some boundries otherwise players would fly straight out in to infinite space.
To counter this we had different ideas but the one we settled with was the "frostbite-system".
This meant that at a certain distance above ground players would experience the cold stratosphere, at first the screen started to "freeze up" with snow and frost, limiting sight, and once frozen enough they started taking damage.
This made players fear the extreme hights but also gave them the tactical option of trying to shake off enemies by flying in to the cold zone. Enemies with low health stalking the player would think twice before following a loop up in space.

Balancing the craft:
The variables each craft would have was Health, Speed and manouverability. During tests we quickly discovered that a more manouverable craft, although low in health and speed, would win against any foe by simply outmanouvering them.
To counter this we had to make the machines more similar than we originally planned.
All the craft had their variables changed to become more "average", there was also a reduction to health for all craft since actually hitting your foe was harder than we thougt.
In the end all craft had an OK balance while maintaining their individuality.
Final results:
All models and graphic were finished on time and made the game.
All the important features made the cut, players could match their dogfighting skills with smooth controls.
They could choose their pilot and aircraft, since the special manouver feature had been cut the choise of pilot determined the apperance of the aircraft according to the nationality of the pilot.
The special weapons all made the game in the last minute: shield, double fire rate, health boost, airmines and cannonball.
These weapons could be used to mix up the battles.

What went right?
Freedom and personal responsibilitys in ones work functioned pretty well for the artists who kept on schedule through the whole project.
Open communication within the group helped keeping the direction of the project.
The game was completed on time! And without a too painful crunch!

What went wrong?
We may have had a too optimistic schedule for the programmers who were pretty much always working a bit too much. Probably due to network programming.
Special effects was forgotten in the planning! Got squeezed in last minute.

Lessons learnt:
Testing and balancing multiplayer games alone or even with 2 players is hard! It sounds obvious but its something that was forgotten in planning stages. Sometimes you just don�t have enough, non-busy, people to test with.
Keeping up to date with the programmers is vital.
Use the first weeks well while morale is still up and things haven�t become routine.
Use the last weeks well and burn that crunch-energy on the right things!
Multiplayer games seem to have their base fun-factor increased by x1.5 but network programming increases all the work by x1.5!

Copyright (c) Fredrik Alexandersson 2009 | fredrik.alexandersson@live.com