# Game Creation Lab

Build Crystal Courier: a small browser game about collecting crystals, avoiding patrols and reaching the exit.

## 1. What makes something a game?

A game gives players actions, rules, goals and feedback. A toy can be enjoyable without a fixed win condition; a game often adds a challenge to work toward. Start by describing what the player does repeatedly and why the next attempt might be interesting.

Experiment: Describe your game in one sentence: the player does X to achieve Y while facing Z.

Question: Which description is a playable starting point?
Answer: Collect crystals while avoiding moving hazards

## 2. Mechanics, dynamics and experience

A mechanic is an implemented action or rule, such as movement, collection or losing a life. Dynamics are patterns that emerge when rules interact, such as waiting for a patrol to pass. The experience is how play feels. A speed slider changes a parameter; the consequences depend on the level and goals.

Experiment: In the prototype, identify one rule and one behavior it encourages.

Question: Which is a mechanic?
Answer: Losing a life on hazard contact

## 3. Find the core loop

The core loop is the repeated sequence that makes play meaningful: observe, choose, act, receive feedback and adjust. Crystal Courier asks the player to read a route, move, collect and avoid. A strong small loop is a better prototype target than many disconnected systems.

Experiment: Play one short run and write the repeated decisions you made.

Question: What should you prove first?
Answer: A working, interesting core loop

## 4. Goals and success conditions

Players need to understand both the immediate task and the finish condition. This game requires all crystals before the exit activates. A score alone is not always a goal; explain what the player is trying to achieve and how they know they have done it.

Experiment: Use stage 6 and test the exit before and after collecting every crystal.

Question: When does this prototype allow a win?
Answer: All crystals collected and exit reached

## 5. Meaningful choices

A choice matters when alternatives have different consequences the player can understand. Two paths can trade safety for speed. If every route has the same cost, the apparent choice may be cosmetic. Keep the consequences readable enough for a learner to reason about.

Experiment: Create a safer long route and a shorter hazardous route in the editor.

Question: Which creates a meaningful route choice?
Answer: Different risk and travel time

## 6. Scope a finishable first game

Choose one arena, one player action and one clear ending. A complete small game includes instructions, restart, pause and failure handling. Write down what you will leave out. The export here is a standalone browser prototype, not a multiplayer engine or a commercial production pipeline.

Experiment: Name three features your first version will deliberately omit.

Question: What is a good first milestone?
Answer: A complete small playable loop

## 7. Represent the world as data

The level is an array of eight strings, each twelve tiles wide. Symbols describe walls, crystals, hazards, a start and an exit. The renderer interprets the data, while game logic uses it for collisions. Keeping layout separate from behavior makes experiments faster.

Experiment: Paint a wall and observe the changed level text.

Question: Why separate level data from drawing code?
Answer: Layouts can change without rewriting every rule

## 8. Input is an intention

Record which keys or controls are held, then read that state during updates. A keydown event should not be the only thing moving a real-time character because keyboard repeat varies. Clear input when focus is lost to prevent a stuck direction.

Experiment: Hold two movement directions and then release focus; confirm movement stops or pauses.

Question: Why track held input state?
Answer: For predictable continuous movement

## 9. Movement and time

Velocity describes units per second. Multiplying it by elapsed time gives a frame displacement. Normalizing a two-direction vector prevents diagonal movement from being faster. This prototype caps long frame steps to reduce large jumps; under stalls, its simulated time can run slower than wall-clock time.

Experiment: Compare player speeds of 120 and 240 while leaving the level unchanged.

Question: Why normalize diagonal input?
Answer: To keep diagonal speed consistent

## 10. The update and render cycle

An update changes state; a render displays it. Keeping those responsibilities distinct makes the rules easier to test. requestAnimationFrame schedules browser drawing opportunities. The game should stop updating when paused and avoid starting duplicate loops on restart.

Experiment: Pause a run and verify the timer and player position remain unchanged.

Question: Which part changes the game state?
Answer: The update step

## 11. World bounds and walls

A collision shape is a simplified representation of an object. This prototype checks a small axis-aligned player box against wall tiles, moving each axis separately so the player can slide along a wall. Its visual circle is not a pixel-perfect collision mask.

Experiment: Try moving diagonally into a wall and inspect the sliding behavior.

Question: Must collision exactly match every visible pixel?
Answer: No, a suitable simplified shape often works

## 12. Collectibles and one-time events

A collectible changes state once: remove its tile, add to score and communicate the result. Leaving the item active while repeatedly checking overlap can award points every frame. In this prototype, entering the collectible tile is the collection rule.

Experiment: Stand on a collected tile and verify the score does not increase again.

Question: How can repeated scoring be prevented?
Answer: Remove or mark the collectible after collection

## 13. Hazards and readable motion

A moving hazard creates a timing problem. Predictable motion helps a beginner learn and plan. The prototype hazards patrol horizontally and reverse at walls. Randomness is not automatically better difficulty: it can make outcomes harder to explain or compare.

Experiment: Place a hazard in a short corridor and observe its turnaround points.

Question: What makes a basic hazard easier to learn?
Answer: Readable, consistent behavior

## 14. Lives and recovery

After a hit, the player loses one life and returns to the start with brief protection. Recovery prevents a single overlap from consuming all lives instantly. Lives and checkpoints affect the cost of failure; decide whether that cost supports learning or merely repeats solved sections.

Experiment: Try one and five lives; compare how much you are willing to experiment.

Question: Why give brief protection after a hit?
Answer: To prevent immediate repeated damage

## 15. States: ready, playing, paused and ended

