Appendix J: Frequently Asked Questions

This appendix is the email I get every week, collected and answered in one place. Most of these questions have longer answers in specific chapters — I'll point you there. But I also want you to have a version you can flip to when you're stuck at midnight and don't have time to re-read a whole chapter.

Practitioner voice, same as the rest of the book. Honest, opinionated. You came here for someone's actual take, not for hedged neutrality.

Getting Started

I have no experience — should I really start with Godot?

Yes. And I say this as someone who has shipped games in Unity, Unreal, GameMaker, and a couple of engines you've never heard of.

Godot is free, open source, cross-platform, has a small enough codebase that you can read the documentation in a weekend, and — critically — forces you to understand what your game is actually doing. You're not hidden behind acres of engine abstraction. GDScript is the easiest-to-read scripting language I have used in any engine. The editor is fast and doesn't crash.

There is one caveat: if your long-term goal is 3D AAA work, you will eventually need to learn Unreal. But that's a two-year-out problem. For learning design and shipping your first game, Godot is the right tool. Chapter 3 walks through setup.

I know Unity already — should I switch to Godot?

Not for the book's sake, no. The design principles are engine-agnostic. If you already have working Unity muscle memory, translating the GDScript examples to C# is straightforward and arguably useful — the translation forces you to understand what the code is doing rather than copy-paste it.

But watch out for one trap: Unity does several things differently from most engines (the component-only object model, MonoBehaviour lifecycle, prefabs). Godot's scene-tree model is closer to how most engines work. If you plan to eventually work on a team using a different engine, Godot exposure is a good thing.

Also: Unity's 2023 licensing drama broke a lot of indie trust. I would not build a small studio on Unity without a long, hard look at the legal terms.

Do I need to learn C++ to make games?

For learning design? No.

For shipping indie games in Godot, Unity, or GameMaker? No.

For getting hired at a AAA studio in a programmer role? Probably eventually, yes — most AAA engines (Unreal, proprietary) have significant C++ surface area and engine programming positions require it.

For getting hired as a designer at a AAA studio? No. Designers at most AAA studios use Blueprint / visual scripting or scripting languages. C++ is an engine programmer's problem, not a designer's.

Start with GDScript or C#. If you fall in love with systems programming and want to push further, pick up C++ later. Don't use "I should learn C++ first" as procrastination from shipping a game. Chapter 34 has more on studio roles.

Is GDScript "real" programming?

Yes. This is a dumb question asked mostly by people who want to feel superior. GDScript is a dynamically-typed scripting language comparable to Python. The algorithms you write in it are the same algorithms you'd write in C++. Data structures are the same. Control flow is the same. If you can read and write GDScript, you can read and write most scripting languages.

What isn't GDScript: it's not systems-level programming. You won't write a renderer in GDScript. You won't manage memory manually. That's fine. You're designing games, not writing engine internals. If you eventually need to, GDScript is close enough to Python that any language transition is about syntax, not concepts.

Designer tip: even if you become an "all-visual-scripting" person, you will communicate with engineers better if you can read code. Learning GDScript pays that dividend forever.

How much math do I actually need?

Less than you think. More than you currently know.

For 2D indie game design: basic algebra, some simple trig (vectors, angles), and probability (covered in Chapter 10 and Appendix E). That's it.

For 3D: add vector math (dot product, cross product) and some matrix concepts, but 95% of the time the engine abstracts these away.

For balance and economy work: probability, expected value, and some statistics. Also in Appendix E.

You do not need calculus. You do not need linear algebra beyond vectors. You do not need to prove theorems. You need to use formulas. Appendix E is written for exactly this audience.

Choosing a Project

What genre should my first game be?

Small. The genre that will fit in your time and skill budget.

That almost always means: a short 2D game, probably a puzzle, arcade score-attack, simple platformer, or focused narrative piece. Not an RPG. Not a roguelike. Not a "Metroidvania but with my twist." Not a survival game. Not an MMO. Not a colony sim. Not a grand strategy.

I'm not being cute. Those genres are graveyards for first-time developers because they combine high content demand (RPGs need hours of content), complex systems (roguelikes need deep generation), or ongoing service (MMOs, colony sims). You will underestimate the scope by a factor of five. You will burn out. You will not ship.

Make something you can finish in three to six months of spare-time work. Something with one core mechanic done well. Thomas Was Alone is more shippable than Skyrim. See Chapter 37 (Scope Management) for the painful details.

