Level Design and Scripting Week 8

1
Level Design and ScriptingWeek 8

• Advanced Programming for 3D Applications
• CE00383-3

2
References

• Andrew Rollings and Ernest Adams. On Game Design,
  New Riders Games, 2003.
• Kevin Oxland. Gameplay and design, Addison
  Wesley, 2004.

3
The Parts

• A game (or other graphics based application)
  comprises four broad components
• Game Engine
• Rules and Mechanics
• User Interface
• Content and Challenges

4
Game Engines

• Sometimes when a developer or player uses the
  term engine they really mean graphics engine.
  But a game engine encompasses much more. Game
  engines
• Power the graphics and sound
• Power the AI
• Power the physics and interactions in the game
• Describe the nature of the game space
• Define the parameters of game objects
• Define the space of possibilities in the game
  world

5
Characteristics of an Engine

• Is broad, adaptable, and extensible.
• Firmly encodes all non-mutable design decisions.
• Allows parameters for all mutable design
  decisions.
• Should outline the gameplay and challenge
  possibilities.
• Determines the overall game architecture.
• Is coded so that new design decisions leave it
  unchanged.

6
Rules and Mechanics

• Specific decisions about game parameters,
  obstacles, and abilities determine the rules and
  mechanics of the game. This includes things like
  
• Player abilities
• Enemy stats
• Enemy behaviour
• Jumping height
• Gravity strength
• Point values
• Interplay between game objects

7
Rules and Mechanics (contd)

• Engine mechanics core rulebooks.
• Engine and mechanics still doesnt make a whole
  game.
• AI is part of the mechanics.
• If you have the engine and the mechanics, you
  should be able to make a level editor or game
  toolset.
• Takes the space of possibilities, and makes
  decisions for all parameters

8
Interfaces

• The engine and mechanics tells us what the player
  and other objects in the game can do.
• The interface tells us how the player does
  things, and how she knows whats happening in the
  game.
• Interfaces thus have two parts
• Player-to-Computer
• Computer-to-Player
• The interface is the center of the user
  experience.

9
Content and Challenges

• Two types of content
• non-gameplay
• gameplay.
• Non-gameplay content includes
• Graphics
• Sound Effects,Background Music,Cut Scenes
• Story,Flavor Text,Dialogue
• Gameplay content includes
• Goals and victory conditions
• Missions and quests
• Level design

10
Types of Levels

• Before designing a level for a game, it is
  important to know what type of level is needed
  for the game.
• Standard
• Hub
• Boss
• Bonus
• Tutorial

11
Standard Levels

• Standard levels are used to contain the typical
  gameplay of a game and are used to contain most
  of the story of the game.
• around 90 of a games levels are standard
  levels, while the rest are special levels of one
  of the other types.

12
Hubs

• Hubs do not have the same gameplay model as
  standard levels.
• Hubs are levels that tend to be used to connect
  other levels together.
• Consequently hubs can have multiple entry and
  exit points, although not all need be accessible
  on the first visit to the hub.
• Typically, players can return to hubs multiple
  times throughout a game for some purpose.

13
Types of Levels Hubs
Screen shot from Overlord. In this game, your
tower is a hub, allowing youto do a variety of
maintenance tasks, as well as transporting you to
otherparts of the game world.
14
Boss Levels

• Climax points within a game.
• Whether they be bosses, mini-bosses, orthe final
  boss of the game.
• Boss levels are often designed around the boss in
  question.
• This includes how the boss attacks, and how the
  boss can ultimately be defeated.
• Boss levels provide a break from the standard
  levels in a game.
• Typically cover a lot less territory thanthe
  standard levels.
• Can also have different gameplay mechanics.
• Boss levels also typically trap or otherwise
  contain the player so that they cannot escape the
  area.
• At least not until they defeat the boss

