1 of 56

OnePD Feedback Day!

Faculty of Mathematics and Physics

Charles University, Prague

Vojtěch Černý

Game Development I

2 of 56

What do you get?

This course gives three kinds of feedback

Peer reviews
Personal feedback
General feedback

3 of 56

Project A

17 projects available on-line (as of yesterday)
Altogether, many cool ideas!
Receiving up-to 20 points

4 of 56

Feedback

Pay attention to it, incorporate it

You should always listen to the feedback.

Except when you shouldn‘t

5 of 56

A smart person learns from his mistakes,

but a truly wise person

learns from the mistakes of others.

6 of 56

Shown examples

Demonstrate only the current point, might be lacking in something mentioned on other slides

7 of 56

The main point

8 of 56

The level layout is too small

Text

LEVEL SKETCH

9 of 56

The level layout is too disattached

Text

LEVEL SKETCH

10 of 56

Make the level layout the king

LEVEL SKETCH

Text

11 of 56

Example

12 of 56

Example

13 of 56

Example

14 of 56

Text vs graphical

Text is a back-up plan

It is used whenever you can‘t explain some design purely visually

But if you can‘t say it visually, write it down

15 of 56

Technical low-level

16 of 56

Hand-writing

Technical-people hand writing often hard to read

Medical doctors are even worse

This is not how your handwriting looks

17 of 56

Pick a good font

18 of 56

Rasterized graphics tools

Vector tools are so much better

19 of 56

Color palettes

Using similar colors for different things
Using different colors that aren‘t in the game
Not being consistent

Doors that are hard to see

20 of 56

Providing legends

Good idea
Squares of different colors might be hard to distinguish/understand

Ordering?

Start to finish
Group logical things together (Chomper+Spitter)

21 of 56

Using in-game graphics

22 of 56

Partially using in-game graphics

23 of 56

Using close-to-ingame graphics

24 of 56

Not being clear

Don‘t let the implementer design things

He will have a lot of freedom anyway

What‘s fine:

The damage of these enemies should be tuned to adequate difficulty

25 of 56

Describing technical details

26 of 56

Describing the big picture

27 of 56

Put yourself in the reader‘s shoes

Similar to writing/commenting code

Try to streamline the understanding process

What would you like to read first? What last?

28 of 56

Hacker mentality

Try to carefully examine every piece on

„What can go wrong?“

In some ways, your whole design can be broken by a single weak link...

29 of 56

Gameplay

30 of 56

Redoing everything

Somebody will have to implement that level
Using just 2D GameKit features is fine

Make real estimates

(coding is hard to estimate)

Maybe you don‘t need 17 power-ups?

31 of 56

Small easy changes

Timer lasting 2 minutes and the game restarts if it is not beaten
Moving pillars/platforms with spikes
Limited ammo
Having slow/fast bullets (scripting HW)
Forbid kneel
Slower gravity in a part of the level
...

32 of 56

Show the jump height

Absolutely key to understanding the design
In regards to blocks
Also show the jump-length?

33 of 56

Moving platforms

Mention the speed
How are they synchronized?

Can be mentioned as the kind of experience you want to provide

34 of 56

Movable boxes

Pressing buttons
Squishing enemies

Show how they should be used
Dead ends possible?

35 of 56

Enemies

Melee and ranged

Field of view?

Angle & size

Best way(s) to deal with?

36 of 56

Define the scale of your objects

It is important how big the objects are

37 of 56

Respect the boundaries of Kit

The kit is tile-based
Has a lot of things implemented

Making everything different may be hard to implement

38 of 56

Work on a grid

39 of 56

Mentioning vague ideas

„There should be either X or Y“
„There should be something like X“
„There should be an X (without explaining, assumes everybody knows it)“
„There should be a fight scene“
Just a picture of an element without describing how it works

40 of 56

Be clear and concise

41 of 56

Golden thread

Prevents misunderstanding on how should things work

42 of 56

Show connections

43 of 56

Describe your design

Explain the problem the player will face

Understand what he‘s likely to think

Maybe very different from your own

Make the implementer understand

44 of 56

Describe your design

Good example:

This area is supposed to teach the player the jump action and that he jumps further when holding the key. Thus, the last jump should be far, reachable only when the key is held.

45 of 56

Describe your design

46 of 56

Estimate the length of the level

Submissions have vastly different lengths

Estimates are hard

Visualize the player playing the level
Mock-up level without features

47 of 56

Subjective gameplay

48 of 56

Difficulty

Maybe surrounding the player with many enemies is too hard?
Do the enemies serve a point (repetitiveness)

Make sure the player can deal with obstacles individually before you recombine them

Difficulty curve

49 of 56

50 of 56

Introducing obstacles safely

51 of 56

Dead-ends

Can the player get stuck?

Forcing the player to restart the level because of running into a dead-end

Is it fun?

52 of 56

Variability

Maybe too much to ask?

Simple alternative playthroughs are good
Adding secrets?

Make sure to explain clearly in the design

Random power-ups are maybe too out of control?

53 of 56

Journal entries

We read them, often
Write more subjectively:

What you‘ve done is mostly clear
What was easy and what hard isn‘t
Any extra thoughts are much appreciated

There should be (at least) one each week!

54 of 56

Expert review: GMTK

55 of 56

Wrap-up

Project B starts now!

By a wheel of fortune, it was decided that this year, you will implement your own Project A‘s
Start now!

Project B – implement the game design

Your own or someone‘s?
Stick to the GDD (for real)
Weekly (!) journal
Deadline: 2nd practical in April

56 of 56

Discussion & Consultation

Any questions?