[In this GameCareerGuide-exclusive student postmortem, FIEA students discuss the creation of their ambitious Gamebryo engine-powered RTS, Bizarrecraft.]
In the Fall of 2007, I entered the Florida Interactive Entertainment Academy (FIEA), a 16-month Master of Science program at the University of Central Florida in Orlando. I came to achieve a goal I've had since I was five years old: to have a career in the video game industry. Like most of my generation with this aspiration, I was inspired after playing a video game and thinking, "I could do this better." It is this thought that drove my classmates and me to make the best games we could for every project we were assigned at FIEA.
During the second and third semester at FIEA, the students are combined to form large development teams in order to begin work on a large-scale game. These teams are made up of producers, artists, and programmers attending FIEA. The students work on these projects to gain personal experience of the challenges a developer faces while trying to produce a video game.
In January of 2008, 16 students at FIEA began their seven-month work on BizarreCraft , a real-time strategy game, with that one driving mentality in mind: we can do this better. Our overarching goal for BizarreCraft was to make a better real-time strategy game. We wanted to try and fix all the problems we saw in the genre.
Yes, it is okay for you to begin laughing. Once we sat down to begin planning the project, we laughed too. Although, as this postmortem will show, we may not have laughed hard enough, as we still tried to do too much to make this better RTS.
Over the course of its 7-month development, BizarreCraft went from being a Command & Conquer clone to a barely functional RTS to an experiment that barely resembled a game. In the end, BizarreCraft used it RTS roots to create a unique world where chimera-like monstrosities battle barely functioning junkyard robots in an attempt to capture their enemies' insane general.
This is the postmortem for BizarreCraft, wherein I will discuss what went right and what went wrong in the 7-month development of the game and what the phrase "We can do it better" does to video game development.
What Went Right
1. A Passionate Team
It might seem like this could go unsaid. I mean, we were making a video game. How could we not be passionate? But I believe the passion of this team was unique, so it deserves explicit recognition. It would be a lie to say the whole team was in love with this game throughout development. It would even be a lie to say the team was in love with the final product. So, how could a team who was not 100% behind the game be this amazingly passionate team?
Every member of the team found one aspect of the game latched onto. They then threw themselves into this area of the game with abandon. You could not forcefully pull people away from the systems, features, and assets they were passionate about. This passion made the project possible. At no point, did we manage to set the scope of BizarreCraft correctly, but thanks to the passion of this team, all developers put in the extra time to make sure BizarreCraft became the game we all hoped it would be.
The programmers deserve special recognition for their passion. In December, prior to the beginning of the development, the team had a five programmer technical team. Considering all the systems and features that are expected of an RTS, it should be obvious that 5 programmers working for seven months is going to be a tight schedule for getting a quality RTS put together from scratch.
Well, the team got a surprise right before development began. We were only going to have four programmers. The four programmers we had were some of the most impassioned developers I had a chance to work with at FIEA. They achieved things I would not have thought possible with only four programmers.
2. A Wall for the Programmers
On the topic of our amazing programmers, I should mention their wall. Well, it wasn't quite a wall, but it might've well have been. They had taken over an extremely long whiteboard in one of the classrooms at FIEA. No one but the programmers was allowed to touch the wall. What was on this wall? Well, before I explain that, I need to backtrack a little.
One of the first decisions we had to make regarding the scope of the project was which gameplay mode of an RTS we wanted to create: multiplayer or campaign. Both require a large technical hurdle. Campaign requires an AI system that allows the player to feel like he is actually competing against someone. It also requires the ability to allow designers to script events to push the narrative of the campaign forward. Multiplayer requires a robust networking framework for the game. It needs to keep the game in synch and prevent cheating. After weighing the options, we decided to go the multiplayer route.
The programmers immediately began studying on networking solutions and how that required data to be stored and code to be structured. After research was complete and a networking methodology was decided on, the programmers began work on organizing all the data that would be necessary for the game into categories.
They were trying to figure out what data need to be transmitted across the network and what data could be maintained locally. To accomplish this organization, the programmers used a whiteboard in one of FIEA's classrooms. All these small areas of the game were being planned out all across this whiteboard. Every data point had a place in this chart.
What made this great was that whenever one of the programmers was ready to move on to a new system, they could first reference this chart to see where the necessary data was coming from and where it was going to. It also aided in giving the programmers a roadmap for the game's codebase before ever touching a line of code.
This proved to be invaluable tool as the challenge of actually making the game work across a network began to become a larger challenge than anticipated. As such, having this plan for the game's data was one less headache that the programmers did not need to worry about.
One might ask, why, of all places, would something as important as this go on a whiteboard. It seems much less permanent than what should be expected. In the end, this became the most reliable location for this. It was in a central location where all the programmers could easily access it. As well, items could be added, removed, modified, and moved very easily.
Now, from this description it would seem like an electronic chart maintained on Perforce would be the better option. The problem with that would be the file would probably be marked as a binary file. As such, only one programmer could modify it at a time. With the whiteboard, the entire programming team could be editing the chart at the same time. In this way, no programmer was ever being held up because someone needed to check in a document on perforce. Or at least, they were never waiting for this information to be checked in to Perforce.
