Inertia's picture

What turns games into fun? Part 1/2

First of all: Merry Christmas :-)

WARNING: Similar to learning how a magic trick works, this document may kill the fun in playing video games. READ IT AT YOUR OWN RISK.

I wrote this 2003 as some sort of summary/reminder of some books I read on board- and video- game design and recently found a backup. This is the english translation of that document. Please excuse any yoda-grammar, it's kinda hard to track when translating. (Corrections welcome)

It is not a replacement for real books where authors share "why this worked, but that didn't" experiences and should not be understood as a step-by-step guide, but rather an attempt to look at what makes games fun objectively from a programmer's point of view. It's focus is the interaction of a single player with the machine (or a board) and some psychological implications, but does not look at any social aspects of multiplayer games. (Maybe it will in a future part 3)

1) What's fun to play?

It has nothing to do with story, characters or pretty presentation. Those can enhance the experience, but unless you're a fan(atic), reading a story for the second time isn't half as exciting as reading it the first time. Graphics might help screenshots look good, but the player is usually quickly saturated and doesn't accept it as an entertainment factor in itself. No doubt though, when done right both can enrich a good gameplay tremendously.

After getting that out of the way, back to the initial question:

Essentially it all boils down to action and reaction. Each iteration, the game accepts user input, applies certain rules and finally updates the playfield to communicate it to the user. Action and reaction. The user now may respond to the new situation by another action and so on. In traditonal board-games, players do provide each other with reactions to the opponent's actions, defined by a commonly agreed-to set of rules. In a video game against AI, it's the programmer's job to provide those.

The actions from which the user may chose from must be interesting and meaningful on their own. These options are usually present for the whole duration of the game, otherwise you have multiple games in one. If a functional prototype of the game is not fun with debug graphics, no miracle will happen and it will not become fun with state-of-the-art graphics.

2.a) User Interface

The interface is the communication center between player and machine and requires alot of dedication. It's recommended that, even before you start with a design document, you sit down and write down all possible actions of the player with the playfield. Each of these actions has to be implemented, tuned and debugged. Another problem ist that if you use too many, overview will be difficult for the player. Use too few and there is no real choice left.

A rather good example are the adventure games by Lucasarts, in which all the player's actions are verbs which are used to manipulate nouns (people, objects, etc.). The whole game can be solved by the following actions: Go To, Look At, Open, Close, Pull, Push, Use, Give, Pick Up and Talk To.

Later versions of their games have simplified the actions to: Hand (Open, Close, Pull, Push, Use, Take, Give and punch), Foot (Go To and kick), Tongue (Talk), Eye (Look At).

Many of the verbs in the old design were simply not necessary, they were legacy from earlier text-based adventure games. (i.e. they allowed to produce a legible sentence "Use Turkey with Oven"). When interacting with a door, each of the verbs open, close, push, pull and use should give the same result. if the door is closed, by manipulating it the player wants it to open regardless whether he is trying to "pull" (or "push", depending on which side), "open" or "use" the door. Eliminating the option to close a closed door doesn't hurt either.

2.b) Advanced User Interface

Remember that player's skill to play your game will improve with time. After some initial training phase you can demand more complicated interaction. Take any strategy game where you can select and move your units with the mouse. A beginner will not use the keyboard at all to play the game, but advanced players will want to group their units, assign a shortcut key for the group and move them all at once. This impact should be considered carefully, unless you are targeting a very specific gameplay with few, independent units.

3) Guidance

The player must know long- and short- term goals of the game and be reminded of them regularly. This is critical to guide the player in the right direction and helps immersion. Especially at the beginning of the game, the player might still be struggling with the controls of the game and will put the game away as "too hard" if you ask too much. When done right (by giving the player easy, achievable goals and increase difficulty bit by bit) the player will realize that it's actions have impact on the world, which is a strong motivator.
It is important to be true and caring about the player in the early hours of the game, so the player starts to trust and rely on the tips it receives.
Later in the game there may also be misleading, lies and simply wrong statements to confuse the player and make the game harder, but this may - under no circumstances - be done at the beginning.

Note: The impression of control may be disturbed by cut-scenes or other non-interruptible sequences!

As the developer of a game, you know the controls and tasks in the game inside-out, that's why it's important to have someone neutral (with at least knowledge about the game as possible) playtest your design. Analyze the opinions of the test players, but do not change anything at the first sight of criticism. You cannot make everyone happy. But if multiple testers complain about the same part to be too hard and they're stuck, it probably is. In that case there may be a hint missing players need to figure it out, otherwise the difficulty raised too quickly.