15
Types of Levels Boss Levels
Screen shot from Armed and Dangerous. After
finishing an area, quiteoften there were boss
battles involving using a turret to ward off
wavesof enemies. A different style of gameplay
from the rest of the game.
16
Tutorial Levels

• Tutorial levels can be among the more difficult
  ones to design properly.
• They must teach the player multiple new skills in
  a short amount of time, as you do not want the
  player delayed from getting into the rest of the
  game.
• At the same time, the training scenarios must be
  spaced out and paced so that the player is not
  overwhelmed by too much at once.
• They must somehow fit into the rest of the levels
  in the game smoothly, and must not seem out of
  place in comparison, which can be hard,
  especially when you must consider the player
  might skip them.

17
Types of Levels Tutorial Levels
Screen shot from Psi-Ops The Mindgate
Conspiracy. This game featuresmultiple tutorial
levels, each teaching a different gameplay skill.
Theseare nicely integrated as memories
recovered as the game progressesto teach the
relevant skills as they are needed.
18
Bonus Levels

• Unlike other levels that can be critical to the
  completion of a game, bonus levels are optional
  and not required for game completion.
• Typically, bonus levels are given as rewards to
  players for some kind of extra effort in the
  game.
• Bonus levels also provide a break from standard
  levels.
• They can be shorter and use much different
  gameplay than standard levels.
• Completing a bonus level might provide a further
  reward, like a special weapon, item, and so on,
  depending on the game.
• Bonus levels should be the lowest priority on any
  project, and are one of the first things cut if
  time runs short.

19
Types of LevelsBonus Levels
Screen shot from Mario Bros. This is a bonus
level in which the playermust grab as many coins
as possible before time runs out.
20
Designing the Level

• Three main categories of design issues
• The spatial or physical characteristicsof the
  level.
• The temporal characteristics of the level.
• The interplay between the levels designand the
  gameplay that is contained within the level.

21
Spatial Characteristics

• Spatial characteristics include the physical
  elements of the game environment.
• Perspective
• Physical Layout
• Consistency
• Interior versus Exterior
• Materials and Terrain
• Scale , Boundaries
• Consistency
• Style
• Landmarks

22
Spatial Characteristics Perspective

• There are a wide variety of perspectives that can
  be used to view the levels inthe game world.
• First person perspective
• The game is viewed from the perspective of the
  player character in the game world.
• Third person perspective
• In this perspective, the player character is
  visible on screen, and the game world is viewed
  through some other camera observing the scene.
• Omnipresent Provides the ability to view all
  over the game world, usually from above, with
  great control over the cameras position.
• Isometric The player can look slightly across
  the landscape at a 30 to 45 degree angle to be
  involved in the action.
• Top-down The game is viewed straight from
  above, possibly with some form of scrolling.
• Side-view The game is viewed from the side,
  possibly with some form of scrolling.

23
Spatial Characteristics Physical Layout

• The physical layout of a level will be heavily
  influenced by its gameplay type.
• Single player levels should create a flow that
  leads the player from goal to goal. There should
  be a linear flow of nonlinear areas, perhaps with
  branches to the flow.
• Multiplayer levels should be more open, but
  simpler so the player does not get lost. There
  should be no safe places, but perhaps some hard
  to reach ones.

24
Spatial Characteristics Interior versus Exterior

• Interior spaces often work differently in games
  than exterior spaces.
• In essence, an interior space is a space with a
  ceiling constrained by walls.
• Interior spaces also tend to be smaller, more
  confined, and easier to control.
• Exterior spaces tend to be more open, with the
  player able to see much farther.
• Consequently, interiors tend to have more details
  than exteriors, in which detail must be used with
  great care and a lot of consideration.

25
Spatial Characteristics Materials and Terrain

• In game levels, there are two types of
  structures man-made and organic.
• Man-made structures are not naturally occurring,
  constructed from a variety of materials like
  concrete, brick, metal, glass, wood, and so on.
