# Skybound Studio: Game Development Handbook

## 1. Your first playable idea

A platformer asks the player to move and jump through a space. Skybound adds a clear goal: collect every star and reach the portal. The interesting part is the sequence of decisions between those actions. Begin with one short level you can finish and explain. A complete small game teaches more about finishing than a large list of features.

**Experiment:** Write one sentence describing what the player does, why it is challenging, and how they win. Then play the starter without changing any settings. Notice which rules you understood immediately.

**Check:** Which scope is easiest to test?

**Answer:** One short level with movement, stars and an exit — A small playable loop gives you concrete behavior to observe.

## 2. Mechanics, dynamics and experience

A mechanic is a rule or action: jumping, a checkpoint, or requiring stars to unlock an exit. Dynamics are patterns that emerge from the rules: taking a risky shortcut or returning for a missed star. Experience is how that play feels to a person: tension, curiosity, relief. A rule does not guarantee the same feeling for everyone.

**Experiment:** Add a star above a spike, then move it to safe ground. The collection mechanic stays the same, but the approach and perceived risk change. Ask someone to describe the difference.

**Check:** Which is a mechanic?

**Answer:** A checkpoint changes your respawn position — The checkpoint is an explicit rule. Pride is an experience; route selection is behavior arising from the rules.

## 3. The core loop

The moment-to-moment loop is observe, move, jump, land and reassess. The level loop is collect, reach the portal, review and retry. Feedback should make each transition understandable. A jump that fails without a clear reason interrupts learning; a visible spike and predictable landing help the player form a better plan.

**Experiment:** Play without looking at the lesson. Can you explain what the locked exit requires? Change the star placement so the requirement is introduced before a dangerous jump.

**Check:** What makes a loop easier to learn?

**Answer:** Consistent actions and readable feedback — Players can improve when results reliably follow their actions.

## 4. Data before decoration

The level is twelve strings with twenty-four characters each. A # is solid, o is a star, ^ is a spike, C is a checkpoint, S is the start and E is the exit. The renderer draws pictures from these symbols. The same data drives collisions and rules, so changing a tile changes gameplay without rewriting the engine.

**Experiment:** Open the level editor. Paint a platform, then inspect the level JSON. Find the exact row and character you changed. Export a backup before a large redesign.

**Check:** What should level data describe?

**Answer:** Where gameplay objects are placed — Structured level data separates layout decisions from the code that interprets them.

## 5. Coordinates and collision boxes

Canvas coordinates increase to the right and downward. Each tile is 32 logical pixels. The player has a 20 by 26 pixel collision box. Art can be decorative, but the collision shape determines contact. This engine uses rectangles for solid blocks and smaller inset rectangles for stars, spikes and portals. The spike art is triangular; its collision is deliberately simpler.

**Experiment:** Turn on debug mode and approach a wall. Compare the visible character with its outlined collision box. Explain why a drawing and a collider do not have to be identical.

**Check:** Which direction is positive vertical motion?

**Answer:** Down — This canvas uses a downward-positive Y axis.

## 6. Velocity is change over time

Speed is measured in logical pixels per second. Movement uses x += vx * dt so distance depends on simulated elapsed time. At 200 pixels per second, a half-second of unobstructed movement covers 100 pixels. This engine uses immediate horizontal velocity: releasing a direction stops horizontal motion. That is a design choice, not realistic inertia.

**Experiment:** Use the speed coding challenge. Compare a speed of 140 with 280 in the same level. Record where precision becomes more difficult.

**Check:** At 200 px/s for 0.5 seconds, distance is…

**Answer:** 100 pixels — Distance equals speed multiplied by elapsed time.

## 7. Gravity and jump impulse

A jump assigns a negative vertical velocity. Gravity adds positive velocity each physics tick. The character rises, slows, reaches zero vertical velocity, then falls. Jump strength changes the initial impulse; gravity changes how quickly that impulse is overcome. Tuning both together controls height and airtime.

**Experiment:** In the physics explorer, keep jump strength fixed while increasing gravity. Predict the new height before reading the estimate, then test it in the game.

**Check:** Increasing gravity with the same jump strength usually…

**Answer:** Lowers jump height — A stronger downward acceleration reverses upward motion sooner.

## 8. A fixed physics step