4) Tempo

Against common belief there's no good reason why a game has to pace at mach 5 at all times, in fact it is desireable that pacing varies during gameplay. If pacing is very fast and hectic at all times the game will become an exhausting experience over time, but also if pacing is very slow and calm the game may become boring. The contrast between those extremes is simply necessary to keep both interesting. After a hectic battle, a short period of calmness will be relaxing to the player, and after (not too much) relaxation another stressful battle will be welcome again to keep things interesting. This pacing can be found in pretty much every RPG as an explicit action, where the game is designed so that players "rest" after battle.

It's desireable to allow players to use skills they have obtained playing other games, so you as the developer should be very clear about the minimum and maximum pacing you desire. Especially if you are going to clone an existing game you should carefully consider changing the speed, because that can quickly change the game into something very different. For example a player who is used to the pacing of the quake/unreal deathmatch will feel that games like SWAT are rather slow. (The first favors speed while the later favors tactics) This doesn't mean they will never be interested in your game, but if they do they are likely going to feel restricted in their interaction with the world. But you can compromise: by adding a sprint action to SWAT, or adding ambush passages or traps to quake levels.

5) Target Audience

Obviously this is no perfect formula to glue the audience to the screen infinitely, and sincere thought should be given who you're trying to address. Games for children and grown ups will have to meet different physical, intellectual and emotional limits.

Here are some solutions how to meet different demands with the same game:

  • A shade of grey between short-term and long entertainment, by allowing the player to save the gamestate at will, automatically save for the player at predefined checkpoints or provide passwords for completed levels.
  • Different difficulty levels to provide acceptable challenge for beginners, veterans and players inbetween.
  • Provide an Arcade-Mode and a Simulation-Mode, the former provides simple controls while the later provides complex ones.
  • As the only (known to me) game of it's kind, Lucasarts adventure game "The Secret of Monkey Island 2: LeChuck's Revenge" offered a "light" and a "full" story mode. The light mode did not contain hard and non-obvious puzzles, while keeping the story intact. The full mode would play the complete game.

Games for children usually train the hand-eye coordination, aren't text-heavy and only include the most basic emotions. Children have a short attention span, patience and long-term planning are skills that have to be obtained and are not given by nature. Also make sure that the graphics are very colorful, children like heavily saturated colors.

Games for teenagers and adults tend to be more complex, also their hand-eye coordination is already fully developed. Certainly this audience will also play children's games, but will usually not be challenged and they rather do that for a sense of accomplishment and achievement. Games for grown ups may contain complex problems and long term goals. Note that there's a wide gap between real-time and turn-based strategy games, the former will demand a solution in finite time, while the later asks for the overall best solution without time pressure.

Part 2 will be following these holidays...


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
c2woody's picture

Nice nice. Hoping for more DOTT screenshots ;)

Tal's picture

Great article!
I first thought the article is for gamers(by the title), but it turns out it is for the developers.
And why do you think it "may kill the fun in playing video games"? You didn't said why playing video games is bad, you said why it is(or should be) fun!

nythrix's picture

Good reading. It's a shame that seven years later a lot of games still get most of those points wrong.

Tal: He didn't write playing games is bad. He's trying to warn us that reading how a game is designed/built/developed might spoil the fun. I disagree, though. IMO you can be a gamedev AND a serious player. But not of the same game probably.

Boogiwoogie's picture

I once have asked myself the same question and got highly misunderstood when I wrote it to a game developers forum.
I pretty much wanted to know which type of game has the best "lines of code to fun ratio". As anyone may anticipate, it turned into a "which language is the best" thread right away, because its rather clear that "lines of code" heavily depends on the used language ;)
So I reasked it: "How few logic does a game need to be fun?", leading to more appropriate answers. I can remember one good suggestion: In order to make the player stick to your game, you may introduce a reward system of some sort. It doesnt make the game funnier or more complex, it just gives the player the feeling that he "has gotten further", even if that is not the case. Many games make use of that, rewards being higher player rank, experience points, features that get unlocked and so on. Good example would be Trackmania Nations, where you can gather points that virtually have no meaning at all, but make you get higher in the rankings.
I can remember playing it, just to reach some threshold... more than once ;)