A Theory of Fun for Game Design - by Raph Koster (Summary - PVIII)

Chapter 8: The Problem With People

• The holy grail of game design is to make a game where the challenges are never-eding, the skills required are varied and the difficulty curve is perfect and adjust itself to exactly our skill level. Someone did this already, though, and it's not always fun. It's called "life".

Try to design abstract systems that have deep self-generating challenges.

Emergent Behavior -> New patterns that emerge spontaneously out of the rules. Emergence has proven a tough nut to crack in games, it usually makes games easier, often generating loopholes and exploits.

Storytelling -> Most games melded with stories tend to be Frankstein monsters. Most players tend to skip the story or skip the game.

Placing Players Hand-to-Hand -> Other players are an endless source of new content. But players hate to lose, so if you fail to match them up with an opponent who is very precisely at their skill level, they'll quit.

Using Players to Generate Content -> Many games expect players to supply the challenge in various ways, raging from making maps for a shooter game to contributing characters in a role-playing game.

• If something has worked for us before, we'll tend to do it again. We're really very resistant to learning.
• We're conservative at heart, and we grow more as we age.

Features that make the experience a learning experience:

- Greater skill in completing the challenge should lead to better rewards;

- High-level players can't get big benefits from easy encounters or they will bottom-feed, and the inexpert players will be unable to get the most out of the game;

- Failure must have a cost.

• Most long-lasting games in the past have been competitive because they lead to an endless supply of similar yet slightly varied puzzles.
• If we come across a problem we've had encountered in the past, our first approach is to try the solution that has worked before, even if the circunstances aren't exactly the same.
• Sticking to one solution is not a survival trait anymore. The world is changing very fast and we interact with more kinds of people than ever before. The real value now lies in a wide range of experiences and in understanding a wide range of points of view. Closed-mindedness is actively dangerous to our society because it leads to misapprehension. And misapprehension leads to misunderstanding, which leads to offense, which leads to violence.
• Engaging in an activity that you had fully mastered, being in the zone, feeling the flow, can be a heady experience. And no one can deny the positive effects of meditation. If gamers find themselves in tune with a game, they may play it for longer than they need to in order to master it, because being in the zone feels good.
• Games must encourage the player to move on.
• Every once in a while games come along that appeal to the masses, and thank goodness. Because priesthoods are a perversion of what games are about. The worst possible fate for games would be for games to become niche, something played by only a few elite who have the training to do so. It was bad for sports, it was bad for music, it was bad for writing, and it would be bad for games as well.
• The most creative and fertile game designers working today tend to be the ones who make a point of not focusing too much on other games for inspiration.
• It's critical that games should be placed in context wih the rest of human's society endeavors.

A Theory of Fun for Game Design - by Raph Koster (Summary - PVII)

Chapter 7: The Problem With Learning

• The mind likes to take shortcuts when solving problems. In other words, many people are willing to cheat.
• Cheating is a long term tradition in warfare, where it is acknownledged as one of the most powerful and brilliant of all military techniques.
• When a player cheats in a game, he is choosing a battlefield that is broader in context than the game itself.
• Cheating may be a sign that the player is grokking the game.
• Gamers will try to make the gameplay as predictable as possible. This then means that the game will become boring and not fun.
• We dislike tedium, sure, but the fact is that we crave predictability. Our whole life is built on it. Unpredictable things. Unpredictable things are like drive-by shootings, lightining bolts that fry us, smallpox, food poisoning - unpredictable things can kill us.
• Since we dislike tedium, we'll allow unpredictability, but only inside the confines of predictable boxes, like games or tv shows.
  
• Games package up the unpredictable and the learning experience into a space and time where there is no risk.
  
• Unpredictability means new patterns to learn. Therefore, it can generate fun.
• The natural instinct of a game player is to make the game more predictable because then they are more likely to win.
• Bottom-feeding: player taking on weaker oponents under the sensible logic that a bunch of sure wins is a better strategy thn gambling it all (minimizing risks).
• Rewards are one of the key components of a successful game activity.
• Successful games tend to incorporate the following elements:

