July 2009's topic, Mature Games, was submitted by game designer Ryon Levitt.
He writes:
"For the love of God, think of the children!"
The famous train of thought that has carried much debate against the video game industry. But is this realistic anymore? The ESA says that "The average gamer is 35 years old and has been playing for 12 years." However, while many other media, such as books and movies, are recognized as having certain (not necessarily pornographic) sub-genres for adults, many critics continue to act as though the word "game" automatically means "for kids". One reason for this is that the typical target demographic is still Adolescent Males and, as such, contain many typical "young male power fantasy" stereotypes - Big Guns, Big "Guns", Violence, Crime, Sex, Drugs, and, of course, Rock and Roll.
As designers, we face many questions regarding this subject:
- How can we fix this image?
- SHOULD we fix this image?
- Are games for adults and youths mutually exclusive?
- What do adults want in an entertainment medium?
- Does "adult" automatically mean "casual gamer"?
Ryon Levitt is a programmer-turned-designer for KOEI, currently working at their main branch in Yokohama, Japan. He is currently working on his first title as a designer. Ryon is one of the founding members of the IGDA Game Design SIG, and helped coin the acronym GDAM.
Friday, June 19, 2009
Prototyping: An Odyssey (Part I)
In Part I of this article, scholar Altug Isigan looks to etymology and the Odyssey for lessons on prototyping.
In Search of Full Sail
When I decided to write an article for this month’s GDAM (I didn’t know at that time that it would be this article), the first thing I did was to look up the word prototype. To my surprise, I found that it was rooted in a combination of the Old Greek words protos and typus: “first impression”. I thought that most game designers would find this to be a very appropriate definition.
Delving deeper into the etymology of the word, I found out that it was connected to the adjective ‘protean’ (someone or something taking on varied shapes), which in return was generated from the name of an oracular ancient deity with the name Proteus. At the very moment in which I decided to have a closer look at this deity, I had already triggered a trap: Before I even realized, I was thrown into an odyssey that would carry me through the vast seas of prototyping. Would I be able to find my way back home? Only the winds knew the answer.
Indeed, it is one of Odysseus’ close friends -Menelaus, husband of the beautiful Helen of Troy- who, in Homer’s Odyssea, mentions the name of Proteus. In an account of what happened to the many heroes of the Trojan War on the way back to their homes, Menelaus tells Telemakhos also the story of his own adventurous return to Lakedaimon (Odyssea, Chapter IV: In Lakedaimon, verses 350-570): He and his friends get stuck on the island of Pharos, where for weeks and weeks there is no wind to fill their sails. Eventually they find themselves plagued by scarcity and face starvation. The exhausted Menelaus finally realizes that the reason for this abnormal situation must be a curse of a god that he must have failed to please. But which one, and what wrong had he done? Obviously, only an oracle would be able to tell him these secrets. But where on this abandoned island could he find such a gifted person? It’s Eidothoe(Ido) who suggests him a solution: She says that he must seek the help of Proteus, a prophetic sea god that frequently visits the shores of Pharos with his flock of seals. There is a problem though: Proteus doesn’t like to share his wisdom with others, and should anyone attempt to force him to prophecize, then he pulls off some stunning tricks that help him to escape.
“Proteus possessed the gift of prophecy, a gift he could avoid using by utilizing his ability to metamorphose at will. In an instant he could become fire, flood, or wild beast. However, if a person held him fast, no matter what form he assumed, he would eventually return to his normal form and deliver the truth.” (Dixon-Kennedy; 1998: 263)
Menelaus, determined to escape the island, prepares a trap, and with the help of his friends he captures Proteus, who, after some wild shapeshifting, eventually normalizes and tells Menelaus the reason that got him stuck. With this vital information, Menelaus manages to bring back the winds and re-opens the sea routes that will lead him to his beloved lands of Lakedaimon.
I must admit that I was enchanted by this myth. It was a wonderful metaphor for prototyping and captured its essence perfectly. Let’s look at the elements of this myth:
• Metamorphoses: the ability to assume many forms in rapid succession.
• Prophecy: the revelation of the mistakes you were unaware of at the time you made them; and directives on what course to take in order to repair the damage that they have done.
• Exactitude (As an extension of the Prophecy element): The Oracle of Delphi carried the inscription “Know thyself!”, an inscription that has been often interpreted as “Know your problem!” or “Have a clearly formulated question!”. Otherwise the answer of the Oracle will sound cryptic and useless.
• Teamwork: You can’t fasten Proteus all by yourself; you need the help of a group of dedicated and determined people.
So, what’s prototyping then? Following the myth of Proteus, it is –together with your comrades– to hold tight onto the prototype –and your question!–, and not to allow yourselves to be fooled by the many shapes it will assume. If you’re determined enough and hold on tight, finally the prototype will be tamed: Your mistakes as well as the steps you need to take for the future will be revealed to you.
Now, as we seem to have some wind filling our sails, let’s move quickly to our next topic.
Working at the Pace of Mind
There are many fascinating things about prototypes and prototyping. We can summarize the most important points as follows:
• Sustainability: Prototyping is a (relatively) cheap and repeatable process.
• Flexibility: You can prototype almost anything, with anything (and anyone).
• Safety: You don’t risk to waste expensive code or art during or after experimentation. More than that, you protect yourself from wasting such expensive assets in the future, because the prototype will help you to tell into which assets to invest and into which ones not.
• Modularity (Scalability): Like a magnifying glass, you can zoom into particular game mechanics or zoom out to see the interactions between them.
• Responsiveness: Instantly make changes and receive feedback on them. A prototype is functional, interactive, up-and-running.
• Collaboration: Although it mostly starts alone, prototyping can be easily expanded to include friends, team members, producers and executives or members of the target audience.
• Control (Manageability): You can always take a step back and reconsider things, until you feel that you’ve cleared it all up and are ready to proceed with the next step. You have control over the goal, scope, ‘question(s)’ and what not’s of the process.
• Experimentation: (Almost) anything goes! It is the playground of the imaginative and innovative mind.
However, there is one thing that is the ultimate argument in favor of prototyping, and that is its pace and exactitude. These qualities can make them so persuasive that it made one game designer to speak of prototypes as “powerful ninjas” who can “move mountains” and “cut all debate with one swift movement” (Gingold, in Fullerton, 2008: 184). Is that to say that a prototype works at the pace of the mind? Not always, but probably it is the method closest to cope with the pace of the imaginative mind. And when it’s done well, a prototype becomes the sharpest of arguments, like the sword of a ninja.
…We’ve made quite some way already, but there is still a lot to discover in these waters… See those islands over there? Let’s go and check them out!
Altug Isigan is a scholar at the Eastern Mediterranean University, Department of Radio-TV and Film, in sunny Famagusta, Cyprus, where he is writing a dissertation on narrative in games. You can read more of his work at his blog, the Ludosphere.
In Search of Full Sail
When I decided to write an article for this month’s GDAM (I didn’t know at that time that it would be this article), the first thing I did was to look up the word prototype. To my surprise, I found that it was rooted in a combination of the Old Greek words protos and typus: “first impression”. I thought that most game designers would find this to be a very appropriate definition.
Delving deeper into the etymology of the word, I found out that it was connected to the adjective ‘protean’ (someone or something taking on varied shapes), which in return was generated from the name of an oracular ancient deity with the name Proteus. At the very moment in which I decided to have a closer look at this deity, I had already triggered a trap: Before I even realized, I was thrown into an odyssey that would carry me through the vast seas of prototyping. Would I be able to find my way back home? Only the winds knew the answer.
Indeed, it is one of Odysseus’ close friends -Menelaus, husband of the beautiful Helen of Troy- who, in Homer’s Odyssea, mentions the name of Proteus. In an account of what happened to the many heroes of the Trojan War on the way back to their homes, Menelaus tells Telemakhos also the story of his own adventurous return to Lakedaimon (Odyssea, Chapter IV: In Lakedaimon, verses 350-570): He and his friends get stuck on the island of Pharos, where for weeks and weeks there is no wind to fill their sails. Eventually they find themselves plagued by scarcity and face starvation. The exhausted Menelaus finally realizes that the reason for this abnormal situation must be a curse of a god that he must have failed to please. But which one, and what wrong had he done? Obviously, only an oracle would be able to tell him these secrets. But where on this abandoned island could he find such a gifted person? It’s Eidothoe(Ido) who suggests him a solution: She says that he must seek the help of Proteus, a prophetic sea god that frequently visits the shores of Pharos with his flock of seals. There is a problem though: Proteus doesn’t like to share his wisdom with others, and should anyone attempt to force him to prophecize, then he pulls off some stunning tricks that help him to escape.
“Proteus possessed the gift of prophecy, a gift he could avoid using by utilizing his ability to metamorphose at will. In an instant he could become fire, flood, or wild beast. However, if a person held him fast, no matter what form he assumed, he would eventually return to his normal form and deliver the truth.” (Dixon-Kennedy; 1998: 263)
Menelaus, determined to escape the island, prepares a trap, and with the help of his friends he captures Proteus, who, after some wild shapeshifting, eventually normalizes and tells Menelaus the reason that got him stuck. With this vital information, Menelaus manages to bring back the winds and re-opens the sea routes that will lead him to his beloved lands of Lakedaimon.
I must admit that I was enchanted by this myth. It was a wonderful metaphor for prototyping and captured its essence perfectly. Let’s look at the elements of this myth:
• Metamorphoses: the ability to assume many forms in rapid succession.
• Prophecy: the revelation of the mistakes you were unaware of at the time you made them; and directives on what course to take in order to repair the damage that they have done.
• Exactitude (As an extension of the Prophecy element): The Oracle of Delphi carried the inscription “Know thyself!”, an inscription that has been often interpreted as “Know your problem!” or “Have a clearly formulated question!”. Otherwise the answer of the Oracle will sound cryptic and useless.
• Teamwork: You can’t fasten Proteus all by yourself; you need the help of a group of dedicated and determined people.
So, what’s prototyping then? Following the myth of Proteus, it is –together with your comrades– to hold tight onto the prototype –and your question!–, and not to allow yourselves to be fooled by the many shapes it will assume. If you’re determined enough and hold on tight, finally the prototype will be tamed: Your mistakes as well as the steps you need to take for the future will be revealed to you.
Now, as we seem to have some wind filling our sails, let’s move quickly to our next topic.
Working at the Pace of Mind
There are many fascinating things about prototypes and prototyping. We can summarize the most important points as follows:
• Sustainability: Prototyping is a (relatively) cheap and repeatable process.
• Flexibility: You can prototype almost anything, with anything (and anyone).
• Safety: You don’t risk to waste expensive code or art during or after experimentation. More than that, you protect yourself from wasting such expensive assets in the future, because the prototype will help you to tell into which assets to invest and into which ones not.
• Modularity (Scalability): Like a magnifying glass, you can zoom into particular game mechanics or zoom out to see the interactions between them.
• Responsiveness: Instantly make changes and receive feedback on them. A prototype is functional, interactive, up-and-running.
• Collaboration: Although it mostly starts alone, prototyping can be easily expanded to include friends, team members, producers and executives or members of the target audience.
• Control (Manageability): You can always take a step back and reconsider things, until you feel that you’ve cleared it all up and are ready to proceed with the next step. You have control over the goal, scope, ‘question(s)’ and what not’s of the process.
• Experimentation: (Almost) anything goes! It is the playground of the imaginative and innovative mind.
However, there is one thing that is the ultimate argument in favor of prototyping, and that is its pace and exactitude. These qualities can make them so persuasive that it made one game designer to speak of prototypes as “powerful ninjas” who can “move mountains” and “cut all debate with one swift movement” (Gingold, in Fullerton, 2008: 184). Is that to say that a prototype works at the pace of the mind? Not always, but probably it is the method closest to cope with the pace of the imaginative mind. And when it’s done well, a prototype becomes the sharpest of arguments, like the sword of a ninja.
…We’ve made quite some way already, but there is still a lot to discover in these waters… See those islands over there? Let’s go and check them out!
Altug Isigan is a scholar at the Eastern Mediterranean University, Department of Radio-TV and Film, in sunny Famagusta, Cyprus, where he is writing a dissertation on narrative in games. You can read more of his work at his blog, the Ludosphere.
Wednesday, June 17, 2009
Simplicity is the Glory of Prototyping
In this article, programmer Nels Anderson explains how to maximize the benefits of prototyping.
Prototyping is one of the most important phases of pre-production and it is important that the (likely limited) time spent prototyping is made as productive as possible. Some studios are renowned for the amount of resources dedicated to prototyping. Unfortunately, most do not have access to a bottomless wellspring of money and time. One way to help maximize the value of prototyping is to think of it as brainstorming with evaluation.
Ultimately, prototyping really is a collection of brainstormed ideas that have been taken farther than a white board or sticky notes. Keeping that spirit of brainstorming is important to successful prototyping. Successful brainstorm means getting through as many ideas as possible, not dwelling on minutia related to just a few ideas. Similarly, it's important not to dwell on details while evaluating prototypes. This means prototyping as quickly as possible.
As my background and daily work is partially in engineering, it pains me to write this, but prototypes should not be coded unless they absolutely must. There's simply too much setup time involved in getting code prototypes up and running. There's a feeling of tangibility and permanence that can come with coded prototypes, which can be detrimental to rapid iteration. Use paper prototypes whenever possible, because no matter how good your programmers are, heavy stock paper, scissors and markers are faster. When prototypes require code, still push for as much expeditiousness as possible. Use Flash, Director, Panda3D or even Unity if you have a team member familiar with such. Steal as much existing work as you can, from other projects, public mods (if appropriate), wherever you can. And, above all else, plan to throw any code you write away before starting the project in earnest.
A fantastic example of this is when EA Blackwood was prototyping Skate. The prototyping team connected the control logic to a simple text output. No animation or rendering at all. But this prototype let the team gain a clear understanding of how the game would feel and that it was enjoyable to play.
Also, always include an artist in your prototyping. Not only can this help visualize what a prototype can grow into, but much of the initial creative process occurs during prototyping. Having an artist supporting the prototyping can keep those creative juices flowing and take things in directions that simply might not happen solely with written and spoken brainstorming. But as with the engineers, artists during prototypes must work as quickly as possible. Several rough sketches with only a small area coloured and filled in with detail are far more useful than a single immaculate, detailed and coloured piece. Be as broad with art prototypes as possible and don't emphasize areas of the prototype that are vague or likely to be changed.
Lastly, include audio in prototypes, especially music. As much as an artist can help evoke certain aesthetics during the prototype, music can help establish thematic tones that will take prototypes in more valuable directions. It gives a prototype more substance and can help you visualize what a more complete experience will feel like. Even if it's just a paper prototype, play some thematically similar music on a stereo in the background. Kyle Gabler, one of the developers of World of Goo, advocates getting music into your game as soon as possible, possibly even before you have a solid idea of what your game actually is. Use temp tracks if you must, but do be careful about inadvertently falling in love with them.
I believe the value of prototyping is directly proportional to the number of iterations that can be achieved. Do whatever you can to make that prototyping faster, more substantive and more evocative. The more ideas that can be brainstormed and evaluated, the more likely it is you're going to hit on something truly fantastic.
Nels Anderson is a programmer at Hothead Games. He's probably the only game developer in Vancouver (and maybe all ofCanada ) that was born and raised in Wyoming
Prototyping is one of the most important phases of pre-production and it is important that the (likely limited) time spent prototyping is made as productive as possible. Some studios are renowned for the amount of resources dedicated to prototyping. Unfortunately, most do not have access to a bottomless wellspring of money and time. One way to help maximize the value of prototyping is to think of it as brainstorming with evaluation.
Ultimately, prototyping really is a collection of brainstormed ideas that have been taken farther than a white board or sticky notes. Keeping that spirit of brainstorming is important to successful prototyping. Successful brainstorm means getting through as many ideas as possible, not dwelling on minutia related to just a few ideas. Similarly, it's important not to dwell on details while evaluating prototypes. This means prototyping as quickly as possible.
As my background and daily work is partially in engineering, it pains me to write this, but prototypes should not be coded unless they absolutely must. There's simply too much setup time involved in getting code prototypes up and running. There's a feeling of tangibility and permanence that can come with coded prototypes, which can be detrimental to rapid iteration. Use paper prototypes whenever possible, because no matter how good your programmers are, heavy stock paper, scissors and markers are faster. When prototypes require code, still push for as much expeditiousness as possible. Use Flash, Director, Panda3D or even Unity if you have a team member familiar with such. Steal as much existing work as you can, from other projects, public mods (if appropriate), wherever you can. And, above all else, plan to throw any code you write away before starting the project in earnest.
A fantastic example of this is when EA Blackwood was prototyping Skate. The prototyping team connected the control logic to a simple text output. No animation or rendering at all. But this prototype let the team gain a clear understanding of how the game would feel and that it was enjoyable to play.
Also, always include an artist in your prototyping. Not only can this help visualize what a prototype can grow into, but much of the initial creative process occurs during prototyping. Having an artist supporting the prototyping can keep those creative juices flowing and take things in directions that simply might not happen solely with written and spoken brainstorming. But as with the engineers, artists during prototypes must work as quickly as possible. Several rough sketches with only a small area coloured and filled in with detail are far more useful than a single immaculate, detailed and coloured piece. Be as broad with art prototypes as possible and don't emphasize areas of the prototype that are vague or likely to be changed.
Lastly, include audio in prototypes, especially music. As much as an artist can help evoke certain aesthetics during the prototype, music can help establish thematic tones that will take prototypes in more valuable directions. It gives a prototype more substance and can help you visualize what a more complete experience will feel like. Even if it's just a paper prototype, play some thematically similar music on a stereo in the background. Kyle Gabler, one of the developers of World of Goo, advocates getting music into your game as soon as possible, possibly even before you have a solid idea of what your game actually is. Use temp tracks if you must, but do be careful about inadvertently falling in love with them.
I believe the value of prototyping is directly proportional to the number of iterations that can be achieved. Do whatever you can to make that prototyping faster, more substantive and more evocative. The more ideas that can be brainstormed and evaluated, the more likely it is you're going to hit on something truly fantastic.
Nels Anderson is a programmer at Hothead Games. He's probably the only game developer in Vancouver (and maybe all of
Saturday, June 13, 2009
July 2009 Poll
Please come and vote for the July 2009 topic!
You'll see the poll to the side. The choices are:
Please choose by June 19, 2009!
You'll see the poll to the side. The choices are:
- Mature Games (Games for Grown-Ups)
- Multiplayer Economies
- Cheats
Please choose by June 19, 2009!
Monday, June 8, 2009
Prototyping: Do it Quick + Dirty
In this article, creative director Eitan Glinert describes the process of prototyping that has worked for his company, Fire Hose Games.
So you've got an idea for a game, but you're missing an artist, you don't have the design nailed down, you need to find funding, and you don't know what platform you're going to develop for, you're not sure that the concept is even feasible, or you [insert development hurdle of your choice here]. How do you even start? With prototyping!
Prototyping is the process of making a small, crappy, slapped-together version that demonstrates certain key aspects of your final vision. It's a great way to start making games since it is far less daunting, and during the process you'll learn a lot about what you should actually do in the full version. Prototypes are throw away, but that's a good thing since it'll give you more freedom to experiment in ways you might not normally try.
Starting out
Take stock of what you have, and make a list of your strengths and weaknesses. When we started out at Fire Hose we were 3 MIT nerds with a good amount of design experience. We were especially good at programming and game design, but we completely sucked when it came to art and we had almost no money whatsoever. As a result, we decided to focus on the technology and design, and to just rip off artwork from other games. A larger, more established studio might have strengths of lots of money and a large code base, but weaknesses of time and manpower. Whatever the case may be it's important to focus on what you're good at and (for the time being) ignore the rest.
Scoping is really important as it dictates how big the prototype will be. We recommend making a few rounds of prototypes, starting with quick + dirty one day versions, then a 1-3 week build, and then a 2 or 3 month final prototype which is a good vertical slice of what the game eventually might feel like. Of course this will vary team by team, as larger groups can accomplish more, and not everyone has 3 months or so to devote to prototyping (though we certainly recommend spending at least that long if you can afford it). It's worth noting that there is a limit to how big a prototyping team should be; larger than 10 people will probably not be useful since the goal is NOT to make a final version, but just something quick and dirty that can be tested. We find that 3 – 4 people can do a good job of rapidly comping up with something worth playing with.
Let the development begin!
Once you've got your team, get to it! Remember, the standard rules of development don't apply, so feel free to take shortcuts. Want to steal assets/code from other games? Go for it! Want to use stand in, crummy programmer art? Why not! Code in whatever is faster, not most robust (i.e. python, not C). In fact, you should do whatever is necessary to get it done quickly. We've done prototypes where someone sits behind the monitor and reads the spoken parts to the user, pretending to be the computer. Don't feel bad about taking such shortcuts, remember that it's all throw away anyway.
The one rule that DOESN'T change during early prototyping is that you need to test, test, test. In fact, you should be testing more than you normally do, since you're probably throwing more new features in front of your users now than during any other part of development. Test on a weekly basis, ask lots of questions, and try to direct users towards rating the features you actually care about (but don't be leading when you do this!) It's amazing how much users are willing to forgive when they are presented with an obviously half-assed prototype, so don't feel bad about asking for feedback.
Finish the job!
It's easy to stop after making one prototype and calling it a day, but don't stop there! Analyze testing results and iterate on the prototype, taking what you've learned and making it better in the next version. Feel free to try out completely new, different, orthogonal, or contrary features/designs in subsequent builds, since you're trying to learn more about what will work. You should also start looking to fix your weaknesses during this phase – hire that artist, find more funding, or start putting together a schedule that is actually appropriate for the full title.
Deadlines are your friends, so be sure to schedule them in. It's easy to just keep iterating with prototypes forever, don't fall into this rut. Set hard deadlines for when you will finish certain versions and stick to them. Testing days are generally useful as deadlines since it'll force you to have finished builds that users can play with.
And when you're done...
Throw the prototype away and start fresh! Trust me, this is the right thing to do. It feels rotten since you've spent a lot of time working on it, but you can't build off of a hacked together prototype full of spaghetti code, stolen assets, and written in a non-robust language. Prototypes serve a purpose, but should not turn into a final game. The main things that should survive are the design and lessons learned.
Eitan Glinert is Fire Hose Games' founder and creative director. Before Fire Hose, Eitan spent several years making educational and accessible games, including AudiOdyssey, the first Wii Remote game accessible to the blind. If you have any questions on prototyping, feel free to contact Eitan Glinert at this e-mail address.
So you've got an idea for a game, but you're missing an artist, you don't have the design nailed down, you need to find funding, and you don't know what platform you're going to develop for, you're not sure that the concept is even feasible, or you [insert development hurdle of your choice here]. How do you even start? With prototyping!
Prototyping is the process of making a small, crappy, slapped-together version that demonstrates certain key aspects of your final vision. It's a great way to start making games since it is far less daunting, and during the process you'll learn a lot about what you should actually do in the full version. Prototypes are throw away, but that's a good thing since it'll give you more freedom to experiment in ways you might not normally try.
Starting out
Take stock of what you have, and make a list of your strengths and weaknesses. When we started out at Fire Hose we were 3 MIT nerds with a good amount of design experience. We were especially good at programming and game design, but we completely sucked when it came to art and we had almost no money whatsoever. As a result, we decided to focus on the technology and design, and to just rip off artwork from other games. A larger, more established studio might have strengths of lots of money and a large code base, but weaknesses of time and manpower. Whatever the case may be it's important to focus on what you're good at and (for the time being) ignore the rest.
Scoping is really important as it dictates how big the prototype will be. We recommend making a few rounds of prototypes, starting with quick + dirty one day versions, then a 1-3 week build, and then a 2 or 3 month final prototype which is a good vertical slice of what the game eventually might feel like. Of course this will vary team by team, as larger groups can accomplish more, and not everyone has 3 months or so to devote to prototyping (though we certainly recommend spending at least that long if you can afford it). It's worth noting that there is a limit to how big a prototyping team should be; larger than 10 people will probably not be useful since the goal is NOT to make a final version, but just something quick and dirty that can be tested. We find that 3 – 4 people can do a good job of rapidly comping up with something worth playing with.
Let the development begin!
Once you've got your team, get to it! Remember, the standard rules of development don't apply, so feel free to take shortcuts. Want to steal assets/code from other games? Go for it! Want to use stand in, crummy programmer art? Why not! Code in whatever is faster, not most robust (i.e. python, not C). In fact, you should do whatever is necessary to get it done quickly. We've done prototypes where someone sits behind the monitor and reads the spoken parts to the user, pretending to be the computer. Don't feel bad about taking such shortcuts, remember that it's all throw away anyway.
The one rule that DOESN'T change during early prototyping is that you need to test, test, test. In fact, you should be testing more than you normally do, since you're probably throwing more new features in front of your users now than during any other part of development. Test on a weekly basis, ask lots of questions, and try to direct users towards rating the features you actually care about (but don't be leading when you do this!) It's amazing how much users are willing to forgive when they are presented with an obviously half-assed prototype, so don't feel bad about asking for feedback.
Finish the job!
It's easy to stop after making one prototype and calling it a day, but don't stop there! Analyze testing results and iterate on the prototype, taking what you've learned and making it better in the next version. Feel free to try out completely new, different, orthogonal, or contrary features/designs in subsequent builds, since you're trying to learn more about what will work. You should also start looking to fix your weaknesses during this phase – hire that artist, find more funding, or start putting together a schedule that is actually appropriate for the full title.
Deadlines are your friends, so be sure to schedule them in. It's easy to just keep iterating with prototypes forever, don't fall into this rut. Set hard deadlines for when you will finish certain versions and stick to them. Testing days are generally useful as deadlines since it'll force you to have finished builds that users can play with.
And when you're done...
Throw the prototype away and start fresh! Trust me, this is the right thing to do. It feels rotten since you've spent a lot of time working on it, but you can't build off of a hacked together prototype full of spaghetti code, stolen assets, and written in a non-robust language. Prototypes serve a purpose, but should not turn into a final game. The main things that should survive are the design and lessons learned.
Eitan Glinert is Fire Hose Games' founder and creative director. Before Fire Hose, Eitan spent several years making educational and accessible games, including AudiOdyssey, the first Wii Remote game accessible to the blind. If you have any questions on prototyping, feel free to contact Eitan Glinert at this e-mail address.
Friday, May 29, 2009
The Cost of Simplicity
In this article, game designer Ryon Levitt explores how the spiraling cost of game development leads to simpler and more polished games.
As a designer and long time gamer, I learned one important aspect of simplicity in games the hard way - costs. Cost is something that is not often considered by players and even new arrivals to the design field. Sure, people toss around budget approximations (a $10,000,000 budget) but until you've entered the industry and dealt with the budget, the number exists in a black box. Even as a programmer, budget wasn't something you think about. You're told what you need to get done by when, and you do your best to achieve it. But when you get down into the thick of it, cost controls a lot of what can and cannot be done in a project.
It is a fact that as long as you are working for someone who controls the money, proper budgeting is going to be an important, though perhaps unfortunate, aspect of the game design. Every man-hour costs money and needs to be budgeted for based on the expected size of the team at any given point in the process. Without going much deeper into budgeting (since 1] I don't know too much on the subject, and 2] Budgeting will likely need a GDAM Topic of its own), it is safe to say that not everything that every designer wants to put into the game can get in and still have the game released withing a schedule that is "in budget". Furthermore, based on the specifics of the game (such as genre), not every part of the game will cost the same.
With that in mind, we can already see one potential reason for games to have gotten simpler (or at least easier) in more recent years. With the move from sprite-based games to full 3D games, the cost of many aspects have gone up significantly. As a simple example, look at someone likeMegaman or Mario in one of their later 2D titles. A common action like Jumping was pretty "easy". Make a number of 2D sprites to create the animation and then program in a timing to switch between them while moving them. It was okay if they didn't look very dynamic or realistic; it was just a limitation of the medium.
But lets now look at more modern 3D animation. Search YouTube for gameplay videos ofGod of War, Heavenly Sword, or Ninja Gaiden (post 2004). Characters are expected to move and behave realistically. If a character is too stiff, it is usually frowned upon. Now we need modeling teams, animation teams, motion capture actors, cloth simulations, etc. This means, of course, that more people are getting paid, which translates to higher cost.
Now this is just a simple example, but this translates to a big issue - the more complicated something is, the more it costs, not just in making it, but also in testing it. Someone needs to make sure that characters don't jump into objects or fall through the ground when they land, or any number of other potential bugs that may be possible with all the new technology being used today. Not only that, for every character that is made to not be a carbon copy of any other character, the cost gets duplicated. Suddenly something that seems small - adding one more character - is greatly increasing the costs.
And with mentioning Carbon Copying, I bring up one of the many ways that various teams cut costs - they take short cuts. While this usually seems like a good way to bring the development back down to budget, the end users - the gamers - don't get to see that. All they end up seeing is the end result, and if the "wrong" things were cut, we end up with dissatisfied fans who feel cheated.
This is where cost-performance usually comes in. Various aspects within a game can be reused more easily than others. Easily, in this case, being factored both in usability - Does the object/action/system fit in other places within the game? - and fun - Will this object/action/system be fun the second or third time around? Aspects that are hard to reuse in both cases are far more expensive than aspects that are easy to reuse.
As an example, if a Dragon boss has a special fire breath attack that it only uses on hard difficulties per spec, this as an idea alone can be quite interesting. This boss has a new feature that can improve replayability if played again on a harder difficulty level - great. But is it feasible to put in? Well, by spec, it cannot be used in the lower difficulty levels, though it may be usable elsewhere in the game. However, if the ability was supposed to be a surprise new ability for the player to deal with, it cannot really be used in too many other places before it stops being a surprise and falls to common. As such, the threat of staleness limits its use. Furthermore, the average gamer does not play their first playthrough on Hard - if they did, this wouldn't be speced as an ability to promote replayability. In addition, many gamers do not have the time anymore to play a game through multiple times. This means that over 50-60% of players (probably closer to 75-90%) may never even see this feature of the game. This means that what started out as an interesting way to balance out a particular fight across difficulty settings - a feature that requires particle effects to display the attack, sound effects to follow along, AI to determine when to use it, collision checking to find out who got hit, and hours of QA making sure it happens when it should, doesn't when it shouldn't, behaves correctly, looks good, etc. - has had money spent on it that could have been perhaps better spent on something that more people would see.
Now multiply this again for every other boss in this hypothetical game. A lot of money may have just gotten wasted on a game balance that almost never gets seen. So we throw it out - toss out all these little features that would possibly make the hardcore gamers wet with glee because in the grand scheme of thing, they are the minority of gamers today. And not only are they a minority, they're really difficult to please. What do you put into a game for a player that has seen everything and yet make it accessible, fun for all, and cheap?
Finding a way to give every gamer what they want at cost is a daunting task, but with a bit of creative finagling and a little bit of love, it can be possible to find one. But until then, it may be better to have a slightly simpler but solid and polished game, than one that provides too much but feels incomplete.
Ryon Levitt is a programmer-turned-designer for KOEI, currently working at their main branch in Yokohama, Japan. He is currently working on his first title as a designer. Ryon is one of the founding members of the IGDA Game Design SIG, and helped coin the acronym GDAM.
As a designer and long time gamer, I learned one important aspect of simplicity in games the hard way - costs. Cost is something that is not often considered by players and even new arrivals to the design field. Sure, people toss around budget approximations (a $10,000,000 budget) but until you've entered the industry and dealt with the budget, the number exists in a black box. Even as a programmer, budget wasn't something you think about. You're told what you need to get done by when, and you do your best to achieve it. But when you get down into the thick of it, cost controls a lot of what can and cannot be done in a project.
It is a fact that as long as you are working for someone who controls the money, proper budgeting is going to be an important, though perhaps unfortunate, aspect of the game design. Every man-hour costs money and needs to be budgeted for based on the expected size of the team at any given point in the process. Without going much deeper into budgeting (since 1] I don't know too much on the subject, and 2] Budgeting will likely need a GDAM Topic of its own), it is safe to say that not everything that every designer wants to put into the game can get in and still have the game released withing a schedule that is "in budget". Furthermore, based on the specifics of the game (such as genre), not every part of the game will cost the same.
With that in mind, we can already see one potential reason for games to have gotten simpler (or at least easier) in more recent years. With the move from sprite-based games to full 3D games, the cost of many aspects have gone up significantly. As a simple example, look at someone like
But lets now look at more modern 3D animation. Search YouTube for gameplay videos of
Now this is just a simple example, but this translates to a big issue - the more complicated something is, the more it costs, not just in making it, but also in testing it. Someone needs to make sure that characters don't jump into objects or fall through the ground when they land, or any number of other potential bugs that may be possible with all the new technology being used today. Not only that, for every character that is made to not be a carbon copy of any other character, the cost gets duplicated. Suddenly something that seems small - adding one more character - is greatly increasing the costs.
And with mentioning Carbon Copying, I bring up one of the many ways that various teams cut costs - they take short cuts. While this usually seems like a good way to bring the development back down to budget, the end users - the gamers - don't get to see that. All they end up seeing is the end result, and if the "wrong" things were cut, we end up with dissatisfied fans who feel cheated.
This is where cost-performance usually comes in. Various aspects within a game can be reused more easily than others. Easily, in this case, being factored both in usability - Does the object/action/system fit in other places within the game? - and fun - Will this object/action/system be fun the second or third time around? Aspects that are hard to reuse in both cases are far more expensive than aspects that are easy to reuse.
As an example, if a Dragon boss has a special fire breath attack that it only uses on hard difficulties per spec, this as an idea alone can be quite interesting. This boss has a new feature that can improve replayability if played again on a harder difficulty level - great. But is it feasible to put in? Well, by spec, it cannot be used in the lower difficulty levels, though it may be usable elsewhere in the game. However, if the ability was supposed to be a surprise new ability for the player to deal with, it cannot really be used in too many other places before it stops being a surprise and falls to common. As such, the threat of staleness limits its use. Furthermore, the average gamer does not play their first playthrough on Hard - if they did, this wouldn't be speced as an ability to promote replayability. In addition, many gamers do not have the time anymore to play a game through multiple times. This means that over 50-60% of players (probably closer to 75-90%) may never even see this feature of the game. This means that what started out as an interesting way to balance out a particular fight across difficulty settings - a feature that requires particle effects to display the attack, sound effects to follow along, AI to determine when to use it, collision checking to find out who got hit, and hours of QA making sure it happens when it should, doesn't when it shouldn't, behaves correctly, looks good, etc. - has had money spent on it that could have been perhaps better spent on something that more people would see.
Now multiply this again for every other boss in this hypothetical game. A lot of money may have just gotten wasted on a game balance that almost never gets seen. So we throw it out - toss out all these little features that would possibly make the hardcore gamers wet with glee because in the grand scheme of thing, they are the minority of gamers today. And not only are they a minority, they're really difficult to please. What do you put into a game for a player that has seen everything and yet make it accessible, fun for all, and cheap?
Finding a way to give every gamer what they want at cost is a daunting task, but with a bit of creative finagling and a little bit of love, it can be possible to find one. But until then, it may be better to have a slightly simpler but solid and polished game, than one that provides too much but feels incomplete.
Ryon Levitt is a programmer-turned-designer for KOEI, currently working at their main branch in Yokohama, Japan. He is currently working on his first title as a designer. Ryon is one of the founding members of the IGDA Game Design SIG, and helped coin the acronym GDAM.
Wednesday, May 27, 2009
Building Bridges (Part II)
In Part I, QA tester and aspiring game designer Kumar Daryanani looks at the hardcore/casual dichotomy and gives suggestions on how game developers can bridge the gap between hardcore and casual players. In Part II, he explains why asymmetrical gameplay may provide the answers.
The question of what games to make is a simple one: we give them exactly what they wish for, games that a core gamer can play with their casual or non-gamer loved ones. The major problem with this, or rather, the big opportunity, is that these games haven't been made yet. There are ideas out there, waiting to materialize. A perfect example, and one that serves the game industry on many levels, is Sande Chen's idea of 'date games'. These are short games, maybe 2-3 hours long, that a young couple can play as a date. These games could prove to be a perfect new market for developers, as well as serving the purpose of maintaining young girls' interest in video games until they reach college, at which point they have the option of choosing to pursue games as a career. Developers have been asking how to change the lopsidedness of gender demographics in the industry for a long time now, and these seems a likely solution. It would also have the effect of keeping girls and young women in the market for video games, which is also a good thing. Both these factors could very well be the push the industry needs towards more mature games with a wider appeal than the current offering, which in turn could mean that video games as a whole gain a new level of legitimacy and cultural relevance.
Date games also tackle another incipient problem in the current game development environment: length. Developers face the constant struggle of creating games that are fun but finite. Since a game that is too short is perceived as not being good value for money, and one that is too long risks detracting from sales of future games because players are still enjoying it after the initial investment, developers are faced with the problem of how long to make a game. With short-form games like these, Developers could create an engine and then develop 2-3 hour long games that can be sold in an episodic fashion or as DLC. This would help offset development costs, since developers could use the same engine to create a number of different games with an accessible price point. In essence, they could create a new business model where games are closer to a service, such as movie rentals, as opposed to a physical product. With the wide variety of options available to deliver downloadable content to consumers, date games could mark an evolutionary step for episodic content, and for the monetization of games as a whole.
Why stop at date games, though? We could just as easily create games that can be played by parents and their children, dispensing with the notion that video games for young children, and creating the perfect opportunity for familial quality time and bonding experiences. In the same way, we could create games for adults to share with their older parents, for couples to play together.
In my mind, the key features of these games are cooperation and asymmetrical gameplay. Cooperation because working together towards a goal is more conducive to a shared experience, since both players participate in success and failure, and since neither benefits from the other's loss. Asymmetrical gameplay in order to cater to the relative strengths of each, and to allow both players to experience different aspects of the game at different times.
In the discussion following Sande Chen's post on her Gamasutra blog, a few good examples of hypothetical games sprang up, but I want to use an existing game to illustrate the concept: consider the game Henry Hatsworth and the Puzzling Adventure. The game is a single player 2D platform game with an element of match-3 puzzle game that is used in a clever and seamless way to add another layer of depth to the platforming elements. Now imagine that the developers had added a multiplayer game mode, where one player controls the 2D platforming action with the D-pad and the face buttons, while the second player controls the match-3 puzzle game element with the stylus. This is a perfect example of how to integrate a casual gameplay mechanic with a core one. Personally, I could picture a parent playing the game with a child in this manner, with the child sitting in the parent's lap.
The other great advantage of a game like this would be that each player could see what the other was doing. This would mean that a casual gamer would get a first-row seat to how the core gamer traverses the obstacles on the screen. Ideally, at some point, one of the two players would suggest that they switch roles, and the casual gamer would get to experience the core aspects of the game while the core gamer helps them in-game and with advice or coaching on how to proceed if needed.
Games like these would not only be the perfect way of bridging the casual/core divide, but would also appeal to a larger proportion of gamers than strictly the casual or core segments. They would also be perfect grounds for creating new types of games. By exposing casual and non-gamers to core games in a cozy environment, we could increase the 'stickiness' of core game mechanics and the potential buyers for future core games.
Perhaps these games could be a cornerstone of the Gaming Renaissance Movement that Wanda Meloni foretells. Perhaps they could play a part in this recession doing for video games what the Great Depression did for movies. Perhaps they could be the standard that rallies core gamers to the Wii, or the means by which Sony and Microsoft break Nintendo's dominance in the current console generation.
Kumar Daryanani is a QA tester, videogame enthusiast and aspiring game designer. He currently resides in the San Francisco Bay Area with his wife. He keeps a blog where he writes about various aspects of video games.
The question of what games to make is a simple one: we give them exactly what they wish for, games that a core gamer can play with their casual or non-gamer loved ones. The major problem with this, or rather, the big opportunity, is that these games haven't been made yet. There are ideas out there, waiting to materialize. A perfect example, and one that serves the game industry on many levels, is Sande Chen's idea of 'date games'. These are short games, maybe 2-3 hours long, that a young couple can play as a date. These games could prove to be a perfect new market for developers, as well as serving the purpose of maintaining young girls' interest in video games until they reach college, at which point they have the option of choosing to pursue games as a career. Developers have been asking how to change the lopsidedness of gender demographics in the industry for a long time now, and these seems a likely solution. It would also have the effect of keeping girls and young women in the market for video games, which is also a good thing. Both these factors could very well be the push the industry needs towards more mature games with a wider appeal than the current offering, which in turn could mean that video games as a whole gain a new level of legitimacy and cultural relevance.
Date games also tackle another incipient problem in the current game development environment: length. Developers face the constant struggle of creating games that are fun but finite. Since a game that is too short is perceived as not being good value for money, and one that is too long risks detracting from sales of future games because players are still enjoying it after the initial investment, developers are faced with the problem of how long to make a game. With short-form games like these, Developers could create an engine and then develop 2-3 hour long games that can be sold in an episodic fashion or as DLC. This would help offset development costs, since developers could use the same engine to create a number of different games with an accessible price point. In essence, they could create a new business model where games are closer to a service, such as movie rentals, as opposed to a physical product. With the wide variety of options available to deliver downloadable content to consumers, date games could mark an evolutionary step for episodic content, and for the monetization of games as a whole.
Why stop at date games, though? We could just as easily create games that can be played by parents and their children, dispensing with the notion that video games for young children, and creating the perfect opportunity for familial quality time and bonding experiences. In the same way, we could create games for adults to share with their older parents, for couples to play together.
In my mind, the key features of these games are cooperation and asymmetrical gameplay. Cooperation because working together towards a goal is more conducive to a shared experience, since both players participate in success and failure, and since neither benefits from the other's loss. Asymmetrical gameplay in order to cater to the relative strengths of each, and to allow both players to experience different aspects of the game at different times.
In the discussion following Sande Chen's post on her Gamasutra blog, a few good examples of hypothetical games sprang up, but I want to use an existing game to illustrate the concept: consider the game Henry Hatsworth and the Puzzling Adventure. The game is a single player 2D platform game with an element of match-3 puzzle game that is used in a clever and seamless way to add another layer of depth to the platforming elements. Now imagine that the developers had added a multiplayer game mode, where one player controls the 2D platforming action with the D-pad and the face buttons, while the second player controls the match-3 puzzle game element with the stylus. This is a perfect example of how to integrate a casual gameplay mechanic with a core one. Personally, I could picture a parent playing the game with a child in this manner, with the child sitting in the parent's lap.
The other great advantage of a game like this would be that each player could see what the other was doing. This would mean that a casual gamer would get a first-row seat to how the core gamer traverses the obstacles on the screen. Ideally, at some point, one of the two players would suggest that they switch roles, and the casual gamer would get to experience the core aspects of the game while the core gamer helps them in-game and with advice or coaching on how to proceed if needed.
Games like these would not only be the perfect way of bridging the casual/core divide, but would also appeal to a larger proportion of gamers than strictly the casual or core segments. They would also be perfect grounds for creating new types of games. By exposing casual and non-gamers to core games in a cozy environment, we could increase the 'stickiness' of core game mechanics and the potential buyers for future core games.
Perhaps these games could be a cornerstone of the Gaming Renaissance Movement that Wanda Meloni foretells. Perhaps they could play a part in this recession doing for video games what the Great Depression did for movies. Perhaps they could be the standard that rallies core gamers to the Wii, or the means by which Sony and Microsoft break Nintendo's dominance in the current console generation.
Kumar Daryanani is a QA tester, videogame enthusiast and aspiring game designer. He currently resides in the San Francisco Bay Area with his wife. He keeps a blog where he writes about various aspects of video games.
Subscribe to:
Posts (Atom)
Posts