The display loop uses requestAnimationFrame. An accumulator advances physics in 1/120-second ticks, then draws the latest state. A frame delay is capped at 0.1 seconds, so a long stall does not trigger an unlimited catch-up. This makes the simulation more consistent, but measured game time can differ from wall-clock time after stalls.

**Experiment:** Pause the game and use Step one tick. Watch vertical velocity change. One tick is not one visible screen refresh; these are separate concepts.

**Check:** Why separate physics steps from drawing?

**Answer:** To update simulation with a consistent time increment — Consistent increments simplify physics tuning while rendering follows the browser.

## 9. Jump height and range

Ignoring obstacles and the falling-speed cap, jump height is J²/(2g). Return time to the same height is 2J/g, and horizontal range is speed multiplied by that time. These are planning estimates. The discrete engine, collision box, ceiling and landing height can change the actual result. A theoretical maximum is a poor required jump for a beginner.

**Experiment:** Compare a three-tile gap with the predicted range. Leave a margin for imperfect takeoff. Then use the level editor to test the same gap instead of treating the equation as proof.

**Check:** Should a beginner gap equal the theoretical maximum?

**Answer:** No, leave a margin and playtest — Real players need room for timing and alignment errors.

## 10. Coyote time

Coyote time briefly permits a jump after leaving a ledge. It makes a nearly-on-time input feel fair. The engine remembers how recently the player was grounded and consumes that grace period when jumping. It is not an extra midair jump. A large grace period changes the reachable space and should be tested with the level.

**Experiment:** Set coyote time to zero and walk off a ledge before jumping. Repeat with 0.12 seconds. Keep other settings the same to isolate the effect.

**Check:** Coyote time means…

**Answer:** A brief jump allowance after leaving ground — It is a short forgiveness window around the edge of a platform.

## 11. Jump buffering

Jump buffering remembers a recent jump press for a short interval. If the player presses just before landing, the engine can jump on the first grounded update. Buffering differs from coyote time: it handles an early press before landing, while coyote time handles a late press after departure. Holding jump does not continually retrigger jumps here.

**Experiment:** Try pressing jump just before touching a platform with buffer set to 0.02 and then 0.18 seconds. The control still requires a new press for each jump.

**Check:** Which setting helps a press just before landing?

**Answer:** Jump buffer — Buffering preserves recent intent until a jump becomes possible.

## 12. Resolve collisions one axis at a time

The engine moves horizontally, resolves wall overlap, moves vertically, then resolves floor or ceiling overlap. Landing sets grounded true and vertical velocity to zero. The approach is compact and useful for tile platformers. It is not a general rigid-body engine: there are no rotated colliders, slopes or moving platforms in this project.

**Experiment:** Jump beneath a ceiling. Observe that upward velocity stops and gravity brings the player down. Then walk against a wall while jumping to test axis separation.

**Check:** What should landing on a floor do?

**Answer:** Place the player above it and stop downward velocity — Collision resolution repairs overlap and updates the relevant motion state.

## 13. Teach safely first

Introduce movement on safe ground, jumping over a harmless obstacle, and only then a dangerous gap. The first screen should teach through arrangement as well as text. A star can indicate a route, but it should not silently lure a beginner into an unavoidable death. Safe repetition builds a useful mental model.

**Experiment:** Load the First steps template. Identify where a new player can practice without losing a life. Add one optional challenge after that practice area.

**Check:** Where should the first required jump appear?

**Answer:** In a forgiving space — Low-cost practice lets players discover controls before stakes increase.

## 14. Use stars as guidance

Collectibles can guide attention, reward exploration or create a tradeoff. In this game every star is required, so a difficult bonus route is not truly optional if a star is placed there. Be explicit about that rule. Decorative empty space and platform shape can also guide a player without increasing the completion requirements.

**Experiment:** Place a line of stars along a jump arc, then move one far away. Does the level now require backtracking? Decide whether that trip supports your intended experience.

**Check:** A star on a hard side route is…

**Answer:** Required in this game because all stars unlock the portal — Rules determine whether a reward is optional.

## 15. Checkpoints change the cost of failure

A checkpoint updates the respawn position after contact. Collected stars stay collected after death in Skybound. This reduces repeated work, but it also changes the challenge: a player can collect a risky star and keep it even if they fail to return. Neither rule is automatically better; choose the experience deliberately.

