Some Things That I've Learned About Game Development While Making ULTRAKILL So Far (Talk/Slideshow)

Main ideas / lessons conveyed

1) Purpose and credibility of the speaker

• The speaker repurposes an older slideshow to share “helpful advice” for aspiring game developers.
• They emphasize this is not authoritative—it’s one person’s experience.
• The speaker is the lead developer of ULTRAKILL, which started as a solo project (with friends) and grew into a small full-time team.
• They cite ULTRAKILL’s strong reception as indirect confidence in the perspective: roughly ~99% then ~97% positive reviews over time.

2) ULTRAKILL development + visibility strategy (high-level timeline)

• Development start: approximately Feb 1, 2018 (earlier work existed but dates were unclear).
• Marketing/visibility begins immediately:
  • They started posting YouTube videos about the project from the day they began.
  • Rationale: indie devs face an “uphill battle,” so early attention helps the eventual release.
• Growth phases:
  • Early: mostly solo dev, with occasional friend help for 3D models/art.
  • By June 2019: pushing into communities (Discord/forums) as visuals looked more promising.
  • They describe gaining interest from experienced artists once the project seemed feasible.
• Public demo:
  • Released a public demo (Aug 2019) on itch.io, gaining traction via word of mouth.
  • Emphasis: playing the game sells it better than screenshots/videos.
• Publishing path:
  • Repeatedly emailed New Blood Interactive.
  • Picked up around May 2020; early access followed in Sep 2020.
• Ongoing development:
  • Frequent updates; the game grew far beyond original expectations.
• Motivation behind the talk:
  • Now that the original constraint (“speed through slides”) is gone, they expand into the full list of advice.

---

Detailed methodology / instruction-style advice

A) Start correctly (choices early in development)

• Pick an engine and start experimenting
  • Don’t overthink “Unreal vs Unity vs GameMaker vs Godot”—all can do most things.
  • The key is to choose one and begin building, or risk “planning forever.”
• Make lots of small games before your main passion project
  • Why:
    • Teaches the development process (many lessons are invisible until you do it).
    • Reduces risk of burnout.
    • Avoids needing to restart your big project multiple times due to learning better practices.
  • Use strict, escalating deadlines to prevent scope creep:
    • First game ~2 weeks
    • Next ~1 week
    • Next ~1 month
  • Example small projects:
    • Red Red Knight (platformer): completed from 0 to completion in ~2 weeks due to deadline constraints.
    • This Game Only Has One Level (Unity learning project): ~5 days; controls/design felt tighter due to prior learning.
• Avoid complete solo development if possible
  • Solo devs can still get control as a lead/director, but exhaustion is a major risk.
  • Bringing in other artists can increase creativity and richness.
  • Early teams may rely on:
    • friends/community work
    • contracts involving royalty splits or future pay once revenue exists
  • Critical requirement: you must prove you can make the game; promises alone don’t recruit reliable help.

B) Team-building and leadership practices

• Build connections with other developers (especially peers)
  • Indie devs aren’t truly competing; you’re “in the same ship.”
  • Peer support helps everyone make games real.
• Be “nice/pleasant to work with”
  • Team cohesion matters more than pure talent if it destroys collaboration.
• Lead devs should understand multiple fields
  • Even if you can’t do certain tasks well (e.g., 3D modeling), understand enough to direct vision and assess feasibility.
• Avoid “romanticized solo creator” logic
  • Bragging rights aren’t the main objective; game quality is.

C) Creative direction: avoid common content failures

• Don’t just remake a better version of a game
  • If it isn’t meaningfully differentiated (unique hook/twist), players will choose the already-successful original.
• Design marketing clarity into visuals
  • Plan so viewers can understand what the game is from a random screenshot/clip:
    • first-person vs third-person
    • weapons/gameplay genre signals
    • visual style cues
  • For ULTRAKILL, they emphasize:
    • including the “style meter” in screenshots
    • making UI immediately communicate gameplay interest (“What is this? I want to play it.”)
• Think ahead for genre trends
  • When developing long projects (1–2+ years):
    • you aren’t building for the market today, but for the market later.
  • Example concept: if a genre trend blooms (e.g., after DUSK), you need novelty/gimmicks by release time.

D) Make the game fun by design

• Treat “fun” as something you must design
  • Ideas/mechanics alone don’t guarantee fun.
• Focus on the primary gameplay loop first
  • The loop is ~90% of what players do.
  • ULTRAKILL example loop:
    • enter room → enemies spawn → shoot while avoiding death → move to next arena.
• Avoid “gimmick-first” thinking where most of the game becomes filler
  • If story is the “main pull,” gameplay must be minimal or exceptionally engaging.
