Hardened by Fire: The Trials of Producing a Student Capstone Game
[10.22.13] - Benjamin Roye
[The Guildhall at Southern Methodist University student Benjamin Roye details his experience producing the student-led project Full Steam Fury during its vertical slice sprint.]
Full Steam Fury (working title) is a third-person, over-the-shoulder, fast-paced robot combat against many enemies game. It plays something like Dynasty Warriors and looks like a steampunk-inspired, militarized dystopia. However, Full Steam Fury wasn't always the game I just described. In fact, it used to be quite a bit different.
I came onto the project as the game's Producer right after the team's Proof of Concept Gameplay milestone. The "POCG" was their second major milestone, following Proof of Concept Technology, which was their first. I was told going into the project that there were major issues with the project, but that the team was very talented, and if they were better organized, could make a spectacular student game. I will list the more potent issues I was made aware of going into the project:
The team had a lack of vision. This permeated into several categories including the game's theme (steampunk), core mechanics, narrative, player goal setting, and more. No one could agree on what the story was, how it translated to building out a believable world, both in terms of art direction and world building, and how that translated to mechanics that made sense for the game. For me, the game had turned into a melting pot of ideas that while each one in their own right was interesting, in the soup they all felt bad and mismatched. When I came onto the project, the game was a third-person platforming and combat game involving ranged weapons, and "knock up" and "knock back" melee moves. Allegedly, the game's story was about a crotchety old man who, fed up with the bureaucracy not doing anything about people on his front lawn, climbed into his mech suit and started to wage war on the city. It may also help to note that when playing the game, you didn't feel any humorous elements coming across.
The team leads couldn't agree on anything. The Game Designer wanted to create the game a certain way, his way. The Lead Level Designer complained that the Game Designer wouldn't stop interfering with relatively inconsequential level design decisions. The Lead Level Designer would then just argue on and on until a week or so later, nothing had been accomplished in the level.
The other leads were not performing very strong leading either. The Lead Programmer spent time working on a melee combo system that ended up being cut. The Lead Artist had a few problems. For one, he could not keep his artists on track because they were apathetic from all of the arguments happening on the other side of the room. Also, they were creating assets that were overly expensive. Many artists had to spend time doing rework to increase game performance. (In a milestone as early as Vertical Slice, the game having performance issues is fairly bad news).
Because of the constant bickering between Leads, the rest of the team was quite apathetic as one can imagine. When I arrived, no one was interested, motivated, or passionate about making the game anymore. Even worse, some people did not know what it was they were supposed to be working on.
I arrived in at the beginning of the Vertical Slice sprint. The team had two weeks to reach Vertical Slice Interim Milestone (an internal quality check), and another two weeks to reach Vertical Slice proper. For the first week, I talked with each team member, asked what they thought the major issues were, asked if they were motivated, etc. Almost everyone told me that they didn't think their game could be on the same fun or quality level as previous capstone games at the Guildhall. Many team members openly admitted they no longer cared to work on the game because of the incessant turmoil between the Lead Level Designer and the Game Designer. At this point, I knew that I needed to get down to the root problem of the team communication issues. The infighting was almost certainly causing the design issues as well. I knew that if I didn't figure it out quick, the team might drive themselves into the ground.
Solving the Secondary Problems First, the Game's Vision and Motivation
In my opinion, whether it was right or wrong, I thought it would be good to tackle the problem of the game lacking a clear vision that was understood by all team members. I knew that the dysfunction happening between some of the Leads was, in fact, a larger and more menacing problem. Maybe due to my inexperience, I thought that I could work on the team dynamics over time by having the problem makers share small successes each day. However, that problem is for later.
To solve the game vision problem, I decided to pull a desperate but necessary card from my belt: the reboot. I would not normally do this. I don't think that for most projects this would at all be a smart or good idea, especially so far into the project. However, at the rate that the team was going, the Capstone game would have been a failure had it continued. However, as an added bonus to the reboot, if I could get everyone to unite behind the banner of a new and improved game vision, it would also inherently solve the problem of motivation for most, if not all, team members.