Hi everyone!
My name is Min, and I am the Producer on The Maestros, a fast-paced RTS game where you wage war with cute adorable monsters and robots capable of transforming into harbingers of death, destruction, and doom.
So far, we’ve talked about the game itself, designing maps, building a unit, and arting up some beautiful scenery. This time around, we’ll explore a bit about how the aforementioned were organized in our production pipeline. In this blog post, I will be diving into the production of the game -- more specifically, how our approach shifted when the team went from a large student team to a small group of part-time developers. To start off, some backstory…
A Long Time Ago On A Campus Far, Far Away
Okay. Actually, it was just a year and a half ago in May 2014 at the University of Southern California in Los Angeles… where we presented our game in a large auditorium full of parents, professors, friends, industry professionals, and other student developers. This was the final assignment for the game as a yearlong student project -- a very big student project consisting of an international team of soon-to-be-professional hobbyists. Here’s a family photo of just some of our beautiful faces :)
We had a large team and a lot of work to do within a year. Most of the core team worked out of a shared space, our university computer lab (pictured below). We didn’t realize at the time what a luxury it was to have the whole team in one place a couple times a week.
There were roughly 1,500 man-hour worth of tasks every month, from an average team size of 48 people working about 8 hours a week over the span of a 4-week long sprint. Layered on top were college students’ time and budget (or the lack thereof) so we had to get creative with how we tracked tasks from sprint to sprint. There were a couple attempts at managing the workflow for our team. To start, we tried to take advantage of the shared location for our design & engineering teams by using the physical task board below.
Unfortunately with that many people & tasks, this quickly became unmanageable. There were a few free online tools but, for the most part, they were limiting. We needed something simple yet elegant and effective…
SimYEE
Allow me to introduce you to SimYEE - the Simple Yet Elegant and Effective solution to your video game producing needs. Built in the super modern Google Spreadsheet engine, it is indeed simple to use. You can view a sample of the task board here.
- Plan. We determine which goals to complete for the sprint and list out the tasks that make up those goals.
- Assign. Tasks are assigned to the team and each task is assigned a certain number of story points (SP), following the fibonacci sequence. SP indicates the relative size of a task.
- Lookup. It would have been utter chaos for everyone to look at a giant laundry list of everyone else’s tasks with 50 concurrent users. Separate sheets are built in where team members can look at just their tasks.
- Track. Once a task is in SimYEE, it is the assignee’s responsibility to keep the status of the track updated. The lifecycle of a task is as follows: open → in-progress → complete → verified.
- Clean Up. At the end of each sprint, the verified tasks are archived and tasks for the new sprint are added to SimYEE to continue the circle of life.
From a bird’s eye view, production was very simple. But nothing ever really goes according to plan. Tasks were often discovered and would be added to the task board midway through the sprints. Sometimes, team members left because they got awesome opportunities to work on game teams that paid in more than pizza and soda.
But I think the biggest challenge was due to the nature of the genre we were developing for. Our game didn’t follow a linear timeline. Designing an RTS was extremely fragile -- add one unit in one sprint, revisit the others the next. This called for constant ideation, iteration, and rebalancing. This topsy turvy juggling act spanned throughout most of production until our presentation for class concluded in May 2014, at which point most of the team graduated and went to work in the industry. A handful stuck around to continue development part-time.
Downsized Development
It was only about 6 months ago (about a year after USC) that we tangibly changed our approach to sprint planning and task management. A 6-person team means that each team member essentially owns his department (e.g. gameplay engineering, design, 3D art, servers, etc.). SimYEE was also simplified to reflect the smaller team: the many tabs from before are consolidated into a single sheet. You can view a sample of the new task board here.
On the flip side, a smaller labor force means a much slower development. Now, every task counts (not that they didn’t before). To streamline our planning, we broke our goals down into something we call “stories”. Stories have a who, a what, and a why.
- Who is going to ultimately benefit from us completing the story?
- What actually needs to be done so that the aforementioned “who” benefits?
- Why the hell do we even need to do this? So what?
For example, a story would read like this:
“As a player, the Blastmeister’s ability is sufficiently strong so that I don’t get rekt by the Tinkermeister.”
In this case, the player is the who. The Blastmeister’s ability being stronger than it is in the current meta is the what. Not getting demolished by the Tinkermeister when I playing as the Blastmeister is the why. Essentially, something needs to be rebalanced.
When we are ready to take on a story, we break it apart into individual tasks (which are then tossed into SimYEE, of course). The story above might be broken down like so:
- Design - Increase the Blastmeister’s ability’s blast zone and damage.
- Engineering - Implement a recoil on the Blastmeister unit casting the ability, pushing her away from the target.
- Art - Make the blast visually bigger.
Breaking down the features we want into stories like this and their subsequent tasks keeps our goals measurable and relevant. Plus, it keeps our sanity in check. As of the writing of this blog post, we have 61 stories left to tackle, which is a lot more manageable than the 400+ individual tasks that we kept in our backlog before. As we continue to chip away every sprint, The Maestros gets closer and closer to the fun and polished game that we all dreamed it would be.
The other improvement we added to our production toolbelt was some recordkeeping around how much work we have left and how much work we complete. This further allowed us to make some pretty graphs describing the amount of work we completed per sprint, how much work we have left, and ultimately helps us get an idea of how quickly we can complete work in the future using our velocity or how many story points we typically complete in a sprint.
But the game’s not done yet, and we could use a little bit more elbow grease and know-how to move things along. We are always looking for more RTS fans to join our humble team. If our game (or production methodology!) piqued your interest, be sure to drop us an email at team@maestrosgame.com.