• Organic structures are the terrain of the game
  world, composed of water, earth, rock, sand,
  plant-life (like grass and trees), and so on.
  This also includes what is visible in the sky in
  exterior levels, like clouds, and so on.

26
Spatial Characteristics Scale and Boundaries

• The scale of the game includes the total size of
  physical space and relative sizes of objects in
  the game.
• For realism, it is best to scale most objects to
  accurately reflect their size in the game.
• Scale exaggeration might be necessary to make
  sure elements of the game are harder to miss, or
  easier to manage or manipulate.
• Scale distortion might also be necessary to make
  traversal of the world quicker and easier to the
  player.
• Finite world so developers have to provide some
  boundaries
• At the same time, these boundaries must make
  sense when they are visible in the context of a
  game, or else player immersion might be lost.
• Boundaries can include locked doors, walls,
  impassable mountains, thick vegetation, and so
  on, depending on the game, of course.
• Some games do not contain boundaries, but have a
  game world that is wrapped around itself.

27
Spatial Characteristics Style

• The style of a level influences its structure and
  also its appearance.
• This includes
• The architecture of man-made structures.
• The layout of terrain elements.
• The placement and types of objects tobe found in
  the levels.
• The colouring, texturing, and shading of
  everything in the level.

28
Spatial Characteristics Landmarks

• Visually distinctive landmarks should be provided
  to help orient the player as they navigate the
  level.
• Landmarks can be anything in the level as long as
  it is unique.
• Usually, landmarks are memorable either by size,
  position, or appearance.
• Landmarks can also be the focal points for levels
  as well, so make them interesting and evoke
  emotion from the player.

29
Spatial Characteristics Consistency

• The look of a level should be consistent.
• Although larger levels can contain a series of
  smaller locations that look different, each
  location should be consistent within its
  boundaries.
• Levels should also be consistent with other
  elements of the game.
• With the games story, with its characters, and
  so on.

30
Temporal Characteristics

• We can think of time in the context of real
  world or wall clock time.
• In the end, time in levels of the game world can
  pass slower, faster, or not any different than
  time in the real world.
• In some games, time does not pass at all, at
  least until the player does something.

31
Authentic Time

• Some games try to portray time authentically and
  use the passage of time as a gameplay mechanic
  in the game world.
• In some cases, time is synchronized with time in
  the real world or something else like the
  presence of light to track time passage.
• In other cases, time is not synchronized but
  still plays an important and authentic role in
  various elements of the game.

32
Gameplay Goals

• Make sure the player knows the goals and
  objectives to complete in each level.
• Give them a cut scene or scripted action.
• Provide an easily accessible mission screen.
• The players should be given some way of measuring
  their progress and success within a level as
  well.
• The design of a level should also reflect the
  goals the player is to complete.

33
Gameplay Obstacles

• Obstacles prevent the player from easily
  achieving those goals.
• Simple roadblocks
• These obstacles slow the player down
• Enemies
• Games that involve combat will have enemies that
  either need to be defeated or avoided to reach
  the games goals.
• Enemies can vary in size, movement (speed, method
  of movement), and attack style.
• Traps
• Traps are obstacles that can ensnare or do damage
  to the player that are part of the environment in
  the game world.
• Traps can include hidden pits, closing walls,
  falling objects, and so on.
• Puzzles
• Puzzles are obstacles that require some
  brainpower to solve and remove.

34
Structure and Progression

• Ease the player into each level and build up the
  difficulty as they go along.
• Build conflict in a series of ascending arcs.
• Give hints and teases of what is to come.
• Vary the pace of action in the level.
• Some frantic periods of action.
• Some exploration time.
• Some safe time when the player can take a
  breather, think, and absorb the situation.
• Make sure there is enough to do!
• Do not let the player get bored. Ensure there
  are enough challenges to keep the player occupied.

35
Gameplay Structure and Progression
36
Gameplay Flow Control

• Closing off areas can be necessary for many
  reasons
