How we make games faster

Main ideas / lessons (how to make games faster)

• Choose the right target scope early (smaller deliberate games ship faster).

  • Making something massive (e.g., an open-world MMORPG) is inherently slow.
  • Speed comes from deciding what kind of game you will make up front and keeping that scope stable.

• Know the game you want to make—don’t design from a vague direction.

  • The creators planned their games from the start with concrete constraints (e.g., number of environments/endings).
  • This reduces “unknown unknowns,” improves timeline estimation, and limits wasted effort.
  • They also avoid redesigning by “crunching down” later; they start with the scope they intend to ship.

• Use UI as a scope document (UI-first / visual-first development).

  • In the first 1–2 weeks, they push to implement most of the UI so the game has a complete interface early.
  • The UI is treated like a checklist of what must exist:
    • Make all UI windows and elements first
    • Use placeholders where functionality isn’t ready yet
    • Gradually replace placeholders with working logic later
  • Benefit: the game visually looks “real” early, enabling early validation (screenshots, Reddit posts, wishlists, trailers).

• UI/visuals early to validate “appeal,” not just mechanics.

  • They criticize a “gray cubes / mechanics-first” approach (prototyping with minimal visuals).
  • Their claim: mechanics tests fun, but visuals/appeal drive whether people care and whether the game can be marketable/viral.
  • They emphasize that you can’t easily generate compelling GIFs/shorts from gray-box mechanics the same way you can with finished-ish visuals.
  • Therefore: compress mechanics testing and visual/appeal validation into the same development period.

• Compress timelines by overlapping tasks.

  • You can’t spend months only on gray-box fun and then months separately on visuals if you have a short timeline.
  • If timelines are longer (years), you can separate steps—but for faster shipping, you overlap/condense.

• Work directly in Unity to reduce tool overhead.

  • They do not require whiteboard/Figma/paper UI mockups.
  • They build UI directly in Unity using prefabs and reusable components.
  • Reason: once you can iterate quickly in Unity, additional tools don’t provide enough speed advantage, and later porting can be slower.

• Use constraints via a shared core asset/theme to prevent scope creep and speed up production.

  • Many games are built around one primary visual asset/pack/theme, with limited supplemental pieces.
  • This improves:
    • production speed (fewer art directions)
    • visual cohesion
    • scope control (lack of art variety limits feature expansion)
  • Example pattern:
    • One main environment/visual style
    • Small supporting assets only when needed

• Prioritize polish and playability over infinite feature expansion.

  • Their “hot take”:
    • Make the game feel polished and playable
    • Mechanics can be “good enough” as long as the game runs well
  • They strongly emphasize bug-free stability:
    • crashes/serious bugs matter more than having great mechanics
  • Only after baseline quality is reached should you add more mechanics.

• Realistic expectations about time and experience.

  • They stress they do this full-time and have multiple game development years/experience.
  • Part-time developers (e.g., 2–3 hours/week) should expect longer timelines even with good process.

• They also offer feedback/consulting to salvage or improve projects.

  • They mention a service (see “Sources/Speakers” below) where they playtest and advise on:
    • salvage vs. stop
    • marketing
    • limiting scope
    • improving appeal and game feel

---

Methodology / process (detailed bullet instructions)

1) Lock scope early

• Decide what your game is (genre + key constraints like number of levels/endings/features).
• Keep the scope small enough to actually ship on your timeline.
• Plan the game around the scope immediately (don’t rely on later “crunch” changes).

2) Estimate the timeline with fewer unknowns

• Because the game is defined early, estimate:
  • how long key features take
  • what remains to implement
  • how many content items (items, systems, variants) you truly need
• Recognize that improving estimation comes with experience.

3) Implement UI first (UI as the scope checklist)

• In the first 1–2 weeks:
  • build most (or all) UI screens/windows
  • ensure the overall UI structure is complete
• Use placeholders where logic isn’t ready yet:
  • buttons can exist but not function fully
  • static UI assets/images can represent features temporarily
• After the UI “skeleton” exists:
  • iterate window-by-window, replacing placeholders with working systems
• Goal: the game “looks complete” early even if gameplay logic is still under construction.

4) Use visuals/appeal early for validation

• Make UI and visuals look good enough early to:
  • share screenshots
  • post short-form content (e.g., Reddit/GIFs/trailers)
  • gather early response/wishlist momentum
• Validate that people care, not just that the mechanics work.

5) Overlap tasks to fit short timelines

• Don’t sequence tasks like:
  • “1 month gray box fun” → “month 2 visuals”
• Instead, compress by overlapping:
  • start mechanics prototyping while also progressing visuals/UI early

6) Reduce tooling friction: build in Unity directly

• Avoid extra mockup workflows if Unity can handle it directly fast.
• Use Unity prefabs and reuse components so iteration is cheap.
• Iterate toward final UI without later “porting” from another tool.

7) Constrain production with shared core assets

• Base the game around one main visual asset pack/environment/style.
• Allow only limited supplemental assets.
• Use these constraints to:
  • prevent scope creep
  • maintain visual cohesion
  • force creative adaptation within limits

8) Prioritize polish: feel + stability before content

• Ensure:
  • no serious bugs
  • no frequent crashes
  • the game controls/feels good in its core loop
• Only after stability and feel are solid:
  • add additional mechanics/features

9) Calibrate to your available time

• If you’re part-time, adjust expectations and scope more aggressively.
• Full-time + experience makes the process faster; beginners/part-time need more buffer.

---

Speakers / sources featured

• Speaker: The main narrator/presenter (no name given in the provided subtitles).
• Games/assets referenced as examples (no separate sources/speakers):
  • M O 98 (referred to as “MO98” / “M198”)
  • Kyoto Anomaly
  • Unicycle Pizza Time
  • Silicon Architect
  • Forge Industry
  • Overtime Anomaly
  • KiraOnna (also spelled “KiraOnna only” in the subtitles)
  • Mannequins Strike Back
  • AM2R (referenced in relation to visuals appealing to players)