Process of creating games Game Design Vishnu Kotrajaras, PhD

Preview:

Citation preview

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 Shockforce

Wooden Ships & Iron Men 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.

Aurora

Game maker

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

Generate ideas

Make prototype

playtest

Evaluate results

Iterative process diagram [FSH]

problem

No problem