The End of the Beginning (or the First Semester of a Grad Program)

I realize today that my final first semester blog post never made it to the posting machine, which is what I call my computer. A large reason this never happened was that I spent a bunch of time writing a game design document for a game I'm calling The Next Dragon. You can check out the game design document in Google Docs here. For reading inspiration, it's a first person fighting game based on the cheesy theme of 70's and 80's Kung Fu movies. See Sho'nuff (he's pretty great):

I'm going to go ahead and embed the pdf version below. I can't vouch for the usability or quality of Slideshare in regards to pdf's, but if you're lazy and don't want to follow the link, here you go:

And just in case you're a real glutton for punishment, you can go read my thesis paper for the above design document. It's mostly about spatial presence and immersion, and how that can be enhanced using diegetic and meta-perception user interface elements. Read it here; it's a fun read.

So, the burning question on everyone's mind must be: how did Goobles end? Unfortunately Unity has some terrible version control issues that were a problem. We spent a great deal of time merging code together. It started to feel towards the end that we were learning how to wrangle Unity with a team of this size, but we were hurting for a bit there. I did my best to figure out how to handle version control, and with my efforts combined with a couple of the engineers we were able to handle it well enough. Overall we eventually got everything working together and produced a very fun game. Probably the best prototype I was a part of this semester. Check out a screen of the final product:

This was an odd project. With so many producers it felt at times we were scrambling to find things to do. With three of us, the third producer lagged behind somewhat. He initially started out very helpful but then failed to make a move to be involved with the prototype. I blame myself somewhat for this, as I could have done more to try to include him. In my mind, if he wanted to be busy and helpful he would have. On the other hand, if I would have just assigned him more tasks he might have done them. I was caught off guard by a fellow producer failing to meet my expectations. In the future, I would attempt to massage the issue a little bit and work on including people who feel excluded. Overall though, great project with a great result.

After the semester was over, I had a nice three week break where I worked on a game for a competition from Ubisoft. The theme was "Space: The Untamed Beast." It had various requirements such as being a third-person game where the character was always in view and having three types of hostile enemies. Winners of the competition get to intern at Ubisoft for a couple months and make their game. This is an amazing opportunity. Unfortunately, I was only able to drum up three other people for my team. The EAE program had to have a mini-competition to pick which game would be submitted to the actual competition and by the time I found the people I wanted to work with, most everyone was on a team already.So my team ended up being myself, Triston, Yang, and Yuntao, which is four people for a possible eight person team, with no artist. We were starting in a hole, that's for sure.

How did it go? Eh, alright. We spent a lot of time working on our design, and I think we hit on a dynamite idea. Unfortunately, a couple of us had plans to leave Salt Lake for the break, and we just didn't get the prototype done. We decided to pitch anyway, mostly on the strength of our idea alone, and it turned out like this:

I don't want to spend too much time on it, but the idea was that the player was the spirit of a star who was trying to create her own solar system right after the big bang. The player would control an avatar, the star spirit, who would go around and collect the free-floating resources and create planets with them. Once the planets were created, the player would send them in motion around the star. I think it has a ton of potential, but we just didn't get there with our prototype. That's okay. I learned a lot from the brainstorming sessions, and this idea isn't going away.

Next time I'll discuss the first couple of weeks of my second semester (and that should be a much quicker post).

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.