Tuesday, December 4, 2012

My Plans are Foiled: Goo Balls, Weeks 1 and 2

Last time I spoke about toning down the scrum process; making it simpler and easier and not worrying about the process as much. As it turns out, that's not really possible this prototype. Surprise! This time, we're working with another producer and joining teams of nine to ten. In my case, the team has three producers (and therefore ten people). So the idea of using post-it notes and letting people communicate directly (either through email or in person) doesn't work as well. However, I have been prepping for this moment all semester, whether I knew it or not, with my overly complicated and under-utilized scrum spreadsheets! Speaking of, here's my newest iteration (click on the screen shot to view the actual spreadsheet):


I changed a few things up this time, throwing the spreadsheet more in-line with the actual scrum process. First off, I decided to stop breaking down tasks twice, from the release backlog to the tasks tab. Previously, I would break down the task into smaller pieces and then take the small pieces and throw estimates on them and assign people to them in the sprint tab itself. This was a little confusing to people who just wanted to see what tasks we had remaining in the project and grab something. Now I break all the tasks up in the Tasks tab and assign values, priorities, etc. I've also learned that Google spreadsheets allow data validation, so now people can pick a name or a sprint number from a list instead of typing it in themselves (anything to ease the process). So far the spreadsheet is really nice, but people seem very reluctant to actually use it. Today I'm trying again, now that the game design and direction has been worked out a little better, and hopefully I'll get better results.

All this process and you don't even know what the game is yet. For this last prototype, we have no client and not much direction. Here's what we have:
  • Unity for development
  • Game Jam/Indie game (no AAA tropes)
  • Working in larger groups
  • Producers can't design
So that's easy right? Engineers and artists have to do all of the design (and their normal duties), and producers do all of the process. Now you can see why I spent so much time working on my scrum doc, as I have taken the mantle of scrum master on the team. To be honest, it's been a little tough to keep busy with the way the engineers have wanted to design. There's been a lot of experimentation on their part, which scared me at first, but I trusted them to do their part and we've had a lot of success.

So what do we have? Our first day we had a great brainstorming session. We wrote down a bunch of ideas, figured out an interesting way to combine many of them, and then had everyone work on a sample idea or level that night. We met up the next day and pooled our collective ideas to make sure that everyone was on the same page, or if they weren't, what idea they had that led them in that direction. As a producer, my main goal early on is to get everyone personally invested in the project. The best way I've found to allow this to happen is to try to incorporate everyone's ideas, even if it's just a really small part of an idea or a slight twist on someone's idea. Oddly enough, this usually turns out the best games. With so many people bouncing ideas back and forth, and working through ideas together, my groups tend to get pretty interesting designs, and everyone is happy with at least a part of the concept. So our process this time involved a lot of brainstorming since there were so many people working on the project. After we somewhat cemented the idea, the engineers wanted to go make something in Unity. We decided that everyone would create something they thought would be interesting and bring it to our next meeting on Saturday. This worked out pretty well, and as of Saturday, we put down in writing exactly what everyone's tasks were, and what needed to be done. We mainly use our Google group to communicate all of this compiled information to the team, and we also have a wiki we're using.

During this process, the team felt to me like a real indie studio. We have lots of engineers, a couple people to run the process and make some decisions, and an artist (which we could probably use more of). The design was open-ended enough that people could etch out a niche for something they enjoyed, whether it was making a collection of tiny balls into a goo-like substance or designing an interesting trap for our game or laying out a level with a great flow. It was a great collaborative process that turned out a very interesting game.

However, all of that creativity and exploration has to have a downside right? For us, it's time. We have too many ideas and not enough time to implement all of what we want. So at some point, the producers (and the engineers to an extent as well) had to say, "Look, this is all great, but we have two weeks and no completely working builds yet." We're getting there now though. Unfortunately Unity as some terrible version control issues that have been a problem. We spent a great deal of time merging code together. It does feel that as we're learning how to wrangle Unity and a team of this size, the project (and the semester) is ending. That's probably the point of this exercise. The semester ends on a similar note to how it began: lots of confusion and figuring out things just as you stop working on it.

Next week: the end of a prototype and a semester, dealing with one less week.