What? A post-mortem on an academic quarter? How strangely game-designer-y!
Indeed. But as Winter wrapped up last Thursday, I started to feel like I should talk about how it went and what I learned. So here we are, with my first academic post-mortem.
Conclusions in Brief, or TL;DR
There are two overriding lessons this quarter:
Lesson 1: Don’t be so goddamned precious about your work.
Lesson 2: You do actually know what you’re doing; it’s not always a mistake.
Simple, but I think they’re both harder than they look and extremely important. That all said, I think my biggest takeaway for this quarter is simply, and I can’t stress the profundity of the statement enough, this:
Maybe I am a real game designer after all.
It was a rough quarter. Three classes, three game development projects independent of each other. One non-digital game, one digital game and one game design document. Several of my classmates felt I was insane, and more to the point that I still am.
It was rough going at various points. There were bits where, I won’t lie, some despair set in. But while this was the busiest I’ve been yet it was also, I think, by far my most successful quarter.
The first and most noticeable facet of this is the turn-ins on the projects themselves and my mental state during that last couple of weeks. All three were turned in on-time and to their projected level of polish/completeness. During the last week, I was surprisingly unstressed, despite being extremely busy, which was a novelty. I’d managed to pace myself well enough throughout the quarter that the final rush wasn’t as hair-raising as it has been in the past. Which is awesome—I want every quarter to be like that from now on. Only one all-nighter the whole quarter, which was the last night.
The second surprising and happy circumstance was the reception all three projects got from my peers. In all three cases, i was concerned less about finishing and grades than I was feeling like all of them were good for turn-in, but none of them so great otherwise. I was proven wrong on this one. I let a classmate or two play Steel Skies after I turned it in, and both of them spend a good five minutes with it even though there’s only one 30-second level. They really wanted to shave some time off their score for the runs. For The Journey, I had to actually teach someone the game in front of my supervising instructor as part of the turn-in. This was nerve-wracking because I didn’t feel like I’d “found the fun” yet. To my surprise, it’s already there, as we ended up having a blast playing. Finally, I was iffy on the state of my game design document for Waystation, but I got a lot of positive feedback about the final doc as well as the game itself.
This second part, on the whole, made me feel like maybe I really am a game designer of some talent and not just spitting into the wind. I’ve been told I’m good before, but some things you can’t be told—you need to have it proven in some personal way. This is one of those things.
On to the project breakdowns:
Project 1: Waystation
Waystation was the name of the game for my game design documentation class. In brief, the concept revolves around a city-building game like Sim City or Tropico 3, but dealing with a space station instead, while being a bit more “hardcore” than Outpost Kaloki in terms of aesthetic.
Scope was a major issue, of course. Ten weeks in a quarter is not a lot of time to write a document for a large game, especially when you have three projects to get done. Waystation was a bit ambitious, right on the edge of scope for the circumstances, I think. It was able to be bigger than usual, due to nothing being produced other than the document, but I underestimated how much detail would end up coming out.
Lesson: All the little things make big things bigger.
It became a serious problem, both in terms of getting everything done to the detail needed, and also because as game mechanics and such become more refined over the weeks, it became difficult to make sure everything that needed updating got updated. Next time, I’ll need a better organizational system. It is likely to be key.
Lesson: When things get big, things need to be more organized.
I was also a bit concerned about my mechanics themselves. There were a fair number of new features, and I didn’t feel like I had the time to really develop them and get them pinned down to something that made sense and was interesting. This, however, turned out to be an underestimation. Feedback held a great amount of both understanding of what I was describing (mostly) and interest in the way it seemed like it would play out. By the end of the project, people were actually invested in what I was doing, a mark of success beyond the immediate success of finishing the project.
Project 2: Steel Skies
This one was for my Human Centered Design class, in which the core focus of the class is on user-testing and working it into a design process. As such, this project got put in front of people while it was still barely-working and every iteration of the project got put back in front of people. It was kind of terrifying, on the whole, but ultimately a stronger project for it.
The initial goal of the project was to take the basic design of CANABALT, which I’ve enjoyed many a time, and mutate it into something a bit more in line with my preferences (as well as those of some friends of like mind).
The first problem was, in a nutshell, code complicates everything. On the whole, you don’t realize how much is happening in even a simple game until you try and make one and write the code. Collision was a constant problem, making the player follow the ground was another (and technically part of the collision problem). Wall-jumping had to be cut due to the code difficulty infringing on the time. Procedural level generation was intended to be a big part of it, but was cut very early when the enormity of the “small project” was realized. And so on.
Lesson: Simple really isn’t.
There was, fortunately, still a lot of user-testing to do with the pared-down Steel Skies. Interaction and the motion of the character were still very important, and were iterated on right up to the end. Level layout became very demanding in short order, as did conveying the instructions for how to play. Ultimately, cutting those features made the remaining ones MUCH tighter due to focusing the iterations.
In the end, I wasn’t sure how fun it would be. A lot got cut, changed, or didn’t work out from the initial proposal, and I wasn’t sure what was left was enough. However, when I showed the “final” version of the project to classmates after I turned it in, they found it engaging. One person commented that he was compelled to try and shave a few milliseconds off his score, and played for a solid 5-10 minutes. Success after all.
Project 3: The Journey
This was my independent study the quarter, so it was a very personal sort of project. I created a card game in which players build a narrative based on Joseph Campbell’s Monomyth structure during play. The intent was to explore the subject of procedural narrative and engaging the player as part of the storytelling process. I will probably speak about it later, since the ideas I was exploring are very much tied into my area of interest for thesis work.
This was really hard. Finding mechanics that actually turned Campbell’s work into a decent game was difficult to say the least, and there was a constant struggle between simple mechanics and making the needed aesthetic work. Eventually, I decided that it would simply have to be somewhat complicated.
Part of the problem I had was that I had this deadline on a project that needed me to “find it”. I spent a lot of the quarter searching for the game I knew was in there and getting worried about having a deadline on it. It was nerve-wracking, and I started to worry that something was wrong, that i wasn’t as good as I thought, etcetera.
It was Brenda Brathwaite’s talk at the Art History of Games Conference in early February that got me over this hump, ultimately. Her very personal discussion of her design process got me thinking about my own, because in some ways it sounded so familiar to me. And I started to realize that no, there’s nothing wrong with my process per se. The Journey is simply a very personal project and I needed to give it the time it needed to become known to me.
Lesson: There’s nothing wrong with you. Give it some time.
Ultimately, it did more or less work out. Of course, with a card game, there are a number of issues at work, and the game is not balanced, and I felt like “finding the fun” hadn’t really happened yet. It does, indeed, still need some polish work and odds and ends, and there’s definitely balance issues. But I had thought it necessary that I come to terms with the idea that the project could do what I set out to do without actually being a fun game people would potentially choose to play.
As such, I was a little under-enthused when I was told I couldn’t leave until I’d conducted a play-through with someone that hadn’t yet played it. However, I was terribly surprised, because something magical happened.
My guinea pig volunteer read the rules, and we got started, and… he understood. He understood what the game was really going for, and as soon as he engaged the game on those terms—as a storytelling game that required participation beyond playing—suddenly it was a whole other story. Heck, I was having fun watching him engage with it, and I’d just wandered into the classroom sick to death of the thing.
It was very humbling. All of the projects were. Just freakin’ wow.