Hello, my name is Mike Gowen.

Learning Game Design: Goals

I’ve only just begun to scratch the surface of designing casual/social games but during the course of learning I’ve discovered a number of key differences between web application design (my forte) and game design. My plan is to pass this information along as a series of posts I’ll call “Learning Game Design” (I know, not very creative). So I’ll kick it off with a few observations about goals.

Goals

Most web applications are designed to enable the user to reach a goal as efficiently as possible: track your time, manage a to-do list, etc. Furthermore, it is generally good practice to achieve this with as small a feature set as possible. But what if that goal is to have fun? How does that change the design approach and the expectations of the user? Let’s look at the fundamental difference between a web application and a game in relation to achieving goals.

A web application is, more often than not, designed to help you reach a goal that is outside the confines of the application itself. Its role to to get you to an end and stay out of the way while it does so. Conversely, a game implicitly defines the goal for you and typically this goal only exists within the set of rules laid out for the game. As such, it is within the journey *to* the goal that success is determined. Imagine a race-to-the-end car game where the goal is get from point A to point B as quickly as possible. Now imagine that the track on which you are driving is straight, smooth, and there are no other cars on it. Not very fun. While the goal of the game is reach the finish line as fast as possible…and the most efficient way to achieve that goal is via a short, straight and smooth track…the fun lies in the obstacles that inhibit you from achieving that goal. Now imagine a simple to-do list application…only in this application you have to solve a puzzle in order to add a new item, other players can reshuffle your items at will, and you have to use a whack-a-mole mechanic to check off completed items. Obviously this is not the type of functionality you’d be looking for in a to-do list application.

So how does this affect your approach to game design? Well being that I am new to this, I am only beginning to be able to answer that question. However what I found so far is that sometimes less isn’t necessarily more when you’re designing a game, as is the case when designing an amusement park or a playground. But this isn’t true for every game, just look at Tetris. The key is getting a playable prototype built as quickly as possible, sometimes before you even sit down at the computer (more on this in a later post). This allows you to work out the core mechanics and more accurately predict their success before jumping into development. It’s relatively easy to see a web application on paper and be able to determine if it has more or less achieved its goal (UI nuances aside). However looking at a game on paper, its nearly impossible to determine if it will be fun…or fall flat.