Signing up for a class titled “Game Design”, I automatically assumed that I would re-learn the same processes and eventually design a thoughtless game where the protagonist, a burly strong-man, defeats some ugly ogre to save a princess. Little did I know this class would open my mind to a new train of thought regarding game design. My horizons have been broadened, for the better or worse. Worse for the fact that I sometimes look at the games I play and wonder “How could this mechanic be made more accessible?” or “Why did they choose that design over this?” Now over-analyzing games has always been a hobby of mine, but the aspects that I focus on now sometimes surprise me.
The process of game design and production is a long and difficult road, one laden with obstacles that are often unforeseeable. At the end of the road lies satisfaction and accomplishment like you’ve never felt. It’s one thing when you complete a difficult project for science or math, but when you make a project that’s played and enjoyed by others, it’s a completely different feeling. On this journey you’ve got a crew, and this crew becomes your road-trip necessities: entertainers, navigators, drivers and suppliers. Interfaced is one of the most well-planned and well executed games I’ve worked on, and it wouldn’t have been had I not worked with the team I had. I’d like to use this post to discuss the good and the bad that came out of this process, not only to fulfill the requirements for this assignment, but to force myself to think critically on what’s taken place to better my abilities for the future.
Good – Balanced Team
We were quite stubborn during the “Team Up” game. When Celia brought up the idea of creating balanced teams by means of splitting up certain “cliques”, we weren’t for that. I think Michael was the main advocate for our non-movement, which, at the time, seemed like a bad idea. I mean, who would want to go into a project not sure if you have the right guys for the right jobs? Not only did our original five stick together, we recruited an artist from another team that seemed already established. When all was said and done we had six guys total, and each of us were well versed in what was needed for the group. None of us had to really go out of our comfort zone to build the game, which I think was one of the reasons we were able to develop Interfaced so quickly.
Good – Communication/Planning
As project manager, this was my job. I can’t say that I did amazing, but I can say that we hit the ground running. Nothing was held back – everyone contributed to everything. Before we even started holding team meetings, we had nearly five or six different and equally intriguing game ideas posted on the Wiki Holden created for us. All of our design work was well documented and placed so that the team could view it. When something came up, it wasn’t a conversation between two members rather it was an issue for the entire team to handle. I was able to set up schedules and our team was able to meet those deadlines.
Good – Starting Early
One of our initial goals was to get something playable by IGF. As that deadline grew near, you could tell that some of us had our doubts, but whether we made it or not, starting early would only benefit us. This is where scheduling became important because I was able to setup certain milestones to check ourselves by. I left these vague and allowed the group to flesh them out. One benefit of this early leap into production was the fact that we were able to get a good digital prototype working for testing. Zimmerman mentions that “Initial prototypes are usually quite ugly. Game prototypes do not emphasize aesthetics or narrative content: they emphasize the game rules, which manifest as the internal logic of the game, tied to the player’s interaction.” I couldn’t agree more with the ugly part, but what our prototype did provide was a basis to work off of. Although we still spent the weekend before the IGF submission locked up in an apartment coding, our early build enabled us to start using the art assets level designs rather than waste time staring at a blank screen.
Bad – Accounting for the Player
I’ve heard of many developers making the same mistake – our game comes so easy to us as the creators, so we assume that the audience will pick up the game and be experts like us. Wrong. We wanted to make a unique game that used and altered interface elements from other games. “If you know how interface objects work in other games, you’ll understand ours”. But if you completely change the way these parts work (i.e. making them interactive and functional within the game-world), you’re going to confuse some folks. In our battle to make it intuitive, we broke one of Norman’s rules for helping new users understand what to do:” #2 - Use words to describe the desired action (e.g., "click here" or use labels in front of perceived objects).” It would have saved us a lot of head/heartache during play-testing – Why can’t they understand this?? Why do I have to keep explaining this again?? Luckily we’re planning to continue iterating on the build, so we’re including signs and WORDS (per Norman’s request) to help new players understand our attempted intuitivism.
Bad – Iterating on an Early Build
Even though starting early was one of our good choices, us deciding to use that early build to build the entire game might have caused more pain than it was worth. If we had built the game from the ground-up after most of the design was finished, we could have structured our code in such a way that was would have run into fewer bugs. Instead we faced things that weren’t fixed early enough, yet had so much built on top that it was more problematic than it should have been to fix. Luckily we had three guys on our team that were pretty competent in coding, myself included, so many of the bugs were fixed, but some are still present.
In the end I think we were all very happy with the turnout. Most people really liked our idea and how we implemented it. We created what Lazzaro describes as an “Easy Fun” game, one where “players enjoy intrigue and curiosity. Players become immersed in games when it absorbs their complete attention, or when it takes them on an exciting adventure. These Immersive game aspects are “Easy Fun” and generate emotions and experiences of Wonder, Awe, and Mystery.” (7). It was probably a much different game than we anticipated creating upon entering this class called “Game Design”, but as mentioned before, our minds were opened.
Norman, D.A. (2004). "Affordances and design." http://www.jnd.org/dn.mss/affordances_and.html
Lazzaro, N. (2004-2005) "Why We Play Games: Four Keys to More Emotion Without Story." Self-published white paper. www.xeodesign.com/whyweplaygames.html
Zimmerman, E. (2003). "Play as research: The iterative design process." http://www.ericzimmerman.com/texts/Iterative_Design.htm
Comments