The development team
As you might recall from some of my posts in the forums, Buzz Aldrin’s Space Program Manager was born as a personal project back in January 2007 while I was still studying at university in my native Argentina (actually, the “Buzz Aldrin’s” bit in the title came nearly six years later!). The development went through several phases, which I’ll surely discuss in more detail in another article in the near future, but the bottom line is that nowadays Buzz Aldrin’s Space Program Manager is being developed by a very small number of developers across three different countries. The current development roles are:
● 3D modelling and texturing: This area is being covered by Mauricio, who lives in Buenos Aires, Argentina. Mauricio and I met three years ago when I was working at a private university as a teaching assistant and he was working as a computer lab operator. He joined SPM in June 2011, a few months before I emigrated to the UK, and since then he’s been devoting most of his evenings and weekends to the project. All the 3D models and renders you see in the game have been made by him.
● UI and 2D graphics: This area is being covered by Boris, who lives in Vancouver, Canada. Boris joined us only a few months ago and he helped us tremendously by redesigning the user interface and developing the space complex, which has already been covered in a previous article. Boris is also getting a helping hand from his wife Jacqueline, who’s helping with certain aspects of the UI and created the 100+ badges featured in part 1, and his brother Vlad.
● Music and sound effects: This area is being handled by Christian who, like Mauricio, also lives in Buenos Aires, Argentina. I met him five years ago, when I was looking for an artist to provide music and sound effects for Flip Disc, my first commercial game. I was really pleased with the work he did on that project, so calling him again to work on SPM was a no-brainer. Christian is being assisted by Demian, who also lives in Buenos Aires.
● Programming, game design, information research and team management: The remaining areas of the development process fall under my responsability. It’s a really interesting experience, as I enjoy writing code, reading about space and keeping the whole vision for the game. Plus, I get the opportuniy to meet Buzz from time to time and have extensive chats with him about space systems. Buzz is an extremely educated and smart person with really strong ideas on how space exploration should be done, so to me listening to what he has to say is really enjoyable. Lots of improvements have made it through the game based on the outcome of our conversations.
The mission animations
The mission animations are dynamic sequences that get shown in a ‘Mission Control’-style console (figure 1) and depict the sequence of events featured by a particular mission. My original idea was to show a sequence of static pictures for every mission using a set of background musics and sound effects, but a few months ago we decided to take things one step further and show full animations instead.

The Mission Control console.
Unfortunately, creating the animations as AVI or MP4 videos and playing them back inside the game is not an option, as the final application size would be huge and we wouldn’t be able to deploy it on mobile devices. So we devised a solution where we basically extract the renders into different parts or ‘layers’ (figure 2) and animate them independently on the screen by creating an XML file with a series of ‘operations’ that need to be performed on them, such as rotation, translation, scaling, etc (figure 3). We have also developed an internal tool in order to visualize the animations and tweak them without having to run the full game in order to see the resuls.

An image broken in layers.

An animations XML file.
Creating the mission animations
The process for creating the mission animations involves several steps and, as mentioned before, all the team members contribute to it. The procedure comprises the following steps:
Information research: This step began back in 2007, when I started putting the tech tree together. In order to do that, I got information from several online sources, such as ‘Encyclopedia Astronautica’ (http://www.astronautix.com/), NASA’s webpage (http://www.nasa.gov), PDF documents uploaded by Bob Andrepont (which can now be found at http://www.scribd.com/bandrepont) and wikipedia. Also, once I moved to the UK I was able to buy lots of magazines, documentaries, books and movies (figure 4), which helped me improve my knowledge on the subject quite significantly.

Some of the DVDs I bought during the past two years.
3D models: Once the layout for the tech tree and the list of missions available throughout the game were in place, in late 2007 I started writing the list of 3D models that were going to be needed. Originally, some of those models were made by external contractors. Then the scope of the project started to grow, so I started to look for development partners instead, and that’s when I teamed up with Mauricio.
Renders descriptions: When the list of 3D models reached a stable state, I started working on a very extensive document where, for each mission, I provide some background information for Mauricio along with a detailed list of the images we need. The document also includes links to online resources that he uses as a reference point. Animated references examples includes TV news clips from the 1960s, fan-made videos using the Orbiter space simulator and high-quality animations made by NASA itself. For those missions where I cannot find appropriate animations, I usually provide links to diagrams from NASA’s press kit or other documents so that Mauricio has some sort of reference (figure 5). This step is obviously a work in progress, as there are some missions for parts 2 and 3 of the game that still need to be defined.

Documents and press kits.
Renders development: With the infomation from the previous step, Mauricio composes a scene for each image by placing the 3D models in his modelling tool and adjusting the scene properties accordingly. He also adds some special effects (e.g., smoke, flames, etc) using an image editor. The output of this step is a set of renders stored in PSD files (figure 6). We estimate that the final game will feature approximately two thousand renders, so there’s a lot of work involved in the 3D department! Although he keeps telling me that he’s doing all the 3D models and renders on his own, I think he secretly has a room of monkeys with 3D modelling skills working for him...

One of our custom 3D renders.
Animations descriptions: Based on the output from the previous step, I maintain yet another document where I detail a list of mission steps for each mission (e.g., countdown, launch, orbit insertion, etc) and the renders that need to be used for each one of them. Notice that some renders are used across several missions. For example, for the Gemini program, Mauricio did a set of renders for all possible mission steps (e.g., EVA, docking, rendezvous with an Agena Target Vehicle, etc) and in the document I specify how those renders should be used depending on the mission configuration.
Initial preparations for the animations: Remember the PSD files that Mauricio created? In order to make the animations, Jacqueline and Boris carefully go through all the PSD files, extract the different layers and place them in separate files, so that they can be animated independently. They also do this because some of the PSD files make use common layers (e.g., background planets) and, since SPM features so many missions, we want to keep the final application size as small as possible. Ideally, this step wouldn’t have been necessary if we had decided to do animations from the start, since Mauricio would have provided the assets in separate layers. Another lesson learned that we’ll surely apply on parts 2 and 3!

Animations development (visual part): With the different layers in place, Boris and Vlad then produces the actual animations using the After Effects tool (figure 7). By using this tool, they are able to create the animations using a visual tool and fine-tune them until we’re happy with the results.

The ‘After Effects’ tool.
Conversion tool: Once we’re happy with the animations in After Effects, Vlad painstakingly extracts the relevant information from the software and places it on a spreadsheet. The spreadsheet is then fed into another program which grabs that data and outputs the XML file using a format that can be understood by our game. The text file is then fed into our custom visualization tool (figure


The custom visualization tool.
Audio development: The last step involves Christian grabbing the text file with all the visual operations and adding a few more instructions in order to playback the appropriate sound effects and background music. By using the same tool used in the previous step, he can get instant feedback on his work and see what the final animation is going to look like. Then he keeps tweaking the XML script until we’re all happy with the results. All the background music is original and the sound effects are a mixture of assets created by him and others extracted from NASA’s footage.
Checking: Once everything is in place, I check that the animations are correct using the internal tool, raising comments to the rest of the guys when things need to be fixed. The next video shows a docking mission, which features the launch of an Agena Target Vehicle followed by the launch of a Gemini spacecraft. This is the quality you’ll see during the Early Access Program, we’ll do another polishing pass before the final release adding even more sound effects.
Here you can watch a demonstration video of the tool
With all these mission animations we are expecting that you, the players, will get a reward after all the effort you put into the game by spending funds on R&D, managing the agency’s personnel and scheduling a mission. As a nice bonus, you will also get a complete overview of the steps involved in the launch, deployment and operations of a space mission. We hope you enjoy them once the game gets released!