Assigned Date: Thursday, Sep. 7, 2006
Due Date: Friday, Sep. 29, 2006
Due Time: 11:55pm
|Deadline is extended to Friday...|
Last modified on October 24, 2006, at 03:47 PM (see updates)
This assignment focuses on game concept development, on exploring (exploiting?) device and human limitations, and on Python programming.
Theme: Developing games that truly satisfy their players takes more than technical skill and bleeding-edge graphics.
(see Daniel Terdiman, What's wrong with serious games?, C|NET, March 2006.)
Develop a new, exciting game concept for ASCII platforms. Implement a prototype in Python.
Things to consider: Target audience, purpose of game, game objects, game actions, reward structure.
Also: Genre, learning curve, difficulty, after-game effect, personality types.
- Monday, Sep. 11, 11:55pm: Send email with, at least, two different game concepts.
- Wednesday, Sep. 20, 11:55pm: Submit game prototype on the Wiki (details soon). Be ready to present your game in class (in 10 minutes or less).
One of the most important aspects of game development is coming up with a game concept that grabs the user. Another is to understand and fully utilize device constraints. For example, consider Tennis for Two, and Pong.
Successful games do not necessarily need expensive, high-definition graphics platforms. For example, consider Tetris.
According to DouglasAdams.com
There was a time when computer games didn't have graphics. Or at least they couldn't have graphics and sound at the same time. They certainly couldn't have graphics, sound and enough content to keep even a human being amused for more than a few minutes. So they had text. This was radical - a computer game you could control by typing in commands. The game would then respond to your commands with a breathtakingly prescient understanding of your intent. Or not. Usually not - the early text parsers (circa 1977) weren't that bright. But, as long as you limited yourself to what the game understood and the game designers wrote creatively enough to misunderstand you in a humorous and entertaining fashion, it all worked. It therefore stands to reason that any game which combined a really good programmer with a really good writer was likely to do well. So when Steve Meretzky of Infocom got together with Douglas Adams to create a game based around the Hitchhiker's Guide to the Galaxy, the result was never going to be less than interesting and more than likely insane. So it proved - the Hitchhiker's Guide adventure game was one of the best-selling games of its era, selling some 350,000 copies. In 1984.
Then graphics games came along and the computer using portion of the human race forgot all about 500,000 years of language evolution and went straight back to the electronic equivalent of banging rocks together - the point'n'click game. Infocom and most of its competitors went to the wall - signaling the arrival of the post-literate society. That's the way it's been for most of the last dozen years.
- Game should be innovative, easy to learn, "addicting".
- It is not about realism, but about how much the game grabs you.
- The game concept should be easy to grasp (e.g., falling blocks, a ping-pong ball and two rackets, a person wondering in a maze, etc.)
- You should be able to describe it in one, simple sentence.
- Be innovative here, and you'll have a hit!
- Concept should build on user's knowledge about the world (shallow learning curve) - know your user.
- Respect limits on human capacity for processing information:
- Interactive objects should be 7 or less.
- Actions per object should be 7 or less.
- Game should be easy to play (but not too easy). Achieve a balance between user effort and reward.
- If user gets rewards for little effort, game is boring.
- If user has to work too hard for a reward, game is difficult and most likely will be abandoned.
- Game should fit well within device capabilities/constraints (e.g., don't try to simulate extensive graphic action in ASCII).
- Understand and respect device constraints.
- Even better, turn device limitations to your advantage.
- Game should have quick, intermediate rewards (e.g., falling blocks that connect well to their environment, if manipulated properly).
- Design your reward structure.
- Keep it simple, but not too simple.
- Consider hierarchical rewards (e.g., small, medium, large). Several small rewards create a medium reward, etc.
- Keep rewards at each level to 7 or less.
- Keep reward levels to three or less.
- Consider generating an after-game artifact as a reward for good game playing (e.g., art, music, poem, solution to a problem, etc.).
- Be innovative here, and you'll have a hit!
- You may even win the Nobel price!
- Miller, G.A. (1956), "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information", The Psychological Review, vol. 63, pp. 81-97.
- Wikipedia, Computer and video game genres.
- Wikipedia, Text-based Games.
- Wikipedia, Roguelike computer games. Action games for ASCII platforms.
"Though they may seem like trivial games at a first glance because of their simple graphics and interface, roguelikes usually provide a much greater gameplay detail depth than average commercial games. Instead of spending a lot of time on the graphics and 3D engines roguelike developers focus on advancing gameplay."
- Iowa State University News Service, ISU psychologists produce first study on violence desensitization from video games, July 24, 2006.
- Chris Bateman, Designing Rewards in Games.
- Addicting Games (some content may be offensive).
- Text Twist - rearrange the letters to make as many words as you can.
- François-Dominic Laramée, 3D Graphics are the Spawn of Satan, GameDev.net, November 1999.
- Jung Personality Test, Find out which personality type you are.
Submit your solution by editing your page using the provided template.
Michael Baker, Brian Cherry,
Dennis Crenshaw, Justin Dorman,
Luca Pellicoro, Bryan Peterson,
Patrick Roos, Matthew Roth,