1. Preparation: Prior moves in a game, like healing up before battle, are automatically part of the preparation stage because all games consist of multiple challenges in sequence.
2. A Sense of Space: The space might be the landscape of a war game, a chess board, or a networking of relationships between players during a bridge game.
3. A Solid Core Mechanic: This is a puzzle to solve, an intrisically rule set into which content can be poured. The core mechanic is usually a small rule; the intrincacies of games comes usually from having a lot of mechanics or having a few, very elengantly choosen ones.
4. A Range of Challenge: Content. It does not change the rules, it operates within the rules and brings slightly different parameters to the table. Each enemy you might encounter in a game is one of these.
5. A Range of Abilities Required to Solve the Encounters: If all you have is a hammer, and you can only do one thing with it, then the game is going to be dull. This is a test that tic-tac-toe fails but checkers meets.
6. Skills Required in Using the Abilities: Bad choices lead to failure like: failures in timing, failures in physical dexterity, and failure to monitor all the variables that are in motion. But you need to be very careful when requiring those abilities, for you don't want to frustrate the player.

A game having all these elements hits the right cognitive buttons of fun.

A Theory of Fun for Game Design - by Raph Koster (Summary - PVI)

Chapter 6: Different Fun for Different Folks

There are seven categorized forms of inteligence:

1. Linguistic;
2. Logical-Mathematical;
3. Bodily-Knesthetic;
4. Spatial;
5. Musical;
6. Interpersonal;
7. Intrapersonal.

• People are not likely to tackle patterns and puzzles that appear as noise to them. They'll likely select problems that they think they have a chance at solving.
• On average, females tend to have great trouble with certain types of spatial perception. Males tend to have great problems with language skills.
• Since different brains have different strengths and weaknesses, different people will have differente ideal games;
• Men not only navigate space differently, but they tend to learn by trying, whereas women prefer to learn through learning another's behavior.
• It's clear that players prefer other types of games in ways that seems to correspond their fun personality. What does it all means to game designers? Ut means that not only will a given game be unlikely to appeal to everyon, but that it's probably impossible for it to do so.
• The difficult ramp is almost certain to be wrong for many people.
• This may indicate a fundamental problem with games. Since they are formal abstract systems, they are by their very nature biased toward certain types of brains, just as books are biased.
• Perhaps the answer is simpler. Maybe games are more likely to appeal to young males because these players are good at mastering formal abstract systems.
• Both genres should seek out games that address their weakness.
  

A Theory of Fun for Game Design - by Raph Koster (Summary - PV)

Chapter 5: What Games Aren't

• People tend to dress up game systems with some fiction. Designers put artwork on them that is suggestive of some real-world context.
• The fiction serves two purposes: it trains you to see past it to the underlying problem, and it also trains you to recognize real-world situations where the problem might be lurking.
• Usually there are metaphors for what is going on in the game. While metaphors are fun to play with, players can basically ignore them.
• Since games are about teaching underlying patterns, they train players to ignore the fiction that wrap patterns.
• The commonest route these days for developing games involves grafting a history onto them. But most video game developers take a usually mediocre story and put little game obstacles all through it. It's as if we are requiring the player to solve a crossword puzzle in order to turn the page to get more of the novel.
• The stories that wrap up games are usually side dishes for the brain. For one thing, it's damn rare to see a game story written by an actual writter. For another, since games are generally about power, control, and other primitive things, the stories tend to be so as well. This means that they tend to be power fantasies. Story deserves better treatment than that.
• Games are not stories. It's interesting to make the comparison though:

1. Games tend to be experential teaching. Stories teach vicariously.
2. Games are good at objectification. Stories are good at empathy.
3. Games tend to quantize, reduce, and classify. Stories tend to blur, deepen, and make subtle distinctions.
4. Games are external - they are about people's actions. Stories - good ones anyway - are internal, they are about people's emotions and thoughts.

