Here is a blog post written by one of the Afterland programmers, and current MIT and GAMBIT grad student, Mark Sullivan!

Here at GAMBIT, the members of a team each have a certain role. It might be one in production, quality assurance, game design, sound, art, or programming. The function of a programmer is one of a facilitator. The ideas and creations of all these disciplines are synthesized into a game by its coding team.

The programming team for Afterland consisted of three members. I, Mark Sullivan III, am a recent MIT graduate and GAMBIT veteran. Su Qin is a Computer Science student who has just graduated from Nanyang Technological University, Singapore. Last but not least, Melvyn Qwek who is doing his final year Nanyang Polytechnic, Singapore with a specialization in Games Programming.

While we all had prior experience developing games, none of us had done so in Flash before. The mood, however, was definitely one of excitement, and not intimidation. We were all very excited to learn the skills needed to develop for this very portable and accessible platform. Early on, at the recommendation of GAMBIT's technical director Andrew Grant, we decided to use Flixel as our game engine. We did not regret our decision; Flixel does a great job at establishing the basic game framework so that it's very easy to get a simple game up and running very fast. The tools Flixel provided were sufficient to accomplish nearly everything we wanted, and it was easy to patch in the things it did not.

For the first stretch of the project, we did not code at all. Our research objective specified a lofty concept, so the whole team participated in brainstorming before a more concrete specification of the game could be created. While a lot of the design was iterated upon and modified after this point, we had a starting point and could begin implementation. We implemented much of the framework which persisted for the duration of the project. We created a basic platformer with collection elements, and after that the game charged full speed ahead.

At this point, we were able to come up with a reasonable partitioning for the workload, one which persisted the entire summer. I was responsible for the game world - integrating designer levels and the art for the levels - as well as the collision detection and audio. Melvyn was charged with the user interface and heads up display, as well as the item collection. Su Qin took care of the player and non-player-character movement and behavior. While there was certainly some gray area and this was not a strict partitioning, we were able to develop in parallel quite well with this system, and the workload was evenly balanced among us.

One unintended feature of this partitioning was that it matched the artists' partitioning. Yoshi did the level art, Sophia did the character art, and Kelvin did the user interface. This ended up working quite well for us, each having a primary contact on the other discipline's team. There are several things we learned to fear from the art team, however. A high pitched voice accompanying flattering words without a doubt signaled the onset of some absurd feature request. "You're the best programmer ever! I'm sure it would be no trouble for you to..." A particular favorite was "Wow, what a great job on the ending scene! Although...wouldn't it be great if there was confetti as well?" That one lead to our game being stuck at 1 fps for a while. Or the completely urgent "NO! What happened? The items in the house are off by a couple pixels!" I can't pretend I can tell the difference, but perhaps that's why I'm not an artist. In any case, the bantering between the teams was done in good spirit.

The design pipeline was pretty smooth. We kept an up to date backlog with the features we planned to implement, so it was always easy to tell what the plan was. Additionally, we found Flan, a level editor designed for use with Flixel. While the editor was restrictive at times, and closed source so we couldn't modify it, it provided a lot of functionality which we would not have been able to match on a timeline like ours. It allowed our designer, Aaron, to create and test levels on his own, though we wound up fitting in things like the parallaxing backgrounds in code.

Sound integration also went pretty well. There were plenty of iterations on the way sound worked which required programmer intervention, such as certain crossfades and other transitions, but the sound designer, Iqbal, was given access to our sound manager, so that he could swap assets and adjust volume levels on his own. Due to some file size problems, we unfortunately cut a lot of audio in the end, but I feel we managed to tie together what we had quite well.

While most things worked out quite well, there was one thing in particular we could have done better. Our file size is much larger than it needs to be. A lot of the art is in bitmap when it could have been done with vector. This is not the fault of the artists, just a lack of foresight on all of our parts. We managed to save about 6 megabytes converting many of the parallaxing backgrounds to vector art (with blur - we cached them at runtime to prevent a huge performance hit). We could have avoided the need to redo some of the artwork had we anticipated this.

In the end, all of the parts converged to the whole, and we wound up with, what I believe, is a great game which accomplishes the research objective. If you haven't tried it, play it now!

-Mark Sullivan III