**Experiment:** Place a checkpoint before a difficult section. Compare retries with the checkpoint farther away. Make sure there is solid support underneath and room around the respawn.

**Check:** What does a checkpoint most directly change?

**Answer:** The cost of retrying after failure — It changes how much progress or travel must be repeated.

## 16. Risk, reward and recovery

Good risk has a readable consequence and a reason to attempt it. A spike costs one life, a fall also costs one, and an exhausted life count ends the run. Generous recovery can support exploration. A trap at the respawn point creates repeated failure without a meaningful new decision.

**Experiment:** Use the editor to place a spike near a checkpoint, then remove it before testing. Design a clear safe landing instead. Write the choice you want the player to make.

**Check:** What makes a hazard more learnable?

**Answer:** A visible threat and a safe way to approach it — Readable consequences help players adapt their strategy.

## 17. Pacing and contrast

Continuous maximum difficulty can become tiring. Alternate introduction, practice, challenge and recovery. A level can feel richer through rhythm rather than more features. Wide platforms after a precision jump give a moment to orient; a checkpoint can mark a new section without adding a menu.

**Experiment:** Build three short sections: a safe jump, a harder variation and a resting platform. Ask a tester where they felt able to pause and plan.

**Check:** Which sequence supports learning?

**Answer:** Introduce, practice, challenge, recover — Contrast gives space to understand and consolidate a skill.

## 18. Validation is not proof of fun

The editor checks dimensions, allowed symbols, one start, one exit, at least one star and support below the start. It warns about unsupported checkpoints. It does not solve platformer reachability or certify fairness. A connected-looking level can still require an impossible jump under the current physics.

**Experiment:** Build a high platform outside your estimated jump height. Notice that structural validation can pass. Add a stepping stone and test the actual route.

**Check:** A structurally valid level is…

**Answer:** Ready for playtesting, not guaranteed completable — Validation catches specific data errors, not every gameplay problem.

## 19. State makes rules explicit

Ready, playing, paused, won and lost are separate states. Only playing advances physics. Restart reconstructs the level and resets counters. Pause preserves the current run. Keeping these transitions explicit prevents scoring after a loss or accidentally running two animation loops at once.

**Experiment:** Start, pause, step, resume and restart. Identify what should be preserved by each action. Watch the stars reset on restart but not on pause.

**Check:** Which action should reset collected stars?

**Answer:** Restart — Restart creates a fresh run; pausing preserves it.

## 20. Collect once

When a star is collected, its tile becomes empty and the count increases. Re-entering that position does not grant another star because the original condition no longer exists. This is a small example of making state authoritative rather than repeatedly rewarding a collision that remains true.

**Experiment:** Use the collection coding challenge. In the game, walk across the same star position twice. Inspect the code that changes the tile to a floor symbol.

**Check:** How do you prevent repeat collection?

**Answer:** Remove the collectible from active state — The active data must record that the collectible is gone.

## 21. Feedback without overload

The game combines shape, color and text: stars, spikes, a flag and an E portal. A status message explains collection, checkpoint activation and failure. There is no audio dependency or camera shake. Useful feedback tells the player what changed and what they can do next; extra effects are not automatically clarity.

**Experiment:** Ask a tester why the portal is locked. If they cannot answer, improve the instruction or collectible route before adding more decoration.

**Check:** Which message is most useful after a hit?

**Answer:** Returned to checkpoint; stars are kept — It explains the consequence and the current rules.

## 22. Input and focus

Keyboard controls operate when the canvas is focused. Direction buttons support touch and held Enter or Space; jump needs a fresh press. Losing window focus pauses the game, and switching studio panels pauses it too. Focus boundaries stop an arrow key meant for the page from unexpectedly moving the character.

**Experiment:** Navigate to the game with the keyboard, start a run and use the controls. Switch to another panel, return and resume. Test on a touch device if you have one.

**Check:** Why pause when the window loses focus?

**Answer:** To avoid the game progressing while the player cannot respond — The player should not lose progress because input attention moved away.

## 23. Accessibility is a design practice

