Transcript Process of creating games Game Design Vishnu Kotrajaras, PhD

Process of creating
games
Game Design
Vishnu Kotrajaras, PhD
The process, in short

Brainstorming
– Come up with as many ideas as you can.
– Narrow down to 3.
– Write 1 page describing each idea.

Choose one out of three.
 Physical prototype
– Use pen & paper.
– Playtests
• Within here, if problems arise, you may have to
brainstorm and playtest to solve such problems.
• You need to play and adjust your game several times.
– Once finished, write up 3-6 pages about the game
and how to play them.
The process, in short(2)

Presentation(optional)
–
–
–
–
Used to secure fund.
This is another chance to get feedback.
Present demo artwork and detailed gameplay.
Modify game to fit the sponsor’s need, or cancel
the project if things aren’t going well.
– This may not be applicable to today’s market since
big publishers won’t accept your work unless you
are famous enough.
– You are more likely to finish the game and sell it
through an indie channel.
The process, in short(3)

Software prototype
– Do not do graphics, just find ones that can be used easily.
– Iteratively testing the prototype.

Design document(draft)
 Production
– Work with everyone, making sure each design idea is
correctly presented in the document.
– Do real art and programming.
– Still, test and evaluating a work in each step along the way.
– Do not add additional concepts, unless absolutely
necessary.
The process, in short(4)

Quality control
– Playtest again and again before launching.
Physical Prototype
Do it, if you can.
 It is better to tune things this way before
coding.

– You can get feedback right away.

If flaws come out, it is much easier to fix
things at this stage.
Notes on prototyping

Human can track 7+-2 concepts at once. (1956,
George Miller)
 Phone numbers are 7 digits long.
 Tetris includes 7 shapes.
 Thus real concepts of the game must be simple
enough for human to grasp.
 Prototyping help enforces that.
– Vague rules become more concrete.

Try modifying the prototype to get a better play.
From board to computer

Diablo 2, baldur’s gate, EverQuest,
Asheron’s Call, Dark Age of Camelot.
– Based on D&D.

Civilization.
Civilization
Wooden Ships & Iron Men
Shockforce
BattleTech
FPS as a board game: an example
You may use a hexagonal graph paper.
 Then construct walls and spawning
points.

– Make them repositionable.
– Matchsticks are perfect for this.

Then place units. A unit must show
which direction it is facing.

Each player gets the following 9 cards
– Move 1 space x1
– Move 2 spaces x1
– Move 3 spaces x1
– Move 4 spaces x1
– Turn any direction x2
– Shoot x3

Each player chooses 3 cards and place them face
down on the table in a stack.
 Each player turns over his top card.
– Resolve shoot:
• Players with a shoot card fire in the direction their unit is facing.
• If the shooting line intersects with a cell containing another unit,
then it is a hit.
• Shots happen simultaneously for all players
– Resolve turn cards:
• Players with turn cards turn their unit to any direction they want.
– Resolve move cards:
• Players move their unit according to move cards they have in
hand.


Repeat all steps for the 2nd card and the 3rd card.
If a unit is shot, remove it from the game and
regenerate it at a spawning point at the beginning of
the next round.

Possible additions
– Scoring system. Headcount maybe.
– Hit and miss percentage based on how far on the
grid.
• Use 10-sided die.
• 100% at adjacent grid, and reducing by 10% for each
grid distance.
– Hit points
• Try 5 hit points, one removed when hit.
– First aid point on the map.
– Ammo and ammo point.
– Other weapons.
But isn’t there limitations?
Not 3D experience, not real time?
 Do not worry, the structure of the game
is more important at this stage.
 Physical prototyping forces you to think
through the design elements and define
them.
 Programmer can grasp you vision from
it.

Mage knight
Tips on physical prototype

Start with a core mechanic.
– In FPS example, we allow simultaneous movement right
away to capture the real time core gameplay.

Add things that are important first.
– If you add some features, the overall rules will need to be
added or changed to support it.
– Rules come before features.
– You can try removing a rule to see if the game still works.




After the gameplay is good, you can add details.
Add detail only one feature at a time. Test feature
one by one.
If the gameplay is bad, try removing a feature and
test again.
Use flowchart for visualisation.
If you are stuck


Try changing unlimited resource to limited, or vice
versa.
Add ability for player to stop or change actions of
other players.
– Thus creating new play strategies, such as counter attack or
cooperation.

Allow players to change the order of events in the
game.
– Such as speeding up his own turn or forcing his opponent to
skip turn.


Remove a rule from the game, especially a rule that
does not really have anything to do with the core
mechanic.
Double of half a variable’s value.
Software prototype

Software prototype is the additional of small
parts, itself still not a complete game.
– Demo
– A level

These must show the gameplay.
– Includes what we said in the game’s focus.

By getting a small piece of the game working,
we can get a sense whether the final game
will be fun or not.
– Can adjust or even cancel the project.
Non-intuitive
, need fixing
If you still have no fun prototype,
Do not





Do detailed design document.
Script the game’s dialog.
Make a detailed map.
Make a full level.
Draw real art.
Bad thing about detailed levels, art,
or documents

These things make assumption about
the gameplay, which maybe incorrect.
– Wasted effort because the game is likely to
be changed.
– People who work hard on them will cling to
them (keeping the non-working things).
• Making the game bad if it includes such work.