• Better management of resources.
• Reducing player paranoia.
• There are many ways to accomplish this.
• The simplest is the creation of a one way barrier
  that prevents the player from going back once it
  has been crossed.
• Remember that your player can try to do the
  unexpected.
• Play testing is needed to ensure that game flow
  is being controlled properly.

37
Gameplay Balance

• Stocking a level requires very careful thought
  and planning.
• Too many or too few supplies for the player.
• Too many or too few enemies.
• Locations of supplies and enemies.
• Levels need to be carefully balanced to push the
  player to their limits, without actually pushing
  them over the edge.

38
Gameplay Rewarding the Player

• Balance risk and reward for the player.
• Something might be difficult to do in a game, so
  accomplishing it should provide some kind of
  bonus to the player for their efforts.
• Players should also be rewarded for skill,
  imagination, intelligence, and dedication.
• These qualities distinguish a good player, and
  good players should be rewarded.
• It is important to reward in a big way, and
  punish in a small way.
• Ultimately, the hope of success motivates players
  more (and in better ways) than the fear of
  failure does.

39
The Eight Steps Game Design for a Puzzle Game

• 1. Inspiration
• 2. Simplification
• 3. Construction Set
• 4. Design Specification
• 5. Levels
• 6. Testing
• 7. Sequence
• 8. Presentation

SPECIFY RULES BUILD PUZZLES
Here are the eight steps in designing a puzzle
game. The process splits into two halves
specifying the rules, and building the puzzles.
40
1. Inspiration Previous Game
41
1. Inspiration Technology

• 1. Nonphysical moves (Tetris)
• 2. Algorithmic levels (Pit Droids)
• 3. Enforce the rules (Sokoban)
• 4. Allow undo (Solitaire)

If you are going to design a computer puzzle,
dont just copy a puzzle from another medium.
Instead, think about how the computer can enhance
gameplay. Eight ways are listed above. Thinking
about the technology first can inspire ideas for
new types of puzzles.
42
1. Inspiration Play Mechanic
Every computer game, at its core, has a play
mechanic a basic way that the player interacts
with an object that gets used over and over.
Endorfun, for instance, was inspired by the play
mechanic of a cube rolling on a square grid,
controlled by the four cursor keys..
43
1. Inspiration Subject matter

• This puzzle was inspired by thinking about
  astronomy

Like songs, puzzles can be inspired by real life.
Stephen Sondheim A good clue can give you all
the pleasures of being duped that a mystery story
can. It has surface innocence, surprise, the
revelation of a concealed meaning, and the
catharsis of solution.
44
1. Inspiration Story
Adventure games like Myst are built around the
elements of story plot, character, setting, and
mood. When you design puzzles for story-based
games, look for puzzles that arise naturally out
of the environments and situations, and help
advance plot or reveal character.
45
1. Inspiration Art
The story game Obsidian started as a series of
concept sketches for characters and environments.
Story and puzzles came later. Similarly, the
puzzle game Spin Doctor (later renamed ClockWerx)
started as a graphic concept by an artist on the
project.
46
2. Simplification
The second step is to whittle the concept down to
manageable size. Say we wanted to make a puzzle
based on the tricky core skill of parking a car
in a crowded lot. We eliminate irrelevant details
and make pieces uniform by conforming them to a
square grid.
47
3. Construction Set

• Programmer reusable code
• Rule designer tweak rules
• Level designer build levels
• Player build levels

The only way to test a puzzle concept works is to
play it. So the next step is to build a
construction set that makes it easy to build
puzzles of a certain type. Sometimes a paper
prototype is adequate. Once the rules are set,
other people can use the construction set to
build levels.
48
4. Design Specification

• Board grid, network, irregular, none
• Pieces shape, image, attribute, supply
• Moves sequential, side effect, primary
• Goal exact match, partial, condition