Should I make a puzzle, platformer, RPG, or something else?

Puzzle > platformer > arcade > narrative > RPG, roughly, in ascending order of difficulty.

A puzzle game can be one mechanic, twenty levels, a menu, and some sound. Shippable. Baba Is You started as a game-jam entry.

A platformer is physics, levels, enemies, checkpoints, maybe a story. Harder — Celeste is a platformer and it took a team several years.

An arcade / score-attack game is a small content envelope with replay value driven by skill. Shippable, and marketable in a specific niche.

A narrative game (short one) can be walking-sim-plus-text, but writing is the bottleneck and good writing is hard.

An RPG is the everything-bagel of genres. Combat + progression + economy + dialogue + levels + quests + UI. First-time RPGs almost universally fail.

Pick the smallest genre that excites you. You can make bigger things later, once you've shipped something.

Is it okay to clone a game I love?

For a learning project? Completely. Clone Pong. Clone Breakout. Clone Tetris. Clone Asteroids. Clone Flappy Bird. You will learn enormously. This is how practically every designer I know started.

For a released game? Careful. A straight clone with different art is usually legal (game mechanics are rarely protected, though specific implementations and names are). But it's not a good business move — your clone has no audience, no hook, no "why would I play this instead of the original?" The market punishes near-copies.

The sweet spot: take a game you love, identify the one mechanic that fascinates you, and build a short game around just that one thing. Not a clone — a focused study. Downwell is essentially "what if Contra was vertical and had bounce-shoot?" That's a focused study, not a clone.

How do I know if my idea is any good?

You don't. Nobody does. This is the hardest truth in design.

Ideas are worth approximately nothing. Every designer you know has a notebook full of game ideas that seemed amazing in the shower. The idea is not the game. The game is the implementation of the idea, with twenty thousand tiny decisions layered on top. The idea determines maybe 10% of whether the final game is good.

So the answer is: build a prototype. Within a week, you should have a rough playable version of your core loop. Let three or four people play it (Chapter 31, Playtesting). If they're bored in ninety seconds, the idea needs reworking — or more likely, the implementation needs reworking. If they keep playing past when you expected them to stop, you might have something.

Don't spend months polishing an idea you haven't tested. Prototype fast, test fast, iterate.

Should I make a 2D or 3D game first?

2D. Always, unless you have specific experience that lets you skip this advice.

3D adds: 3D modeling, rigging, animation, lighting, a much harder camera problem, more complex collision, much harder level design, much larger file sizes, more performance concerns, more sophisticated art pipeline, harder-to-find collaborators. For the same scope of game, 3D takes 3–5x longer than 2D.

2D is strictly easier on almost every axis. Good 2D games look worse than bad 3D games to many players, but that's a marketing problem, not a design problem. Ship a good 2D game. Chapters 17 and 18 cover both, but Chapter 18 exists mostly so you understand 3D principles when you encounter them later.

Scope and Time

How long will my first game take?

Longer than you think. Much longer.

Rough benchmark for a first game shipped solo in spare time: 12–24 months for a focused small game. (2–3 hours of gameplay, one core mechanic, small team or solo.)

That's if you're disciplined, scope appropriately, and don't burn out. Most people take longer than that, or never ship.

If you can work on it full-time, you can compress this to 6–12 months. But even then, first-project overhead (learning the engine, learning pipelines, setting up infrastructure) eats months.

Chapter 37 (Scope Management) spends a lot of time on this. The short version: cut your scope, then cut it again, then cut it a third time, and you might finish.

How many hours a week do I need to put in?

Consistency matters more than volume.

10–15 hours a week, sustained over many months is much more effective than 30-hour bursts followed by weeks of nothing. Game development rewards compounding progress: each session builds on the last one. Long gaps mean you re-learn your own code every time you come back.

Ten hours a week is roughly: two weekday evenings at 2 hours each, plus a 6-hour chunk on a weekend day. That's doable alongside a full-time job. Most shipped solo indie games I know were built this way.

If you can manage 20+ hours a week for an extended period, your timelines shrink significantly. But burnout is the silent killer. Sustainable medium pace beats unsustainable high pace.

Is it possible to make games part-time while working a full-time job?

Yes. Many shipped indie games — including some very famous ones — were built this way. Stardew Valley was famously built largely solo and part-time before the developer went full-time toward the end.

The real questions are:

Can you protect the time? Your evenings and weekends must have defended game-dev time or the project dies.
Can your partner / family support this? If not, be honest with them before you start.
Can you tolerate slow progress? Part-time means the game takes two to three years, not one.

It's harder than going full-time, but it has huge advantages — you are not financially desperate, you can make the game you want to make rather than the one that pays the bills, and you can walk away if the project isn't working.

What if I don't finish?

You almost certainly won't finish your first project. Most people don't.

That is not a tragedy. Your first "unfinished" project taught you the engine, exposed you to actual development problems, and gave you a realistic sense of scope. Those lessons transfer.

The failure mode to avoid is starting twenty projects and finishing none of them. If you can't get past prototype on any project, you have a scope problem, a commitment problem, or a "chasing shiny ideas" problem. Fix the underlying issue before starting project twenty-one.

The designers I know who shipped games were not the ones with the best ideas. They were the ones who picked one idea and refused to abandon it until it was finished or genuinely dead.

Solo vs. Team

Should I work alone or find collaborators?

For your first game? Solo, if you can stand it, or with at most one tightly-collaborating partner.

Teams multiply communication overhead. Three friends making a game requires constant coordination, shared tools, merged workflows, agreed-upon design decisions. If you've never shipped anything, you don't yet know what you want to agree on. Team failures are the #1 cause of first-indie-game death.

That said: if you genuinely cannot make art, you need an artist. If you genuinely cannot write, you need a writer. Match skills to gaps. But keep the team small — two to three people — and make sure everyone is equally committed and equally invested.

How do I find collaborators?

In descending order of success rate:

People you've already worked with. If you had a productive classmate, a coworker who also makes games, a jam partner — they're your first-pick collaborators.
Game jams. The single best collaborator filter. A weekend jam reveals who ships, who communicates, who pulls weight. Do three jams with different people before committing to a long project.
Online communities. The Godot Discord, r/gamedev, Twitter game-dev circles, itch.io jams. Slower filter but large pool. Expect high ghost rates.
Gig marketplaces (Fiverr, etc.). Works for contract work (commission a portrait, buy a music track), rarely works for committed collaborators.

Red flag: someone who has "a great idea" and wants you to build it "for revenue share." Ideas are free. If they can't contribute actual production work, they are not a collaborator — they are a client trying not to pay.

How do I split revenue with collaborators?

Agree in writing before you start. Not "we'll figure it out later." Before you start.

Simplest structure: equal shares for equal effort. Two-person team, each contributing 50% of the work, 50/50 split.

More realistic: proportional to effort and ownership. Lead designer / programmer might take 40–50%. Artist 25–35%. Composer 10–15%. Writer 10–15%. Adjust for who brought the idea, who bears financial risk, who handles business side.

Pre-release salary vs. royalty: If one person does the thing early and another joins late, the early person took the risk. A common pattern is for contract collaborators (composer, portrait artist) to take a flat fee plus small royalty, while long-term partners share in revenue.

Write the agreement. Sign it. Escrow a copy with someone trusted, or use a simple legal template. The cost of a clear agreement is zero. The cost of ambiguity is a lawsuit.

My collaborator stopped responding — what now?

Painful but common. Here is the order of operations.

Reach out directly once, with a warm tone. Life happens. Their dog died. They got a new job. Give them a lifeline.
If no response within a week or two, reach out again, more directly. "Hey, I haven't heard from you. What's the status? Should we talk about the project?"
If still no response, accept they're gone. People who ghost their collaborators are not coming back. Stop waiting.
Check your collaboration agreement. If there's a clause about unfinished contribution (there should be), use it. Usually: work they completed belongs to the project; work they didn't complete is abandoned.
Decide whether the project can continue without them. Sometimes yes (you can replace the role). Sometimes no (they were the artist, you are not). Be honest with yourself.
Never say anything publicly bad about them. The industry is small. Their ghosting is their problem. Your reputation is what you're protecting.

Art, Audio, and Assets

I can't draw / make music — what do I do?

Three options, in order of cost and control:

Use asset packs. Free and paid. OpenGameArt, itch.io asset packs, Kenney's assets (free, excellent, used in thousands of games). Low cost, low uniqueness, fine for learning and prototyping. Acceptable for finished games if you pick cohesive packs and modify.
Hire a freelancer. Fiverr, ArtStation, Reddit portfolios. Pay fair rates (see below). Good for specific pieces — character portraits, logo, key art. Gives you quality and exclusivity.
Collaborate with an artist. Revenue share or partnership. Higher quality and more custom, but now it's a team, with all the team problems.