Treat the game as distinct states. Movement belongs in playing; instructions and start belong in ready; a finished run should not keep awarding points. Explicit states reduce accidental behavior such as the timer running after a win.

Experiment: Win or lose a run and confirm the displayed state and controls make sense.

Question: Should the game continue normal scoring after a win?
Answer: No

## 16. Win, lose and restart

A restart must reset every run-specific value: position, collectibles, lives, elapsed time and hazard positions. Keep persistent learning notes separate from run data. Test multiple consecutive restarts because leftover state often hides on the second run.

Experiment: Collect one crystal, restart, and check that it reappears with score zero.

Question: What belongs in a restart reset?
Answer: All run-specific state

## 17. Feedback closes the loop

A player should notice an action and understand its consequence. Use position, shape, text and state changes rather than relying on one color or sound. More visual effects are not always better; feedback should explain the important event without obscuring play.

Experiment: Identify how this game signals a pickup, hit, pause and win.

Question: What is the main job of feedback?
Answer: Explain the consequence of an action

## 18. Difficulty is a relationship

Difficulty emerges from movement speed, hazard behavior, level geometry, goals and time pressure together. Increasing speed may help escape a hazard but make precise movement harder. Tune one variable at a time and record what changed.

Experiment: Use the tuning panel to change only hazard speed, then replay the same level.

Question: Why change one variable per experiment?
Answer: To attribute the observed effect more clearly

## 19. Risk, reward and routes

Reward can justify a risky action, but the player should understand the tradeoff. In this prototype every crystal is required, so placing one beside a hazard creates mandatory risk rather than an optional bonus. Change the rules before claiming a collectible is optional.

Experiment: Describe how you would add optional bonus crystals without blocking the exit.

Question: Are all crystals optional in the current prototype?
Answer: No, every crystal is required

## 20. Teach through level design

Introduce a mechanic in a safe space, ask the player to use it, then combine it with a familiar mechanic. Avoid presenting every challenge at once. The first room can teach movement and collection before adding a moving obstacle.

Experiment: Build a safe first crystal and put a hazard later along the route.

Question: What is a useful teaching sequence?
Answer: Introduce, practice, combine

## 21. Fairness and telegraphing

A failure feels more understandable when the danger was visible and avoidable. Distinguish a difficult decision from an unpredictable penalty. Review spawn positions, narrow corridors and time limits for situations where a player has no reasonable response.

Experiment: Check that no hazard starts on the player and that the first route gives room to react.

Question: Which is most useful for fair difficulty?
Answer: Visible threats and understandable consequences

## 22. Access and control options

Keyboard, pointer destinations and on-screen direction controls offer different ways to interact. Pause and adjustable time pressure can help more players participate. A canvas action game still needs additional work for full nonvisual access; this prototype does not claim that its text HUD replaces the spatial experience.

Experiment: Try keyboard-only and touch-style controls; then remove the time limit.

Question: Do multiple input methods alone guarantee full accessibility?
Answer: No

## 23. Ask a focused playtest question

A playtest works best when it investigates a specific uncertainty. Ask whether a new player finds the goal or understands a hit, rather than asking only whether the game is fun. Observe behavior before explaining your intended solution.

Experiment: Write one question in the playtest notebook before the next run.

Question: Which is more actionable?
Answer: Did the player find the exit goal?

## 24. Separate observation from interpretation

Record what happened first, then propose why. A player waiting beside a hazard might be confused, planning, distracted or enjoying the timing. Ask a follow-up rather than treating your first explanation as fact.

Experiment: Write one observation and two possible explanations for it.

Question: Which is an observation?
Answer: The player waited ten seconds at the doorway

## 25. Measure without overclaiming

Completion, collected crystals, remaining lives and time can reveal patterns. Small samples do not prove a universal preference. This lab stores up to twenty completed full-game runs with their tuning settings; staged walkthrough runs are not recorded as full tests.

Experiment: Compare two runs and identify what you still cannot conclude.

Question: Does one successful run prove the design is balanced?
Answer: No

## 26. Level reachability is not enough

A flood-fill can confirm that required tiles are connected through non-wall spaces. It does not prove the level is enjoyable, fair under moving hazards or completable before a timer expires. Automated checks complement actual playtesting.

Experiment: Use the editor to block a crystal, then reopen a route and play the result.

Question: What does the editor’s route check establish?
Answer: Static connectivity

## 27. Debug by reducing the case

Reproduce a bug with the smallest level and simplest settings. Separate input, movement, collision and rendering questions. A clear reproduction such as restarting after a hit is more useful than a vague report that the game sometimes breaks.

Experiment: Create a tiny empty route to test movement before adding hazards.

Question: What helps isolate a bug?
Answer: A small repeatable case

## 28. Write instructions that match the rules

State the action, objective and consequences in a few clear sentences. Include controls and pause behavior. Avoid promising mechanics that the implementation does not have. Your instructions should remain correct after changing settings or editing the level.

Experiment: Review the exported game’s instructions against its actual rules.

Question: What should instructions describe?
Answer: The rules players actually encounter

## 29. Export and test the real build

A local preview is not the final environment. Download the standalone HTML game and test it separately on your target devices. This game has no external assets or libraries. Hosting can still impose policies, and a downloaded file should be checked before distribution.

Experiment: Export the game, open it separately and test start, pause and restart.

Question: What should happen after export?
Answer: Test the exported file itself

## 30. Plan the next version

Choose the smallest change that addresses an observed problem. Keep a short change log with the hypothesis, implementation and result. Good design is an iteration process, not a promise that more mechanics will automatically make a better game.

Experiment: Write a one-change next-version plan in the notebook and export it with your level.

Question: What is a strong next iteration?
Answer: One justified change and a test