Now it is time to write a detailed design
specification. Most puzzle game specs will
describe puzzles in terms of board, pieces, moves
and goals. In addition a design spec may also
cover the user interface, scoring, story, art,
sound and other aspects of production.
49
5. Levels
Schematically, a puzzle challenges the player to
get from a problem to a solution.
50
5. Levels
But of course the path is never simple. Every
puzzle requires that the player make choices,
some of which lead to dead ends.
51
5. Levels
Puzzles in a game have a larger situation that
gives the puzzle meaning. Applying the solution
lets you move forward in the game.
52
5. Levels
Good puzzles have require insight. The insight
above is to walk around the outside of the maze.
Obscure insights, however, feel unfair.
53
5. Levels
Different puzzles emphasize different parts of
the journey. Persistence puzzles are a slow
steady climb. Aha! Puzzles skip the climb and go
straight to the insight. Story puzzles work the
setup into the story. Crossword puzzles are full
of little insights each word unlocks more.
54
6. Testing

• Is it fun?
• How hard is it?
• Are there simpler solutions?
• Can it be improved?

The only way to find out whether a puzzle is fun
is to watch someone play it. Often a puzzle you
think is easy will turn out to be hard, or vice
versa. Sometimes players will find simpler
solutions. Or you will realize that the puzzle
needs some other improvement.
55
7. Sequence

• Accelerating
• Linear
• Sawtooth
• Semilinear
• Ordered collection
• Metapuzzle

Next you must put the levels into sequence.
Linear is simplest, but can get tiring. A better
organization is the sawtooth, which keeps going
back to easy puzzles, or to give players freedom
to play puzzles out of order. Metapuzzles
motivate players to complete the whole game.
56
7. Sequence Transitions

• Learning the rules
• Recovering from failure
• One puzzle to the next
• One section to the next

You also need to think about the transitions
between puzzles. Whenever the player moves from
one place to another in your game, there is an
opportunity to lose the players interest. How
can you bridge these gaps?
57
8. Presentation
Finally there are all the matters of presentation
that turn an abstract puzzle into something
people can see, hear and touch. I wont go into
detail on production for puzzle games.
58
Scripting Engine

• Scripting languages in game engines
• Advantages
• Easy control of many (or all) features in the
  game engine
• Scripting language often provides full OO control
  (like Lua)
• Promotes data-driven design
• Disadvantages
• Performance
• Development support tools
• Learning curve

59
Scripting Engine

• Common languages used for scripting
• Python
• http//www.python.org
• Lua
• http//www.lua.org
• GameMonkey
• http//www.somedude.net/gamemonkey
• AngelScript
• http//www.angelcode.com/angelscript

60
Scripting Engine

• What belongs in a script and what belongs in the
  engine?

• ENGINE
• Graphics
• Rendering
• Shadows/Lighting
• Occlusion Culling
• Physics
• Dynamics
• Collision detection
• Raycasts
• AI
• Pathfinding
• Fuzzy controllers
• Planning/A search

• SCRIPT
• Graphics
• Time-of-Day
• Add/Remove lights
• Loading/moving objects
• Physics
• Object mass/friction
• Collision events
• Raycasts events
• AI
• Path selection
• Decision making
• Goals/objectives

61
Interfacing Between Game Engine and Scripting
Languages

• There is an increasing demand for customizable
  applications and make configuration decisions at
  execution time. Users also want to write macros
  and scripts to increase productivity.
• Split complex system into two parts kernel and
  configuration.
• The kernel implements the basic classes and
  objects of the system.
• The configurations part, connects these classes
  and objects to give the final shape to the
  application1.
• Requires interfacing between the main engine and
  the scripting layer

62
What interface should the game engine provide?

• There are several tasks the main engine of a game
  should provide to the underlying scripting engine
• Store local and global variables
• Getting a reference to an object or a set of
  objects in the world
• Access properties of objects, and ask them to
  perform actions
• Provide a timing mechanism
• Writing custom event handlers
• Building the static world at run time
• Goal setting and modification
• Debugging scripts

63
Store local and global variables