A fourth option that gets underestimated: learn enough to do basic art yourself. Pixel art is famously learnable — spend a month with Aseprite and you can make charming, cohesive pixel-art environments. Low-poly 3D is similar. You won't be great, but you'll be passable, and passable-with-consistent-style beats high-quality-but-inconsistent every time.

Is it okay to use asset packs?

Legally: yes, if the license permits commercial use and you credit properly. Read the license for every asset.

Creatively: depends on how you use them. If your game is "unmodified Synty characters on a unmodified POLYGON environment," it looks like every other asset-flip on Steam and will get dragged in reviews. If you use asset packs as raw material, modify them, recolor them, combine them, build a consistent art direction on top of them — players won't know or care.

Asset packs are professional tools. AAA studios use them too (they rarely admit it). The shame is culturally invented and not reflective of reality. Just don't ship pure asset-flip shovelware; players see through it.

Where can I find free / royalty-free assets?

OpenGameArt.org — classic, large library, varied quality.
Kenney.nl — consistently high-quality free asset packs.
itch.io — filter by "Assets" tag; many free and paid options.
Freesound.org — free SFX (check licenses).
Incompetech (Kevin MacLeod) — free music with attribution.
Pixabay / Unsplash — free stock images and some audio.
Google Fonts — free, license-clean fonts.

For each asset: read the license. Some require attribution, some don't allow commercial use, some require sharing modifications. Keep a spreadsheet of every asset you use, its source, and its license. You will need this when you ship.

Should I hire an artist? How much does that cost?

If you can afford it: yes. It dramatically raises the ceiling of your game.

Rough 2026 rates for freelance 2D game art, varies wildly by region and artist experience:

Character portrait / key art: $100–$500 per piece.
Pixel art character sprite with animations: $200–$1,000 per character.
Tileset for a level: $300–$1,500.
Full game art contract (small game): $3,000–$15,000.
UI art package: $500–$2,500.

Audio (music and SFX):

Custom SFX pack: $200–$1,500.
Original music track: $300–$2,000 per track.
Full soundtrack for a small game: $3,000–$15,000.

These are rough ranges. Low end is junior artists or very simple styles. High end is senior artists or complex styles. Do not try to pay below the low end — the work will reflect the price.

Hire on per-piece contracts with defined deliverables, not "the whole game's art." Control scope and cost; pay for what you get.

Career

Can I make a living making indie games?

Honest answer: probably not.

The harsh reality is that most indie games earn under $5,000 total lifetime revenue on Steam. The median indie game loses money — the developer's time invested, opportunity cost, and tool/asset spending exceed revenue.

Indie developers who sustain full-time careers are roughly 2–5% of the indie dev population. They usually have: a commercial hit that bought them runway, a second-wave hit that confirmed it wasn't luck, a stable niche audience, low cost of living, and probably a partner with stable income.

That doesn't mean don't do it. Lots of people make indie games as serious hobbies or side projects that occasionally generate meaningful income. It means: don't quit your job based on hope. Get to shipped revenue first, then consider the math. Chapter 38 covers the realistic economics.

Should I go to game design school?

Depends what you want from it.

Game design school is good for: structured curriculum, access to tools and facilities, peers working on the same thing, internship pipelines, networking in the industry.