• Implement sound immediately, not later
  • When adding a new mechanic/weapon/ability: add its sound at the same time.
  • Rationale:
    • sound strongly affects perceived feel
    • it becomes an information channel (enemy cues, timing, feedback)

E) Asset sourcing + licensing guidance (practical)

• Start with major sound packs (e.g., Sony GDC audio packs).
• Use additional sources like FreeSound, but check licenses carefully:
  • Creative Commons Zero / public domain
    • Free for any use, including commercial, no credit required.
  • Creative Commons 3.0
    • Free but requires credit.
• Recommendation: prefer public domain/CC0 to avoid the logistical pain of tracking and crediting every effect.

F) Scheduling and technical production realities

• Expect milestones to take longer than planned
  • Rule of thumb: anything will take twice as long (or more) as you think.
• Use “good enough” implementation discipline
  • Only “good” can be used; “perfect” features that never ship are worse.
  • Aim for finishing:
    • completed ~7/10 > unrealized 10/10
• Back up work and use version control
  • Use Git if possible (benefits merging changes).
  • If not: zip the project and store weekly versions (e.g., on Google Drive).
• Be cautious with multiplayer
  • Multiplayer multiplies failure points and complexity.
  • Recommendation: prefer single-player, or local multiplayer only, unless you already know multiplayer deeply.

G) Game feel and design rules of thumb

• Close enough is enough (feel over exactness)
  • Players don’t think like machines.
  • If they’re “almost right,” they blame the game and feel cheated.
  • Example: generous hitboxes vs visible meshes to avoid “accuracy-only” gameplay that forces stopping to aim.
• Give each level/area one memorable “signature moment”
  • Players should remember levels by distinct traits (e.g., “big light beams, two floors, boss with big sword”).
  • Benefits:
    • higher “moment density” to compensate for shorter overall length
    • replay becomes more engaging due to better recall
• Exaggerate audio in action games
  • Capture the “feel” more than real-world authenticity.
• Consider clipping carefully (especially if sound is exaggerated)
  • Some caution against clipping, but exaggeration may justify it.
  • Still avoid: over-maxing everything to the point of ear-unpleasantness.
  • Manage ear exhaustion; make loud-impact sounds only as needed.

H) Player guidance vs expression

• Guide the player toward fun while allowing expression
  • Without guidance, many players choose the most efficient option—which can be boring.
  • Example: ULTRAKILL’s systems encourage using more of the arsenal via “style” mechanics without hard-forcing one weapon.
• Provide multiple solutions to problems
  • If only one solution exists, players repeat motions and disengage.
  • Example: use different tools against the same enemy (distance vs melee head attack).

I) Presentation design: reward the player appropriately (situational)

• Give opportunities instead of taking them away (more situational)
  • Example concept: rather than “you can’t damage the enemy until the shield breaks,” make the “shielded state” feel normal and the shield drop feel like a power-up window.
  • Core idea: player psychology turns a required step into a bonus opportunity.

J) Responsiveness and pacing

• Respond to player input instantly (action games)
  • Strong feedback to button presses improves perceived control.
  • Example comparison:
    • Crash Bandicoot: crouch state registers immediately in the original; in the remake, animation delays cause misinputs and reduce responsiveness.
  • ULTRAKILL example: punch impact happens as soon as possible (before full animation “arrives”) to preserve responsiveness.
• Use calm moments to keep intense moments intense
  • If everything is always intense, intensity normalizes.
  • Alternate calm and peak moments like a pacing system.

---

Story, composition, and writing advice (condensed but clear)

Story writing

• Plan beginning + ending early
  • Beginning = hook
  • Ending = what people remember most
  • Strong beginning/ending can make a weak middle more forgivable.
• Prefer not to answer questions too early (unless the best answer is the only one)
  • Keeping ambiguity allows later ideas to add deeper meaning and weight.

Writing clarity

• Provide enough information to spark imagination, not remove it
  • Answers should imply more than they state.
• Cut unnecessary text/filler
  • Amateur tendency: keep drafts even when much doesn’t matter.
  • They apply this to dialogue and scripting revisions.

Emotional engagement principle

• Most people won’t care about story until emotionally attached
  • If you frontload too much exposition, players disengage before caring.
  • Example: Dune starts with an intense personal moment rather than immediate grand explanation.

Music / composition

• Avoid excessive repetition in game music
  • Since tracks loop in-game, overly repetitive motifs can become overbearing.
• When collaborating, ask for examples
  • “Intense/heavy here” can mean different things—use multiple references to find shared characteristics.
• Get weird / take risks
  • Context (e.g., in games/media like Silent Hill) helps audiences accept unusual music.
