Doug Macdonald

FossaNova

This game was developed in C++. As the team’s producer, I was responsible for writing weekly reports regarding the status of the game and managing the tasks of my teammates. I wrote the code for the game’s physics engine and the game logic for interacting with different block types, as well as preliminary input and camera code.

---

In the summer of 2008, a few friends and I formed  a team and began working on our Junior game project. Over the course of the summer, we would meet for several hours a day, four days a week, to plan its design. We brainstormed a RTS designed specifically to be simultaneously competitive and accessible, set amongst a battle across a computer network between viruses, antivirus programs, and trojan horses. By questioning certain things commonly accepted as integral to the RTS genre (such as resource gathering and skill-tree layouts), we were on track to develop a game unlike any currently existing. Design documents were written, flow charts were constructed, paper prototypes were made and balanced.

This game never left pre-production. By the end of the summer, two of the team members had each failed a prerequisite class for the game project course; without half the team, myself and the other remaining teammate were left to find new teams to work with in the coming year.

I joined up with two classmates who I didn’t really know personally, but did remember being impressed with the game they worked on the previous year. We soon added two more members — a ‘Super Junior’ who had already completed some of DigiPen’s higher graphics programming classes, and an artist who was previously working with me on the aforementioned RTS project. Together we began planning a 3D platforming game.

Spirits started off rather high as everyone was quite excited about the project. Following my initial joking suggestion that we make the player character an animal few people have ever heard of, the fossa, we composed the story of an evil sorcerer trapped in the form of such an animal who must navigate a series of platforming challenges to undo the spell and resume his plot of world destruction. We had a mission to essentially imagine a world without Super Mario 64 and eliminate the free-roaming, combat-oriented, mission-based gameplay found in so many 3D platformers, instead returning to the straight forward “get from point A to point B” gameplay that was so successful in 2D games. With a unique concept and design limited only by the number of environment-hazards we could invent, we began work on FossaNova.

In time, though, things began to fall apart. I discovered, shortly before our first major milestone, that the team’s graphics programmer knew just enough about his area to let us perceive that things were progressing swimmingly; however, when I finally insisted on a demonstration, I realized that things were lagging behind much farther than he had let us know. In an attempt to meet the milestone, I moved our tools programmer and designer to graphics, placing him in a position where he was inexperienced, but willing to learn. For my own part, I learned that programming physics for a 3D action game was a lot more complicated than I expected.

At the end of the fall semester, we turned in our first deliverable prototype. Working long into the night the day before, we were able to deliver a simple platforming challenge, tasking the player with jumping across a series of planar, randomly generated blocks made of either stone or ice. At this point, several components of the game were behind schedule, but we had something that was playable and actually pretty fun. By this point in development, we had realized that we could only assign the original graphics programmer tasks that would not block other team members when they were completed late; and when the new semester began, he left our team for another. On the art side, our artist had recruited a fellow student to animate our player character. Reorganizing tasks to suit our new team, we began the second half of the development cycle.

The major problem we faced second semester was caused by animation: as our school had never instructed its art students how to properly prepare art assets to be placed in a game, and never instructed us programmers how to properly integrate them, using the animations created by our art team became a task that stretched several months and consultations with numerous students and professors. Rapid changes in the graphics code caused problems with my physics engine as well; there were multiple occasions where previous code written under the assumption that certain factors about the existing graphics would remain true would be suddenly broken when the graphics engine entered a new iteration.

These difficulties led to progress slowing at times during the development, which in turn caused team motivation to take a rather big hit. In this semester, I found my responsiblities as the team’s producer extending from assigning tasks and managing productivity to also include trying to keep the other teammates caring about the game and excited about the final product. Differing work styles came into play here, too: While I preferred to work constantly on my assigned tasks, my fellow programmers lived for the crunch, performing the majority of their tasks for each milestone in the few days before it was due. This, of course, had its drawbacks: every milestone, I would awaken a few hours before the presentation and review the build found to be flawless by my sleep-deprived teammates, and frantically try to fix the crashing errors I would inevitably find.

In the end,  we managed to pull together a complete — though short — game. Physics were more basic than we had hoped, but worked; there was less variety in block types than we had wanted, but the ones that existed were fun to use; graphics lacked the sort of visual flair we had hoped to express our environments, but communicated the game world effectively. The final product was not nearly as polished as my previous project, and the whole development cycle was much rougher than the previous year, but in the end, I was happy with the course things had taken. I know for a fact that game development is rarely smooth and predictable, and FossaNova allowed me to experience many of the ways that things can go wrong first-hand, while in an environment where failing to deliver a milestone in full has significantly less consequences than the ‘real world’. This whole project was a year-long exercise in damage control, and the fact that we emerged from it with a completed game, despite everything that threatened to destroy the game, makes me prouder than a project completed without any difficulties could.