Tuesday, December 15, 2015

Capstone Post 7 : Post Mortem

What Went Right

1. Iteration

We nailed this on the head. At the beginning of the project, we had a new game direction about once a week. We started with a super simple game: Tap Zap, which was a game where you controlled lightning by tapping and tried to avoid obstacles. We decided we liked the trail left behind by the lightning and pretty much nothing else, so the next week we had a game where you moved a little particle ball around and collected spheres. Those spheres became your tail, which is where the idea of controlling something with a tail came into play.

The following week we took that and wanted to make a game about making little solar systems. So we prototyped that out, where you would circle around and eat your tail to make planets that orbited a sun. We needed some sort of gameplay, and we were thinking about how bodies interact in space. Obviously, when a planet hits an asteroid (the nodes of the tail), the asteroids break apart. So now we had this game where you flew around collecting asteroids and making planets: the planets would break your tail. This was frustrating to testers, so we did away with what didn't work and kept what worked.

I won't go into every iteration here, but the reason our game turned into what it is now is because we kept throwing away the stuff that didn't work and prototyping new ideas. It was sort of a running joke in the class: nobody could really tell where we were headed or what the game even was from week to week. Each week was a surprise to both the class and to us. Most of the development process was a cycle of prototyping, followed by critique, followed by new ideas, and back to a new prototype. For this reason, I was worried throughout the whole project that our game would fall short, that the idea would fall apart and we would never recover, and that the ideas we had didn't have enough depth or complexity. This drove innovation -- I think now that we're halfway through we have something that is truly unique, and large iteration moving forward is certainly not off the table.


2. Planning

Even though for most of the process we had only inklings of what we were going to end up making, we followed a rigid schedule. I have to give a shout-out to Shannon, our producer, for driving us through each milestone. We had overarching things we had to accomplish by specific dates, but this schedule was purposefully vague enough to be able to iterate as heavily as we did. We blazed through the stage challenges, each time with something very different but clearly more complete than the last. This certainly wasn't without frustrations and conflicts (it still isn't on iOS, sorry Shannon!!). We had to push a couple deadlines back because we had so radically changed the game that there was just no way we could prototype the newest idea in two or three days. But since we had now pushed the deadline back, as developers it seemed we had to just get the new idea finished for the next stage challenge. This pressure definitely kept us all busy, with a drive to stay on schedule. The schedule was made with a release in mind next semester, so we were always working towards that ultimate goal and if we pushed things back, it became very clear how it would affect the trajectory of this project.

In addition to this, we had a set weekly schedule for meetings. There was no confusion over when meetings were: if for some reasons someone forgot, our Slack had Google Calendar integration so slackbot would give everyone a little heads up 30 minutes before each meeting. Every single night at 11pm we had an online Scrum meeting, which only took about 5-15 minutes, but kept us all up to date with everyone else's work.

3. Adaptability and Cross-Discipline Utilization

Being a four person team gave us the obvious limitations that come with a small development team. We realized that a full, textured 3D game just wasn't going to happen with the limitations our artist presented us with. So, we came up with the idea to make the whole game shadow puppets, stemming from a concept of having planets cast shadows away from the sun (when it was still a solar system game). This let us keep the game fully 3D, but instead of rendering textures we just rendered shadows. This gave us a unique an interesting art style while also significantly lowering the art scope. When this proved to still be too much for our artist, our designer and producer made a few assets to make up for this absence. This is what I mean when I say cross-discipline utilization: Our designer helped with the programming, the whole team (besides me, I can't art well) made art, Our designer did all the audio for our game, and we all helped with the design.

4. We Liked Each Other

This is huge for any team, but we all genuinely appreciated each others' company for the most part. I remember coming up with the "you're a dragon putting on a ballet-like performance for the gods" with Zac: we were walking towards his apartment and needed a new direction for the game to take. So we brainstormed, and after a few left-field ideas we left the ballpark almost entirely with this new idea. It was all very casual: we hadn't scheduled a meeting to come up with a new direction, but rather it came naturally on an otherwise innocuous walk. Stuff like this happened a lot: I think the majority of our game-changing ideas came from outside meetings, which paid off in the end.


What Went Wrong

1. Weekly Task Confusions

While we had sprint planning meetings every Monday, and those were super helpful with user stories, there were a few occasions where members of the team just did not know what to do during the week as far as specific tasks go. A couple times, we reached full on conceptual blocks which would not allow anyone to do any work because the game had to change drastically in the next day or two. We handled these, I think, about as best as we could, but it was certainly difficult to know you need to do work and not really know what that work is.

2. Repository Management

Especially at the beginning, this was pretty rocky. Our repository was a mess: meta files and clutter everywhere, projects named incorrectly (The most recent project file is, to this day, still called "HungryHungryHyppo"), and general disorganization in folder structure. Virtually zero naming convention in the art files and no organization in that folder structure made it difficult to find the assets we were looking for. Old builds and old project files cluttered up incorrect folders (branches, trunk, tags), and we didn't use build numbers. Currently we are in version 0.8.0, but wow that is very arbitrary. It certainly got better over time, but a more organized repository would have made us more efficient, especially towards the beginning of the project.

2. Production versus Game

At the beginning, our producer really drove home the point that we would be releasing this game. In order to do so, we would have to keep the game in scope. This turned out to be a great thing: today we sit in a very good position to be able to release a polished and complete game. Throughout the project, especially at the beginning, I think our producer underestimated our abilities a bit. While I understand keeping things in scope was a priority, there is a such thing as too little scope, and in my mind it's just as dangerous for a senior team. There was always this push from programming and design (art is always going to be out of scope) to make a more complex game, followed by a push back to keep the game in scope. This certainly wasn't an unhealthy relationship, but I just felt like I had a lot more to offer than what I was being assigned throughout the first half of the project. Fairly often, I would sit down and complete all my week's tasks in one sitting, without much strain on my programmer-brain. At the same time I didn't want to change the design to give myself more work, I do feel that I could have done more in the first half of the project than I was given to do.