MYP Design Game Design Fundamentals Notes

A Game Is a Loop the Player Wants to Repeat

1. The core loop is the short chain of actions a player does over and over, so in a platformer it is run, jump, collect, avoid, repeat.
2. If that loop is dull in the first minute it will still be dull in the fortieth, whatever you bolt on top of it.
3. Rules say what a player may and may not do, and they are what turn an activity into a game rather than a toy.
4. A goal gives the loop a point, whether that is a score to beat, an exit to reach or a base to defend for 10 waves.
5. Win and lose conditions have to be obvious, because a player who cannot tell whether they are doing well soon stops caring.
6. The limits are where the interest comes from, since chess without the rule that a bishop stays on its own colour is just pushing wood around.
7. Sketch your loop as four or five boxes joined by arrows before writing a line of code, and put that sketch in your design folder.

Mechanics, Dynamics and Aesthetics: Three Views of One Game

1. Mechanics are the rules and systems you actually build: gravity, a health value, a jump that clears three tiles.
2. Dynamics are the behaviour that appears when real players use those mechanics, such as hoarding ammunition, speedrunning or camping in a corner.
3. Aesthetics are the feelings that come out of it: tension, triumph, curiosity, the urge to have one more go.
4. Designers build mechanics while players experience aesthetics, which is why changing one number can change the whole feel of a game.
5. Doubling the time an enemy takes to respawn is a mechanic edit, but it makes players explore instead of rushing, and that is a dynamic.
6. Work backwards from the feeling you want and then pick mechanics likely to produce it.

Difficulty Should Climb in Steps, Not a Straight Ramp

1. A difficulty curve is how much the game demands across its length, and it should sit just ahead of the player's growing skill.
2. Too easy is boring and too hard is infuriating, and the narrow band between them is where people keep playing.
3. A real curve looks like a saw blade: each new challenge spikes, eases as the player masters it, then spikes higher than before.
4. Put a quiet stretch straight after a boss, because the rest makes the next spike feel larger for free.
5. Failure should be cheap and fast, so a restart after death takes 2 seconds rather than 30 seconds of loading screen and cutscene.
6. Give struggling players a route through, such as an optional checkpoint or a slower enemy setting, rather than a wall they abandon.

Feedback Is How the Player Knows It Worked

1. Every press needs an answer within about 100 milliseconds, or the controls feel broken however correct the code is.
2. Feedback arrives in layers: a visual flash, a sound, a number popping up, a rumble in the controller.
3. A score turns invisible progress into a number a player can chase and compare with a friend.
4. Health bars, ammunition counts and timers show the state of the game continuously so nobody has to guess.
5. Bad news needs to be as clear as good news, so a missed shot should sound different from a hit.
6. Stacking small responses onto one action is nicknamed juice, which is why a coin that spins, chimes and throws up a bouncing number beats one that silently vanishes.

Level Design Teaches Without a Tutorial

1. A good level teaches its own mechanic without a wall of instruction text.
2. The reliable pattern is introduce it somewhere safe, test it with a small risk, then combine it with something learned earlier.
3. The first screen of Super Mario Bros teaches running, jumping, enemies and the reward block with no words at all.
4. Place the first appearance of any hazard where failing costs a few seconds, not a whole level's progress.
5. Steer the eye with light, colour and shape so the player heads the right way without an arrow drawn on the screen.
6. Vary the pace, because fifteen minutes at the same intensity leaves a player numb rather than excited.

Sprites, Collision and Score: The Parts You Build

1. A sprite is the image drawn for a character, enemy or pickup, normally a PNG with a transparent background.
2. Each sprite has a position stored as x and y coordinates, and moving it a few pixels every frame is all that motion is.
3. Collision detection asks whether two objects overlap, and the cheap standard method is an axis aligned bounding box around each one.
4. Two boxes touch only if they overlap on the x axis and on the y axis at the same time, which is four comparisons per pair.
5. The hitbox is often drawn smaller than the sprite, because players forgive a near miss and resent a hit that looked like one.
6. Score is just a variable starting at 0 that goes up when a collision with a coin is detected, then gets drawn to the screen each frame.
   1. How to write the conditions and loops that run those checks belongs with the programming logic articles in this unit.

Playtesting Is the Only Way to Find Out

1. Playtesting means handing the game to someone who has never seen it and then keeping quiet.
2. Do not explain the controls, because anything you have to say out loud is something your game currently fails to say for itself.
3. Write down the exact moment they hesitate, die twice in the same spot, or stop looking at the screen.
4. Ask afterwards what they thought they were supposed to do, which uncovers problems that watching alone misses.
5. Balancing is adjusting the numbers, jump height, enemy speed, coin value, until the game lands in that band between boring and unfair.
6. Change one number at a time and test again, or you will never know which change did the work.
7. Log every test in a table with the date, the tester, what went wrong and what you changed, which is exactly the evidence Criterion D asks you to show.