• Physical challenges alone aren't fun. The feeling of triumph when you break a personal record is.
• Throughout the book, fun is referred only as mentally mastering problems. Often, the problems mastered are aesthetic, physical, or social, so fun can appear in any of these settings.
• The brain rewards you for an autonomic response when they are given in the context of a mental challenge.
• Delight strides when we rocognize a pattern but are surprised by them. Unfortunately, it doesn't last. It's like the smile of a beautiful stranger in a starwell - it's fleeting. It cannot be otherwise - recognition is not an extended process.
• We find things beautiful when they are very close to our idealized image of what they should be but with an additional surprise wrinkle.
• Real fun comes always from challenges that are at the margin of our abilities.
• As we succeed in mastering paterns thrown at us, the brain gives us little jolts of pleasure. But if the flow of new patterns slows, then we wont't get the jolts and we'll start to feel boredom. If the flow of patterns increase beyond our abilities, then we won't get the jolts either, because we're not making progress.
• Meditation induces brainwaves that are similar to the ones of the flow state.
• Fun is about learning in a context where there is no pressure.

A Theory of Fun for Game Design - by Raph Koster (Summary - PIV)

Chapter 4: What Games Teach Us

As we age, we think things are more serious and that we must leave frivolous things behind. Is that a valid judgement on games or is it a value judgment on the content of a given game? Do we avoid the notion of fun because we view the content of the fire drill as being of great import?

• The very phrase "it's just a game" implies that playing a game is a form of practice for a real life challenge.
• Exploring possibility space is the only way to learn avout it. Most games repeatedly throw evolving spaces at you so that you can explore the recurrence of symbols withim them.
• Some of the really important parts of exploration involve memory. A huge number of games involve recalling and managing very long and complex chains of information. (ex: dominoes)
• In the end; most games have something to do with power. Even the innocuous games of childhood tend to have violence lurking in their heart of hearts.
• Action games for example, they are all about reaction times, tactical awareness, assessing the weakness of an opponent, and judging when to strike.
• We pay attention to the obvious nature of a particular game and we miss the subtler point.
• Many games, particularly those that have evolved into the classic Olympian sports, can be directly traced back to the needs of primitive humans to survive under very difficult conditions.
• We do in fact evolve games that are more suited to our modern lives.
• Traditional role-playing can reach the same heights as literature in the right hand. But it's an uphill battle nonetheless, simply bacause games are at their core about teaching us survival skills. As we all know, when you're worried about subsistence and survival, more refined things tendo to fall by the wayside.
• It's still valuable to train ourselves in some of the caverman traits, but we need to adapt. It's worth asking ourselves what skills are more commonly needed today.
• Some of the new patterns we need to learn in our brave new world run contrary to our instinctive behaviors. For example, humans are tribal creatures. Most games encouraging demonizing the opponent, teaching a sort of ruthlessness that is a proven survival trait. But these days, we're less likely to need or want the scorched-earth victory. Can we create games that instead offer us greater insight into how the modern world works?
• Since the introduction to the concept of grabbing and using a weapong in a game was introduced not much has changed. The difference is that, today, instead of a single weapon for us to use in the game, we have a bewildering array of weapons.
• Possible algorithm for innovation -> find a new dimension to add into the gameplay. Recent games have included more robust stories and even elements from role-playing games. Are there more dimensions on which to expand?

A Theory of Fun for Game Design - by Raph Koster (Summary - PIII)

Chapter 3: What Games Are

• A "magic-circle" that is disconnected from reality;
• Choice, Rule, and Confront;
• Games are puzzles to solve, just like everything else we encounter in life. They are in the same order as learning to drive a car, or picking up the mandolim, or learning your multiplication tables.
• The only difference between games and real life is that the stakes are lower with games.
• Games serve as very fundamental and powerful learning tools.
• Play a goal-oriented game involves simply recognizing a particular sort of pattern; playing make-believe is recognizing another one. Both deservely belong in the same category of iconified representations of human experience that we can practice with and learn patterns from.
• Books will never be able to accelerate the groking process to the degree that games do, because you cannot practice a pattern and run permutions on it with a book.
• Games are puzzles - they are abouth cognition and learn to analyze patterns. Games that fails to exercise the brain becomes boring.
• Extremely formal games have few variables. To make games more long-lasting, they need to integrate more variables (and less predictable ones) such as human psychology, physics, and so on.
• When you are playing a game it exercises your brain, but you'll only play it until you master the pattern. When a game stops teaching us, we feel bored;
• Games grow boring when they fail to unfold new niceties in the puzzles they present.
• The brain doesn't necessarily craves for new experiences - it just craves for new data. A new experience may force a whole new system on the brain, and often the brain doesn't like that. It's disruptive.