Provide readable text, visible focus, alternatives to color-only signals and adjustable difficulty. The studio includes text lessons, a handbook, keyboard editing and touch controls. The spatial action game still depends on seeing the scene; it is not fully accessible to every player. Test with people and assistive technology rather than assuming a checklist is enough.

**Experiment:** Set a generous life count and lower speed. Navigate the level editor by Tab and activate a tile with Enter. Read its row, column and object label.

**Check:** What is a useful access improvement?

**Answer:** Adjustable challenge plus clear control instructions — Multiple ways to perceive and operate a system help more learners.

## 24. Read and change the source

The export is a single HTML file with level data, configuration, markup and the complete engine. Save a copy, open it in a text editor and search for the gravity update or collection rule. Change one thing, save and reload in a browser. Keep a working version so experiments are reversible.

**Experiment:** Export your game. Find createSkybound in its source and locate player.vy. Change the exported title, reopen the file and check that gameplay still starts.

**Check:** What should you do before a risky edit?

**Answer:** Save a known working copy — A recoverable baseline makes experiments cheaper.

## 25. Ask a testable question

A useful playtest asks something observable: can a new player identify the portal requirement, or how often do they miss the first landing? A question such as is this amazing is too broad to guide a change. Choose one target and avoid explaining every rule while the player is trying to discover it.

**Experiment:** Write a hypothesis in the notebook before your next run. Record what the tester actually does separately from your interpretation.

**Check:** Which is testable?

**Answer:** Does the first star lead players to the next platform? — A specific behavior can be observed and compared.

## 26. Read metrics with context

The run report records stars, jumps, deaths and simulated time, plus the last completed run’s path and death locations. A long time can indicate exploration, confusion or a deliberate pause in play. Counts describe behavior but do not tell you why it happened. Keep observations alongside them.

**Experiment:** Compare two runs under the same settings. Ask what changed besides the design: prior practice, device, fatigue or help from someone else?

**Check:** A slower completion proves…

**Answer:** Nothing by itself; context is needed — One metric has several possible explanations.

## 27. Change one thing

If speed, gravity and level geometry change together, the next result cannot identify which change mattered. A focused iteration keeps most variables fixed. The studio snapshots the map and settings with each completed run, so your report preserves context even after you continue editing.

**Experiment:** Test one level with two gravity values while keeping jump strength fixed. Write a prediction before each run. Compare the observed change with the physics estimate.

**Check:** Why change one variable?

**Answer:** To make the effect easier to interpret — Focused comparisons make causal guesses more useful, though small samples remain uncertain.

## 28. Debug a symptom systematically

Reproduce the issue, describe the expected behavior, inspect state, change a small cause and retest. Debug mode shows the collision box, vertical velocity, grounded state and recent path. Pause plus single-step helps inspect a landing. These observations are more useful than guessing from a single fast animation.

**Experiment:** Pause during a fall and step until landing. Watch when grounded becomes true and vertical velocity reaches zero. Explain the transition in your own words.

**Check:** What is a strong first debugging step?

**Answer:** Reproduce the issue consistently — A repeatable example helps distinguish a fix from chance.

## 29. Package a playable build

The exported HTML works locally with no asset downloads or account. Hosting it makes sharing easier, but the studio does not upload it for you. Test the actual exported file: controls, restart, a win, a loss and a small screen. A working editor preview does not guarantee every packaging step was correct.

**Experiment:** Download your game and open that file in a fresh tab. Complete a short level. Send the file only after you have verified the version you intend to share.

**Check:** Which build should you test before sharing?

**Answer:** The exact exported file — Packaging can introduce problems, so test the delivered artifact.

## 30. Finish with a small release checklist

Check the goal, controls, obvious stuck positions, a valid start, readable hazards and a complete win path. Ask a new player to try the instructions. Record known limitations honestly. A small finished game is a foundation for a sequel: new mechanics should answer a design need rather than extend a feature list.

**Experiment:** Use the release checklist, export a backup and save your final game. Write the one mechanic you would explore in a second project and why.

**Check:** What makes a useful next feature?

**Answer:** It supports a clear player experience — Features should serve the experience you are trying to create.

Further reading: https://developer.mozilla.org/en-US/docs/Games/Anatomy and https://developer.mozilla.org/en-US/docs/Games/Techniques/2D_collision_detection