• Great music can carry emotional weight
  • Even if players aren’t deeply into story characters, music can enhance engagement.
  • Example mention: Undertale as a case where music helped draw attention.

---

Iteration and feedback workflow

• Play-test your own work repeatedly and early
  • Their process:
    • load the current level
    • play through after each change
    • re-upload/replay after breaks
  • Goal: find micro-issues (movement feel, collision quirks, jank vs polish).
  • Example: noticed how players approached a door landing; fixed a protrusion that caused bouncing/falling.
• Learn to take feedback properly
  • Don’t reflexively reject suggestions (“it’s my vision”).
  • Don’t accept everything either—filter ideas through your vision and game understanding.
• Learn what makes games good/bad
  • Don’t just copy surface features; identify what makes them work.
  • Also learn from bad games: derive what could have been better and improve your own approach.
• Use rules on a case-by-case basis
  • Rigid “good/bad design” frameworks can fail depending on desired player experience.
  • Example: Dark Souls “punishing/unforgiving” traits can be “bad” in general but “good” for its intended experience.

Balancing and testing process

• When changing strength/balance, avoid overshooting
  • Multiple nerfs/buffs can cause oscillation until things are worse.
• Test with silent observers (no creator presence)
  • Have testers record themselves without the creator present or talking.
  • Reason: presence changes player behavior via social pressure/creator guidance.
• Lead devs must know what their vision DOESN’T require
  • Not everything you imagine is necessary; some features can harm the actual vision.

---

Marketing + business guidance (actionable)

• Start marketing as early as possible and as often as possible
  • Example: upload from day one to build an audience.
• Accept marketing trust is often opposed to “art”
  • But both are needed to get people to play your game.
• Choose a “reach-back” platform
  • Example choice: YouTube.
• Use additional channels
  • Twitter/X for discoverability
  • Discord for community interaction and updates
• Post where players are, not only where devs are
  • Prefer communities for players; dev communities may help but might not convert interest.
• Learn from similar indie games (not mega-hits)
  • For social posts: observe common hashtags/patterns from successful similar-scoped indies.
• If using a publisher, verify quality
  • A good publisher can help a lot; a bad one can destroy momentum/revenue.
  • Investigate by asking other developers about their experiences.

Demos + Steam + community health

• A good demo can significantly boost word of mouth
  • Especially for indies: gameplay experience sells more than visuals alone.
  • Demos also produce valuable feedback.
• Set up the Steam page early once screenshots look game-ready
  • Goal: accumulate wishlists so players get notified on release even years later.
• Maintain a single primary community hub
  • Today that’s usually Discord; early days used forums.
• Keep the early community welcoming
  • Healthy early cohesion helps growth.
  • Larger communities later become fragmented, but early unity matters.
• Don’t publicly bad-mouth other games/devs
  • It burns bridges through friend-of-friend reputation chains.
  • Rant privately if needed.

Finishing up: production sustainability and release concerns

• The last part is hardest
  • They reference a remark (credited to Dave Ashray) that the last 10% is hardest.
• After “done,” do a consistency pass
  • Revisit/patch holes and improve cohesion (example cited: an ULTRAKILL revamp update).
• Early access can help small teams
  • Provides income for sustainability and feedback while still developing.
• Handle taxes correctly for commercial releases
  • Don’t ignore it; seek accounting help if needed.

---

Speakers / sources featured (explicitly named)

• Speaker: Lead developer of ULTRAKILL (name not provided in subtitles).
• New Blood Interactive (publisher).
• Sam (3D modeler; joined around early “Limbo” period—timing approximate).
• Dave Ashray (“last 10% is hardest” remark).
• Disc — Disco Elysium (referenced as an example of story-heavy games; subtitles likely refer to “Discolesium”).
• Dusk (retro FPS example that inspired others).
• Dark Souls (example used for “rules are case-by-case” and contextual “punishing design”).
• Devil May Cry 5 (responsive state transitions despite realism/animations).
• Crash Bandicoot 2 and its Nsane trilogy remake (input responsiveness vs animation state).
• Undertale (example where music helped draw attention).
• Silent Hill (example context where weird music works).
• Git (version control system).
• Sony GDC game audio packs (audio resource).
• FreeSound (audio resource).
• itch.io (demo platform).
• Steam (Steam page + wishlists).
• Ariplier (example of a very large streamer they suggest not relying on; prefer FPS-focused streamers).
• Twitter/X and Discord (marketing/community platforms).
• YouTube (chosen as primary long-term channel/distribution).
• Dune (original novel referenced for story engagement strategy).
• Graphic interfaces for Git (mentioned generally; no specific vendor named).