Way of Boredom

1. The player might grok that there is a ton of depth to the possible permutations in a game but conclude that these permutations are below their level of interest.
2. The player can't see the pattern (noise).
3. Slow variations in patterns.
4. The game might also unveil the variations too quickly, which then leads to players losing control of the patterns and giving up because it looks noisy. "This got too hard too fast!" they will say.
5. When the game ends for the first time.

The definition of a good game is therefore "one that teaches everything it has to offer before the player stops playing."

Games are very good teachers...of something. The question is, what do they teach?

A Theory of Fun for Game Design - by Raph Koster (Summary - PII)

Chapter 2: How the Brain Works

Definitions of Game word:

1. A rule-based formal system with a variable and a quantifiable outcome, where different outcomes are assigned different values. The player exerts effort in order to influence the outcome, the player feels attached to the outcome, and the consequences of the activity are optional and negotiable.
2. A subset of entertaining limited to conflit.
3. A series of meaningful choices.
4. Ernest Adams and Andrew Rollings: one or more casually linked series of challenges in a simulated environment;
5. A system in which players engage in an artificial conflict, defined by rules, that results in a quantifiable outcome.
   

• The human brain is a most voracious consumer of patterns. Games are just exceptionally tasty pattern to eat up.
• The brain is hardwired for facial recognition, just as it's hardwired for language, because faces and language are incredibly important to how human society works.
• Assumptions is what the brain is best at.
• In fact, we tend to see patterns were there aren't any.
• The brain is good at cutting the irrelevant.
• But the brain notice a lot more than we think he does.
• The brain is actively hiding the real world from us. In fact, seeing what actually is there with our conscious mind is really hard to do, and most people never learn how to do it.
• When we grasp a pattern, we usually get bored with it, and iconify it.
• We rarely look at the real world; we instead recognize something we have chunked, and leave it at that - for example, we can drive barely seeing the road.
• If we are able to divide a paiting into boxes of different proportions, we'll usually think the paint is pretier than if we couldn't.
• Excess -> chaos -> noise -> ugliness.
• Noise is any pattern we don't understand.
  
• Music is ordered sound and silence.
• There's really next to nothing in the visible universe that is patternless. If we perceive something as noise, it's most likely a failure in ourselves, not a failure in the universe.
• Once we see a pattern we delight in tracing it and in seeing it reocur. We call this practicing, and the more we do it, the less we have to think about what we're doing.
  
• Conscious thought (1st level) -> mathematical level.
• Interrogative, associative, and intuitive thoughs (2nd level) -> Link things that doesn't make much sense. Doesn't use words. It's frequently wrong. Builds approximation of reality.
• Usually, we make whole sets of decisions instinctively.
• Building up a library is also what we call practice. Studies have shown that you don't even have to do something physically in order to grasp it. You can just think about doing it and it'll get you much of the way there.
• When our brain is really into practicing something, we'll dream about it. This is the intuitive part of the brain burning nerval pathways into our brain.
• So, basically it'a fun to exercise our brain.
  

A Theory of Fun for Game Design - by Raph Koster (Summary - PI)

Chapter 1 - Why Write This Book?

• Many believe that language is built into the brain and that there's something in our wiring that guides us inexorably toward language.

• Why there are games fun and other games boring? Why do some games start getting boring after a while, and other games stay fun for a long time?

• People are pattern matching machines.

Learning XNA 3.0 by Aaron Reed (Chpters 1 and 2, Book Summary)

Chapter 1 - Getting Started

