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.

Course Analysis: MIS496A

The class that this blog was originally created for has ended! This was one of the best classes that I've taken at this University so far. Thanks to my tendency to morph class assignments into interesting personal projects, here are some of the things that this class has allowed me to do:

1. Start a gaming blog!
2. Make some cool QR-code posters for my club.
3. Get the idea for how to run our club's awesome Facebook group.
4. Get an internship with Riverman Media for next semester.
5. Make my first seriously-designed level.
6. Design an impressive infographic resume.

Of course, none of these things are what made this class so great. After all, I wasn't the only student who loved this class. So in this post, I'm going to analyze this past semester and figure out why exactly we found this class so enjoyable.

Nine GameDev-Related Things to do During your Holiday Break

I just finished writing a lengthy blog post on my club's website on how to productively spend one's holiday break. An article with that much effort put into it would normally be posted on this blog, because on the club website I usually only post short summaries of what we've been up to, which no one really reads. And so I'm tempted to describe this latest article as a guest post on my own side blog.

The reason why I decided to post this article there as opposed to here was because it's very specifically written to my members. When I asked some of them during our last meeting what they were planning to do during the break, I was shocked to find out how little they seemed to value the free time they'll have starting next week.

Or maybe I'm just weird. After years of struggling to find the time to work on the Interguild, I seemed to have developed some strong mental barriers against wasteful time spending. But that's not to say that I have good time management skills. It just means that I procrastinate by finding something else to work on. For instance, today probably would've been better spent writing my 10-page final paper for my MIS class, rather than writing a 10-page blog post for my club.

Level Postmortem: MIS496A HW5

Postmortems are traditionally reserved for critiquing the development processes of entire games, but it shouldn't be too far of a stretch to apply the same kind of analysis to a single level.

Introduction

This level was made for a homework assignment for the class that this blog was originally created for. The project was really open; all we had to do was create "something" that would highlight what we've been learning in class. Some people made videos, others made skits, and one group went as far as to make a advertisement campaign with the goal of getting more students to sign up for the class next semester.

Naturally, I decided to make a level, and the game I chose to make it in was Canvas Rider, an HTML5 remake of the popular Flash game Free Rider 2. The level is currently uploaded to the Interguild. To play it, copy the code in the textbox, visit the game page, paste the code into the textbox under the game, and click load.