• The game engine should allow the script to store
  local and global variables.
• The engine should be responsible for allocating
  memory for those variables, deallocating them,
  and keeping track of variable values.
• local variables are local to a certain object.
  For example, the script can decide to add an
  anger factor for each character in the game.
  This would be stored as a local variable for the
  character.
• A global variable has just one instance overall
  the system. This would include time of day,
  gravity, and so on.

64
Getting a reference to an object or a set of
objects in the world

• The script should be able to query the game
  engine to return a reference to one object, or a
  set of objects obeying certain criteria. For
  example, the script should be able to ask the
  engine to get a reference to the main player, to
  the nearest monster to the main player, or to the
  set of monsters of a certain kind. This is one of
  the cases where the interface will strongly
  depend on the game engine. For example, if not
  all objects are stored in memory at the same
  time, the script may not be able to get a
  reference to all objects in the level (only the
  active ones). The engine should be designed to
  hide these internal details as much as possible.

65
Access properties of objects, and ask them to
perform actions

• This follows naturally from point 2 above. Once
  the script has obtained a reference to an object,
  it should be able to read properties (health,
  location, ), change properties, or ask objects
  to perform certain actions (get angry, walk to
  point X, etc)

66
Provide a timing mechanism

• The game engine should provide the scripting
  engine with a timing mechanism. The script should
  be able to ask the engine to call a certain
  function each X seconds. Again, the engine should
  support both local and global timers. Local
  timers are called per object. Global timers are
  called once for the entire game.

67
Writing custom event handlers

• Writing custom event handlers The scripting
  engine should be able to write custom event
  handlers for characters. This should include
  writing custom event handlers for what a
  character should do when it gets angry, when it
  needs to move between 2 points, and so on. The
  list of events the script can override clearly
  depends very much on the game, and the nature of
  character under control.

68
Building the static world at run time

• This is one of the features that are very hard to
  support for technological reasons. Static levels
  are usually compiled offline. Changing the world
  at run time may not be feasible for some games,
  but adding it adds more power to the scripting
  language. For example, building a random level
  can become feasible in this case (for example,
  turning Doom 3 into randomly generated pacman
  game!). At least, changing some properties of the
  static world should be allowed. Examples include
  changing translucency of certain walls.

69
Goal setting and modification

• Goal setting and modification This is really a
  special case of object referencing, but it
  deserves separate mention. The game engine should
  allow the script to specify the criteria for
  achieving certain goals, and ending the level.
  Internally, the goals may be represented as just
  special objects, therefore, this could be a
  special case of object referencing and
  modification. However, script writers need not
  know about that.

70
Debugging scripts

• The game engine should make script debugging as
  easy as possible. This includes at least allowing
  the scripts to print debugging messages. More
  advanced cases could allow logging variables,
  call stacks and so on.

71
What interfaces should the game engine NOT provide

• This is the list of taboos. In other words, what
  interfaces should the game engine not provide to
  the scripting engine. Providing those interfaces
  only causes confusion to script writers, makes
  the engine unstable, or will be very hard to
  implement correctly without adding sufficient
  value to compensate for all the efforts.

72
Reveal rendering algorithm

• Allowing the scripts to control the rendering
  engine is not a good idea. Usually, script
  writers will not be able to understand or write
  efficient code. This is one of the areas best
  left untouched.

73
Reveal memory allocation algorithm

• Allowing the scripts to allocate memory
  explicitly is a bad idea. Untalented script
  writers will end up creating really inefficient
  mods.

74
Allow scripts to escape from the sandbox

• This is the most dangerous of all. Gamers usually
  assume game mods are safe. Allowing script
  writers to escape from the sandbox is a
  nightmarish scenario. Gamers innocently install
  game mods. This becomes worse when game servers
  install new maps (potentially including scripts),
  which could compromise security of the client
  computer. In this case, you can innocently join a
  deathmatch game, and end up with a spyware or
  virus on your computer