Game design school is bad for: anyone expecting that a degree guarantees a studio job (it doesn't), anyone going into significant debt for it (the industry's salaries don't justify $200K of student loans), or anyone using it as a substitute for shipping games.

The most valuable thing you can have when applying to studios is a shipped portfolio, not a degree. You can get a portfolio for $0 with a laptop, free engines, and six free months of your life. If game school helps you get there, great. If it doesn't, it's probably not worth it.

That said: if you're a teenager deciding between colleges, a game-focused degree from a respected program (DigiPen, Carnegie Mellon ETC, NYU Game Center, USC Interactive Media) carries weight and is often worth it if the finances work. For anyone older with a career already, formal degrees rarely pay back. Chapter 34 goes deeper.

What portfolio do I need to get hired at a studio?

Three shipped things, each one progressively more ambitious.

For a designer role, that might be:

A small, playable solo game on itch.io. Anything shipped beats anything polished-but-unfinished.
A jam game or collaborative project, showing you can work with others and scope tight.
A design document for a larger project, showing you can think at a systems level.

For a programmer role: shipped games with complex systems you built, open-source contributions, technical blog posts, a GitHub profile that shows real code.

For an artist role: visual portfolio + game projects using your art.

The key signal every studio cares about: you can finish things. Most applicants have one half-done project they've been working on for three years. A person with three shipped itch.io games, even small ones, stands out. Ship small things aggressively.

Which GDC talks should I watch first?

If I could only recommend five:

"Concerning the Soul of Game Design" — Frank Lantz. Reframes what design is.
"Failing to Fail: The Spiderweb Software Way" — Jeff Vogel. The most realistic talk about sustainable solo indie dev.
"Inside the Tool of the Architect: Puzzle Design in The Witness" — Jonathan Blow. A master class in iterative design.
"Juice it or lose it" — Martin Jonasson & Petri Purho. Fifteen minutes that will change how you think about game feel.
"The Four Letter Word: Why Narrative Matters in Mobile Games" — Anna Anthropy / various speakers on design ethics. To balance the other four with a perspective that pushes back on industry defaults.

After those, dig into any Celeste or Hollow Knight post-mortems. Matthew Davis and Jonathan Cooper have great GDC talks on specific mechanical design. GDC Vault has hundreds of hours of free content — you'll never run out.

I'm a designer — do I need to learn to code?

Strongly recommend yes, for almost all design roles.

Designers who can code can:

Prototype their own ideas without engineering dependency.
Communicate precisely with engineers about what's possible.
Implement simple gameplay systems themselves, freeing engineers for harder problems.
Debug their own balance issues instead of waiting on someone else.

Designers who can't code are dependent on other people to bring their designs to life, which slows iteration dramatically.

You don't need to be a great coder. You need to be a passable one. GDScript or C# is enough. If you can write a working FSM or a loot table in 100 lines, you're coded enough to work effectively at most indie and mid-size studios.

AAA design roles vary — some are almost pure spec-writing and spreadsheets. Most benefit from some scripting ability (Blueprint at minimum in Unreal shops).

What if I'm older — is it too late to start?

No.

I know designers who started in their 40s and shipped hits. Game development doesn't care about your age. The work is the work. The skills are learnable at any age. The industry, though often young-skewing in its demographics, ultimately hires and buys from people whose work is good.

What is harder as you get older:

Less energy for all-night crunch (which is a feature, not a bug — you'll avoid burnout).
Harder to accept entry-level wages if you're used to a professional salary. Plan the finances.
Family and life obligations eat time. See "part-time game dev" above.

Advantages of starting later: you know how to finish projects, you know how to communicate with collaborators, you have savings, you have a realistic sense of what's hard and what isn't. These compensate.

Publishing

Should I launch on Steam or itch.io first?

itch.io for your first project, or for short / experimental work. Steam when you have a serious commercial game.

itch.io is lower commitment, lower cost, more forgiving audience, great for testing and early revenue. Revenue split is generous. Audience expects less polish.

Steam has the biggest audience by a huge margin, but it's also the loudest market — 13,000+ games launch per year. If your game isn't commercial-grade and you don't have a marketing plan, Steam can feel like launching into the void. See Chapter 38 for the marketing details.

Many games benefit from both: launch a short demo or jam version on itch.io, use it to build a small audience, then launch the full game on Steam with a wishlist campaign built from that audience.

How much does it cost to put my game on Steam?

$100 USD per product via Steamworks Direct. One-time fee. You also agree to Valve's 30% revenue cut on sales.

Additional costs if you're doing things right: legal review of Steam's terms (optional but smart), a Steam capsule and trailer produced to Steam's specs (you or a freelancer), possibly paid promotion, and the time cost of configuring your store page, trading cards, achievements, and cloud saves.

itch.io has no upfront fee. You can set the revenue split (they suggest 10% to the platform, you can make it anything from 0% to 100%).

Do I need a publisher?

For your first indie game? Almost certainly no.

Publishers take 30–50% of revenue plus have final say on a lot of decisions. In exchange they offer: marketing, porting, localization, QA, console certification help, sometimes funding. If your game is genuinely commercial-grade and you can't self-fund its final polish, a publisher might be worth it.

For small first games? The overhead isn't worth it. Self-publish on Steam and itch.io, learn the marketing skills yourself, keep the revenue. You'll learn things no publisher will teach you.

When a publisher does help: console launches (Nintendo Switch especially has friction for solo devs), multilingual localization, physical releases, marketing budgets for bigger games.

How much should I charge for my game?

Ballpark 2026 indie pricing:

Small / short (under 4 hours of content): $4.99–$9.99.
Medium indie (4–15 hours): $9.99–$19.99.
Large indie (15+ hours, significant scope): $19.99–$29.99.
Very large indie / AA-aspirational: $29.99–$39.99.

Never free, unless the game is specifically experimental or a demo. Free reduces perceived value and makes monetization harder later.

Rarely under $4.99, unless you're really experimenting or trying to build audience. Under-pricing devalues your work.

Never launch on sale. You can't un-anchor players from the sale price. Launch at full price; discount later with Steam sales.

Your game's genre matters: premium puzzle games often command $14.99 even at 4 hours of content. Narrative games in the $9.99 range feel normal. Roguelikes in the $19.99 range feel normal. Look at comparable games; price in the neighborhood.

What's realistic to earn from a first indie game?

Honestly: most first games earn under $5,000 total on Steam.

A "successful" first indie game — one that gets noticed, gets reviews, gets some press coverage — might earn $10,000–$50,000 over its lifetime. That's before Valve's 30%, before platform fees, before taxes, and over several years of tail sales, not concentrated at launch.

A "hit" first indie game is a $100K–$500K earner. Very rare. Counts as a life-changing result for most solo devs.

A "breakthrough" first indie game that earns $1M+? You're in the top 0.1% of first-time releases. Planning for this is not a strategy; it's a lottery ticket.

Budget conservatively. Don't quit your job on projected hit numbers. Do it after the first game has earned enough that the second one can actually be your job.

Tools and Tech

Is Godot good enough for my real project, or should I "upgrade" to Unreal/Unity?

Godot is good enough for almost every indie-scale project.

Dome Keeper, Brotato, Cassette Beasts, Sonic Colors: Ultimate (the PC port) — all Godot. Real commercial games, shipped and selling well.

What Godot isn't great at:

Cutting-edge AAA 3D graphics. If you want Elden Ring visuals, use Unreal.
Massive open worlds with complex streaming. Hard in Godot currently.
Console ports — supported but less polished than Unity/Unreal pipelines (though 2026's Godot has improved a lot here).

For most 2D indie, most small-mid 3D, most narrative games, most puzzle and arcade games: Godot is fine. The "upgrade" framing is misleading. Pick the engine that fits the project. Godot 4 is a serious, shippable, production-grade tool.

What's the best external editor?

For Godot: the built-in editor is genuinely good. Many developers use it exclusively for GDScript.

If you want a separate editor:

VS Code with the Godot Tools extension. Most popular choice. Free.
JetBrains Rider if you're doing C# work in Godot or Unity. Paid but excellent.
Sublime Text or Neovim for keyboard-driven purists.

The choice matters less than people think. Use whatever lets you focus on the game.

How do I handle save files?

Godot's FileAccess + var_to_str() / str_to_var() is fine for small games. JSON via JSON.stringify() is fine for slightly larger ones. For Celeste-scale save data, JSON is completely adequate.

Store saves in user://saves/ (maps to a proper per-user data directory on every OS) — never in the game's install folder, which is often read-only.

Versioning is critical. Always store a save version number. When you patch the game and change the save schema, read the version and migrate old saves forward. Failing to do this is how indie games get a flood of bug reports on patch day.

Autosave often. Players losing progress is one of the worst feelings in games. Save at checkpoints, on major state changes, and on quit. Never rely on players to save manually.

How do I localize my game?

Godot has built-in localization support via .csv or .po files. Use the tr() function for every user-facing string from day one.

For the first release, ship in English only, with good string extraction infrastructure. Localize later when you know which markets care about your game.

Community translations — fans translating your game for free — are a real thing for successful indie games and are worth accepting. Give them credit; accept their PRs; sometimes pay a modest honorarium.

Professional translations are expensive ($0.10–$0.25 per word, so a 20,000-word RPG costs $2,000–$5,000 per language). Start with Spanish, Portuguese (Brazilian), French, German, Simplified Chinese, Japanese, Russian — those are the major Steam markets. Localizing early pays back; a Spanish localization alone often doubles your Spanish revenue.

Never use machine translation as your final localization. Players notice and review poorly. Machine translation is fine for internal testing, but ship with human work.

Community and Criticism

A negative review is devastating me — what do I do?

Read it. Let it hurt for an afternoon. Then decide: is it true?

If the reviewer found a genuine problem, you have a patch note. Thank them internally, fix the problem if you can, learn from it.

If the reviewer is being unfair, malicious, or wildly off-base — do not respond publicly. Do not get into comment fights. Do not post a Twitter thread. Do not email them. Every time a developer publicly argues with a negative reviewer, the developer loses, regardless of who's technically right. The game's brand damage from being "that developer who argues with reviews" far outweighs any vindication.

Talk to friends, a therapist, another dev. Game dev is emotional labor. Reviews are not a measure of your worth as a person. They're a measure of what one player felt during 90 minutes of their life. Keep perspective. Chapter 39 covers post-launch coping in more depth.

Someone is harassing me online about my game — how do I respond?

First, identify what "harassment" means. Rude criticism is not harassment. Targeted, personal, repeated, or threatening contact is.

Actual harassment:

Do not engage. Never respond, never argue, never explain. This is almost always the right move.
Block and report. On every platform. Screenshot first in case escalation requires evidence.
Protect your personal info. Remove your home address from public records. Use a P.O. box for business addresses. Don't post photos of your street or landmarks near your home.
Lean on your community. Other devs have been through this. They're the only people who really get it.
For threats — real threats, with specificity — contact law enforcement. It often won't do much but it creates a paper trail.
If harassment is sustained, take a break from social media. Your mental health is more important than "engaging with the community."

If it's a coordinated harassment campaign (some people have been targets of these), reach out to Take This, CyberSmile, or Games and Online Harassment Hotline — organizations that specifically help game industry harassment targets.

How do I find playtesters who aren't friends and family?

Friends and family are useless for serious playtesting — they'll tell you it's great to be nice. You need strangers.

Sources:

Game dev discords. Many have "show your game" channels where people will give real feedback in exchange for you playing theirs.
Subreddits like r/destroymygame (brutal but useful feedback) or r/playmygame.
itch.io "feedback requested" tags. Fellow indie devs playtest each other's prototypes.
Paid playtesting services. PlaytestCloud, UserTesting (pricier). You pay $50–$200 per session; you get recorded video of strangers playing.
Open beta on Steam / Discord. Once you're further along, post a beta and let fans in.
Student game programs at local universities. Sometimes willing to run playtests in exchange for dev insights.

Chapter 31 is all about playtesting. The short version: the feedback you get from strangers is an order of magnitude more useful than feedback from people who love you. Find strangers.

Burnout and Mental Health

I feel like I'm falling behind — everyone's making better games than mine

Stop looking.

Social media curates success. Every game you see on Twitter is a cherry-picked highlight. You are comparing your daily struggle to other people's best days. This comparison will make you miserable forever if you don't break it.

Mute or unfollow accounts that make you feel bad. Follow people who post their actual process, including the struggles. The "indie dev who posts only the beautiful GIFs" is not your friend; they're a highlight reel that happens to have your name in the mentions.

Also: better is a lie. Different isn't better. Your game is not better or worse than Celeste. It's different. It will find its own audience, if it finds any. Every game is somebody's favorite game, and you're not in competition with anyone who's already shipped.

I haven't worked on my game in 3 weeks — am I done?

Probably not. Everyone does this.

Three weeks off means you need a restart session — one where you don't expect to make progress, where you just reopen the project, read what you last wrote, play the current build, and remember what you were trying to do. Usually an hour of that is enough to get back into the headspace.

If three weeks becomes three months, or you feel actual dread when you think about the project: the project might be dead, or you might need a longer break, or the scope might be wrong and you're avoiding it because you know it's too big.

Don't let "I haven't worked in three weeks" become a self-fulfilling prophecy of "so I might as well not bother." Open the project. Do thirty minutes. Everybody's first session back is slow. Every subsequent session is easier.

Is crunch inevitable?

No. It is a failure of planning dressed up as "hard work."

Crunch happens because scope exceeded capacity and leadership refused to cut features. That is a scope problem, not a work-ethic problem. Every crunched game is a project that was mis-estimated, and the cost of the mis-estimation was paid by the developers' evenings, weekends, relationships, and health.

Good studios plan realistic scope. Good solo devs cut features before the final months.

The tell that a studio crunches habitually: they talk about crunch as if it's a virtue, describe working 80-hour weeks as "hardcore," or use phrases like "passion project" to mean "we don't respect your nights and weekends." Run from those studios. Chapter 37 (scope) and Chapter 39 (post-launch) cover the scoping that avoids crunch.

How do I keep going when I'm stuck?

Depends on why you're stuck.

Stuck because you don't know what comes next: write a simple task list of the next five concrete things you could do. Pick the easiest one. Do it. Momentum returns.

Stuck because the thing you're working on is boring: context-switch to a different part of the project for a few days. Come back refreshed.

Stuck because you don't believe in the project anymore: this is the hard one. Sometimes it passes; sometimes it means the project is dead. Play the current build again. If you still enjoy any part of it, keep going. If nothing is fun anymore — not to you, not to anyone — consider whether this is the project you want to spend another year on.

Stuck because you're burned out: take a real break. Not a day. A week. Two weeks. Go outside. Read a novel. Play other people's games for pleasure, not research. Your energy will return, if you let it.

The designers I know who shipped games were not the ones who never got stuck. They were the ones who knew the specific kind of stuck they were in and knew the specific remedy for it.

This Book

What order should I read the chapters in?

For most readers: straight through, chapter 1 to 40. The book builds. Each part uses ideas from earlier parts.

If you're in a hurry: Parts I and II (Chapters 1–10) are the foundational ones. Don't skip them.

If you already have experience: you can skim Chapter 1 (definitions) but do not skip Chapters 5–10 (mechanics, loops, feedback, emergence, randomness). These are where the craft lives. Similarly, Chapters 11–15 (psychology) and Chapter 29 (UI/UX) are essential regardless of experience.

If you're using the book as a reference: jump around freely. Each chapter is designed to stand reasonably alone, though cross-references show where the dependencies are.

Is this book appropriate for a classroom?

Yes. It was written for both self-study and classroom use. The instructor guide (separate from this book) provides syllabi for 1-semester, 2-semester, and quarter-length courses, plus chapter discussion guides and suggested assessments.

Chapters map roughly 1:1 to weeks in a 2-semester course, or 2:1 in a 1-semester course. The progressive Godot project can be a semester-long capstone assignment, or you can use the chapter-end exercises à la carte.

For graduate-level use: the book is undergrad-facing in tone. Supplement with primary sources — Schell's Art of Game Design (lens-based design thinking), Koster's Theory of Fun, and current academic game studies journals — to add theoretical depth.

How is this book different from Schell or Koster?

Those are both great books. They're different tools.

Jesse Schell's The Art of Game Design: A Book of Lenses is the encyclopedic reference. Hundreds of "lenses" — questions to ask about your design. Broad and abstract. Best for designers who already have some craft and want a systematic way to question their decisions.

Raph Koster's A Theory of Fun for Game Design is the essay-length meditation on why games are interesting to humans. Short, poetic, conceptual. Best as a one-weekend read that reframes how you think about games.

This book is the practitioner manual. Less poetic, more operational. Specific games, specific code, specific mistakes. Designed to be read alongside Godot, with you actually building things as you go. We're less interested in asking "what is a game, really?" and more interested in asking "why is this boss fight bad, and how do we fix it?"

Read all three. They complement each other. If I had to rank for a total first-time learner: this book → Koster → Schell. But if you already have some games under your belt, Schell is the deeper well.

What do I read after this?

In roughly this order:

Jesse Schell, The Art of Game Design: A Book of Lenses — systematic reference.
Raph Koster, A Theory of Fun for Game Design — short, conceptual.
Tracy Fullerton, Game Design Workshop — exercise-heavy, classroom-focused.
Adams and Dormans, Game Mechanics: Advanced Game Design — the Machinations framework (referenced in Ch. 24).
Richard Rouse, Game Design: Theory and Practice — classic, still relevant.
Kevin Oxland, Gameplay and Design — underrated, practitioner-oriented.
Then: genre-specific deep dives (platformers, roguelikes, RPGs), whichever matches your interest.

Beyond books: GDC Vault, Mark Brown's Game Maker's Toolkit on YouTube, Jonas Tyroller's channel, and the specific design post-mortems of games you love (most have a 30–60 minute GDC talk).

And: play games seriously, as a designer, not as a consumer. See Appendix H (Required Playing List) for a curated starting point. The most important design education is disassembling the games other people made and understanding what they did right and wrong. Books help. Playing is necessary.

Good luck. Ship something. Come back and read Chapter 39 when you feel like you wasted the last six months — you didn't.