In order to use XNA you'll need to have installed Windows XP(SP2/SP3)/Vista) and Visual C# 2008 or Visual Studio 2008. After that you'll need to download XNA Game Studio 3.1.

Almost all types of code you write for PC using XNA 3.0 can be directly ported to both Zune and Xbox 360.

The program.cs file is pretty straightforward. Your Main method, which creates a new object of Game1 type and executes its Run method, is located in this file.

The real guts of your game lie in the Game1.cs file.

Chapter 2 - Fun With Sprites

• GraphicsDeviceManager;
• Acts as a conduit between XNA and GPU
• Require for every action taken to the screen
• SpriteBatch
• Generate core object to draw sprites
• 2D or 3D images integrated into a larger scene.
• Initialize Method
• Initialize variables and other objects associated with Game1 object.
• GraphicsDeviceManager object is instantiated at this point.
• LoadContent
• Instantiates spriteBatch
• Called whenever new content is in need to be loaded.
• After it’s called, Game1 object enters in a state known as game loop.
• Game Loop
• Update
• The logic calculations should take place here
• Draw
  
• It's better to be used only to draw
• Game Development Versus Polling
• Polling
• The applications is alwasys performing actions regardless of user input
• You have to account for a bunch of user inputs and the implications of such inputs to the game.
• Registering Events
• The application awaits user input to resume its actions.
• Game States
• Defines some changes in the game behavior
• Change of state must take place in the Update Method
• Drawing implications of that should be implemented in the Draw method

Basic Lifecycle of an XNA game.

• Unload Content
• Allows special handling of memory for objects.
• Garbage collection is taken care of by XNA.
• Modifying Your Game
• The gameTime variable
• Used to gauge things such as framerate, animations, sounds, and other effects.
• GraphicsDevice objects' clear method
• Erases everything on the screen, and covers it with the specified color.
• Adding a Sprite to Your Project
• All graphics, sounds, effects, and other items are loaded in XNA through something called the content pipeline.
• content pipeline
• convert loaded files, if necessary
• You can view if the added items were accepted by right-clicking the item in Solution Explorer and selecting Properties
• Uses an asset name to access content resources
• File's name without the file extension, by default.
• Asset names only need to be unique within each content folder.
• A texture refers to a 2D image that will typically be applied to a surface of some object.
• Loading and Drawing Your Sprite
• Before you have access to content from the inside of the code, you need to load them from the content pipeline into variables.
• Texture2D type variables.
• To access data from the content pipeline, you use the Content (ContentManager type) property of the Game class.
• Provides access to all objects loaded in the content pipeline.
• ContentManager
• Load method.
• Content.Load(@"path_to_file");
• The path starts with the Content node in Solution Explorer.

----------------------------------------------------------------------------------
spriteBatch.Begin( );
spriteBatch.Draw(texture, Vector2.Zero, Color.White);
spriteBatch.End( );
----------------------------------------------------------------------------------

• In 2D XNA games, the X, Y screen coordinate (0,0) is the top-left corner of the screen; coordinates move in positive X to the right and positive Y downward.

• Window.ClientBounds
• When a game is run in Windows, Window.ClientBounds.X and Window.ClientBounds.Y correspond to the upper-left coordinate of the game window, while the Width and Height properties of Window.ClientBounds are always equal to the width and height of the window.
• On the Xbox 360 and the Zune, Window.ClientBounds.X and Y are always 0, while the Width and Height properties of Window.ClientBounds are always equal to the width and height of the display (because both Zune and Xbox 360 games are always run in full-screen mode).
• Texture2 variables have Width and Height properties that hold the size of the image.

Transparency and Other Options

• Mainly for performance reasons, you should draw as many sprites as you can in a single SpriteBatch Begin and End block.

• XNA Automatically renders solid magenta (255,0,255) portions of images trasnparent.

• Certains types of file format such as .png make use of an alpha channel - each pixel has an additional alpha channel that determines the transparency of the pixel.

• SpriteBatch.Draw(Texture, Position, SourceRectangle, Color, Rotation, Origin, Scale, Effects, LayerDepth)

