A Retrospective of SISTA's Game Design Workshop

As I mentioned last month, the University of Arizona’s new School of Information: Science, Technology, and Arts (SISTA) has been organizing a Game Design Workshop for kids. The workshop was a one-week summer program that aimed to teach kids about game design and development, and I was lucky enough to have been hired as a teaching assistant for it. There was one other TA, as well as three instructors, which meant we were a team of five teachers in total.

Our biggest challenge was the fact that this was a brand new workshop being run for the very first time, so we essentially had to design it from the ground up. The bulk of the work was done by the instructors, while we TAs were given specific tasks to learn Stencyl, take notes on our experience, and design some lessons for it. During the several weeks before the workshop started, we were mostly working remotely, using online tools like Google Docs to collaborate. During the final week of preparation, we all met up to bring everything together and to "test" the design of the workshop so far by running through a mock version of it. The workshop then ran for two sessions, where each session lasted for one school-week (five days), and then end with a big playtesting event, where all of the parents and relatives could come in to play the students' games.

So was the workshop a success? Many of the people involved—from the kids, to their parents, to the rest of the SISTA faculty—were blown away by how amazing they thought the workshop was. The positive feedback was pretty consistent across both sessions, and it’s been immensely satisfying to read through the anonymous surveys that we’ve been collecting.

In this post, I’ll point out the various aspects of the workshop that I thought made it work so well, while also pointing out the various problems that we failed to avoid. Even though I found the typical postmortem format to be pretty useful when writing this, this is more accurately described as a retrospective. I'm not really in a position to be able to speak for the entire team, and since part of the goal of this post was to critique my own performance as a TA, I've added a few self-evaluation sections as well.

I've Gone Viral! . . . In China?

This blog really doesn't get much traffic at all. I get anywhere from 2-20 pageviews per day, and that number usually spikes up to around 40-60 views on the days following a new post. The "low season" in between posts isn't completely dead, because plenty of people seem to land here from Google Images. For instance, I got an interesting spike in traffic last month when Extra Credits started a T-Shirt design contest and apparently a lot of users were landing in my History of Extra Credits articles looking for images.

However, these mini-spikes in views usually aren't very significant compared to the traffic I get from subscribers every time I post. So imagine my surprise when I noticed a spike that was slightly bigger than the usual new-post spike. This spike happened just a few days before I posted my most recent post, and that should have been part of a really low season since I haven't posted an update in over a month. After looking into it, I found not one, not two, but three websites with articles linking to me.

Long story short, someone seems to have translated my article on How to Think Like a Designer into Han Chinese. And since then, it's been getting passed around and reposted on multiple Chinese websites.

Why I'm no longer Skeptical about SISTA's new Game Design Workshop

[This article explores some of my fears and predictions about the workshop. To find out how it actually went, click here!]

Starting tomorrow, the University of Arizona's School of Information: Science, Technology, and Arts (SISTA) will be launching its first Game Design Workshop. It's a one-week program designed for kids between 6th and 12th grade, and it's being run for two consecutive sessions. I volunteered to be one of the two teaching assistants helping to run the workshop, and our latest assignment is to write a reflection on how we think the workshop might go. One purpose of this reflection is to produce a more visible representation of the work I've been doing so far, which makes this assignment a perfect fit for a blog post!

Given how busy I've been all summer, I was starting to think that I wouldn't be able to update this blog again until fall, so I'm glad that I was able to use this assignment as an excuse for a new post. Plus this gives me a good chance to practice writing posts with smaller scopes. Most of my posts tend to start out with a vague plan that I'll just talk about everything I want to say on a single topic, and then I'll figure out how to merge them all into a coherent thesis later. It is an absurdly slow process, and it's about time I stopped doing that.

For instance, this post started out as a list of predictions about how the workshop might go, plus some descriptions of the interesting aspects of the workshop's design woven in. Fortunately, I had enough sense to realize that the workshop would probably be over before I could even finish such a post.

Deconstructing the Iterative Development Process

This post actually started out as a retrospective for the game I've been working on for my internship/independent study with Riverman Media. At first I was planning to write on everything I've learned during this semester, almost like a postmortem for a project that isn't over yet. But such a post would have probably ended up being a loose collection of small tips, and I prefer to use this blog to explore deeper topics. So I decided to write on the biggest and most confusing problem that's been bothering me all semester: how to properly use the iterative development process.

In the past few years, I've seen at least three memorable explanations of the iterative process, and most of them were too complicated to be practical. It wasn't until I read Jesse Schell's description of the process that I started to believe that I finally understood it, but when I tried to apply it to this project, it just didn't feel like design to me. I have experience designing things in several different media, but for some reason, I felt like I was having trouble migrating my usual design perspective to a long-term game project.

The more I explored this problem, the more I realized how shallow my understanding of this process was. I had learned a lot about the surface details of this process, how to use it, and why it worked. But I didn't really understand why this process was designed in the way that it was or how to fix it when something went wrong with it.

I eventually answered these questions by trying to design a brand new development process that would work for me. I was basically trying to reinvent the wheel, so it was little surprise that I arrived at the iterative development process as my answer. But along the way, I was finally able to wrapped my head around how this process is really meant to work. I decided to turn this exercise into the premise for this post, and the result is a guide that teaches this development process by focusing on its design rather than how it's used. In other words, it's the kind of guide I wish I had read before starting this project.

Everything I've Been Doing Lately

Now that it's been almost two months since my last blog post, I figured it was time for a mandatory blog update. Because I don't have time right now to finish one of the longer posts that I've been working on for the past several weeks, I decided to write a quick post that will hopefully make the slowness of updates seem more justified.

There have been many times when I've wanted to post about some of the cool things that have been happening to me lately, but I just didn't like the idea of posting several small updates about them. If I did that, then the smaller updates might start to crowd out the "real" ones, which might turn this blog into a self-promotional personal blog, rather than a game design analysis blog. So to prevent that, I'll just dump everything I've wanted to say into one big post.

Packaging Design: the Experience of Treasuring our Favorite Games

Writing about this topic might seem rather unusual, especially with digital distribution on the rise. But considering how most game developers, myself included, share the dream of creating games that players absolutely treasure, I feel as though flawed packaging design is getting in the way of this dream.

For example, I own plenty of games that I absolutely love, but whenever I go play some of these games, the casings that house them almost always leave me disappointed in a way. Not only is it a shame that the packaging doesn't live up to the quality of the experience as I remember it, but it almost makes me feel silly for having had such high regards for the game.

While I know that game casings are primarily designed for minimizing the cost of manufacturing and distribution, I believe developers are underestimating the impact that their packaging can have on a player's experience. Much in the same way that listening to a game's soundtrack can bring back fond memories of one's experiences with a game, a well designed casing can keep a player's love and respect for a game alive long after they've stopped playing it.

Project Aeon, and How I spent my Holiday Break

It's been a month since my last blog post, so today I'm going to write about what I've been doing since then. Even though I've been on break from classes for the past month, I've been incredibly busy working on a Flash game called Aeon. I first introduced this project in my History of the Interguild series, and given that this is a blog about game development, it's odd that I haven't written more about the game that I'm currently developing.

Most of this game's production has been incredibly slow, inefficient, and just plain horrible. But recently, I managed to turn this project around while making more progress in just one month than I would have made in a full year otherwise. In this post, I'll explain the major challenges that have held this game back for so long and how I drastically improved my time management and productivity skills.