Remember, the more people you have,
the harder it is to change your game.
Example 1: Odyssey: The Legend of
Nemesis

Richard Rouse inherited a game engine and
some portion of the game from previous
developer.
 First, a six page document to the publisher
– One page per one map.
– By the time he had implemented the 2nd island, he
know enough to throw some other islands away.
– Didn’t lose much work, because the early design
was not too detailed.
Odyssey: The Legend of Nemesis
Second, develop it using place-holder
art (inherited from another project).
 No fear of losing an already created art.
 Hire an artist to draw replacements
later.

Example 2: Centipede 3D

Original gameplay idea.
 But created 6 levels!!
 More levels on paper!!
 Then find out that it was not fun.
– Adjust the gameplay.
– But had to throw away existing levels, and levels
on paper.
– If the designer kept them, it would be worse.
Centipede 3D
Prototyping stages

Initial Core Gameplay
– Test only the core.
– See if it is fun.
– You may probably be testing (repeatedly) on your own.

Try for an audience
– Add enough structure for your friends (people without full
vision of the game) to play.
– Test for functionality and fun (repeatedly).

Try the full functionality
– Test for the game’s weakness and balance (repeatedly).

Refinement
– Test for fun and accessibility (repeatedly).
Useful software or programming
environments for prototyping




Flash
Macromedia Director
Game Maker
NeverWinter’s Aurora toolset
– So good for designing 3D game.






TorchEd
Panda3D
Unity
Unreal 3
Mod from Half-Life (such as Counter Strike).
Level Editor of Warcraft 3
– You must play with it if you want to design RTS.
Game maker
Aurora
Some games really need software
prototype
Tetris.
 Space war game.
 Whenever paper model becomes too
difficult.
 Remember to use the tool that allows
fastest change.
 Do not think of reusing the code here.

Problems in a big company

Artists, level designers, system coders start
working at an early stage.
 Publisher may want to see a complete design
document before anything.
– No choice, have to do what the sponsor says.
– If possible, self-fund until you get the gameplay
prototype working.
– Good prototype will help getting the funding later.
Building the game (Production)
Build core technology
 Complete one system or mechanic
before moving on to the next system
that depends on it.
 It’s difficult to have a different team
code systems in parallel.

Building core technology

Game engine must be built first
– Does not have to be completed before we
can start making the 1st playable version.
– We don’t always know the limitation of
technology.
• We may first design 10 enemies on screen, but
the engine can only support 3. Therefore we
must change the design.
Incremental steps

Break down the design into tasks,
fundamental and dependent tasks.
– Sidescroll platform: getting the player’s navigation
system working is the first thing to do.
•
•
•
•
Forward, backward, turning.
Work on it until it feels good.
Then add more movement: crouching, jumping.
Make sure they don’t break previous movements. All
must work well together.
– Then add attack movement: test until it feels right.
– Then add enemy.
example steps for adding enemy
and items






First, just get an enemy in the world so the
player can attack.
Then get it moving around.
Then get it to do its attack.
Then add item into the world.
Next, allow player to pick it up, and throw it,
etc.
In each and every stage, the game must be
playable and fun.
– When you add a thing that break previous
elements, fix it immediately .
Try to play your game throughout
the development

It is very easy to lose sight of your gameplay
if you spend a lot of time in an unplayable
state.
 If team member can pick it up and play,
they’ll have clearer idea of what they are
working on.
 If a thing that someone adds make the game
less fun, you’ll see the effect immediately .
The first full level in the game

Once all mechanics are working as you like
them, start making a level.
 When you test the game on a level, you’ll find
missing features of your game.
 Make this level as close to the intended final
state as possible before moving on to other
levels.
– You’ll learn a lot from a level, saving you a lot of
time when creating other levels.
– But since you will have modified this first level a
lot, it will not be a good level compared to any
future levels you make.
– It is normal to throw away this first level.
Careful about difficulty level
When doing your first level, you’ll have
a chance to adjust general difficulty
level of the game.
 Have some friends play the game.

– Observe how easily it is to pick up.
– If it is harder to play than you expect, you
must change the design immediately.

Beware of getting used to flaws:
– Unintuitive controls.
– Unfair enemy moves.
Going through changes
Throwing away art, code, levels, and
even design is something to be
expected.
 Everyone must be brave enough to
throw them away.
 Good work may not fit in the game,
remember this.

But don’t overdo it

Designer may get bored of the kind of level
he makes, and decide to redo the level just to
get something new.
 You must stop him from doing it! For players,
this level will always be new when they play
the game for the first time.
 If the gameplay is already good, don’t change
things.
Programming and designing


We need constant feedback between
designer and programmer.
A designer who can program has
advantages:
– Can experiment with his ideas.
– Can understand technology limitations.
• Example: sword change shape when
enchanted…(engine cannot do).
– Engine can do some particles around the
sword though. Designer may in fact be
perfectly happy with this solution (but he
doesn’t know the limitation of the engine).
Different gameplay ideas between
designer and programmer
Programmer may pretend that it is hard,
when in fact he does not like the idea.
 Designer who does not know the
technology will be taken advantages of.

If the designer don’t program
A lead programmer must have a good
sense of gameplay.
 Otherwise, the project may fail.

Conclusion: Iterative & incremental
process
No problem
problem
Generate ideas
Make prototype
Evaluate results
playtest
Iterative process diagram [FSH]