Layer Depth

• XNA lets you specify a layer depth for each individual image, which allows you to always place images in the right Z order. In order to do that you must make use of the last presented overloaded Draw method.

• The layer depth parameter is represented by a float value that must be between 0 and 1. The valye 0 corresponds to what XNA calls the front of the Z order; the value 1 represents the back of the Z order.

• In order to use layer depth values to sort your images, you need to use an overload of Begin that takes a parameter of type SpriteSortMode. One of these overloaded methods is: SpriteBegin(SpriteBlendMode,SpriteSortMode,SavestateMode);

• In order to animate sprites along the screen, you'll need to update their positions in the Update method. For that, you'll may find useful to create Vector2 and float type variables.
  

• The vector type variables, will be used to determine the object's location on the plane when you draw;

• The float type variables can be used to update the sprites' coordinates, accounting as a speed factor.
  

Animation

• Animations are made up of standalone images, and flipping through the images in a cycle causes them to appear animated.
• Sprite animations are laid out in a single sheet, and you pull out individual images from that sheet and draw them on the screen in a specific order. These sheets are referred to as sprite sheets.
• In order to draw only a specific portion of the sprite sheet, you'll need to make use of the third parameter of the overriden Draw method shown above of the green table just up at this page.
• There are few things you need to know in order to build an algorithm that will cycle through each image encompassed into each sub-rectangle:

1. The height and width of each individual image (or frame) in the sprite sheet;
2. The total number of rows and columns in the sprite sheet;
3. An index indicating the current row and column of the image in the sprite sheet that should be drawn next.
   

With these parameters in hand, you can build a source rectangle to pass to the Draw method;

To make things easier, you may find useful the use of Point object to store these values: Point(int x, int y);

To animate sprites using a sprite sheet you'll also be using the Rectangle object: Rectangle(int init_x, int init_y, int width, int height), which will be passed in the draw method;

Adjusting the Framerate

• As mentioned before, framerate generally refers to how many times per second a game redraws the entire scene. In XNA, the default is 60 fps.
• There's a type of framerate related to individual animations. This framerate (often referred to as animation speed) reflects the rate at which a given animation cycles through images in the sprite sheet.
• XNA's Game class has a property called TargetElapsedTime, of the TimeSpan type, which tells XNA how long to wait between calls to the Game.Update method.
• The GameTime object, which is passed in as a parameter in both the Update and Draw methods, has a Boolean property called IsRunningSlowly. If its value is true, XNA isn't able to keep up with the framerate. In this case XNA will skip Draw calls in a effort to keep up with your intended speed.
• The speed of the graphics card GPU, the speed of the computer's processor, the number of resources you consume, and the speed of your code, go a long way toward determining whether your game will have that peak performance.

Adjusting the Animation Speed

If you wanted one image to animate at 60 fps and another to animate at 30 fps, you wouldn't be able to accomplish that by adjusting the overall game's framerate.

To adjust the frame animation individually for an object you may use two variables of the int data type to keep track of the last time you changes frames and to only change frames every X number of milliseconds:

int timeSinceLastFrame = 0;

int millisecondsPerFrame = 50;

timeSinceLastFrame => registers how much time has passed since the last frame skip

millisecondsPerFrame => determines the frame skip rate.

These variables would be used in the Update method to determine the framerate of a given object probably like this:

As you can see here, you use the gameTime.ElapsedGameTime property to determine how much time has passed since the previous frame change. This property indicates how much of time has passed since the previous call to Update. You add the Milliseconds property of that object to your TimeSinceLastFrame variable. When the value of that variable is greater than the number of milliseconds you want to wait between frame changes, you enter the if statement, adjust the TimeSinceLastFrame variable by subtracting the value in MillisecondsPerFrame, and then change the animation frame.

Conclusion: While the dafault framerate in XNA draws a new frame every 16 milliseconds, that is nothing compared to the default framerate of Chuck Norris' fists. On average, Chuck's fists punch and mortally wound enemies every 4 milliseconds! O.O