What if I'm not an artist?

Most indie devs aren't. The advice here is about decisions — style, consistency, readability — which are learnable judgment calls, not drawing skill. Plenty of beloved indie games shipped with simple art and strong decisions.

Where does bug reporting fit into this?

Quietly underneath all of it. Whatever you ship — store page, jam build, full release — players will hit problems you can't reproduce, and most won't tell you. A lightweight reporting tool like Bugnet captures those crashes and reports with the context to fix them, which protects the reviews and momentum everything above depends on.

Game Fonts: How to Choose and License Them

Quick answer: Pick two fonts — a characterful display face for titles and a workhorse readable body face for everything else — and verify each license actually covers embedding in a game (many 'free' fonts don't; Google Fonts' OFL catalog does). Check language coverage before localization, and test readability at couch distance on real screens.

Pick two fonts — a characterful display face for titles and a workhorse readable body face for everything else — and verify each license actually covers embedding in a game (many 'free' fonts don't; Google Fonts' OFL catalog does). Check language coverage before localization, and test readability at couch distance on real screens. That's the short version — the sections below get into the how, the why, and the mistakes worth dodging.

Body text is an engineering choice

The font players read for hours must perform: clear at small sizes, distinct glyph shapes (Il1, rn/m), good hinting, multiple weights. Proven UI workhorses beat characterful choices here — save personality for the display font. Test where players actually read: 1080p TV at couch distance, Steam Deck, and your lowest supported resolution.

Pixel games need extra care: pixel fonts must render at integer multiples of their design size or they smear, defeating the entire aesthetic. Choose one designed at your UI scale.

Licensing is where free fonts surprise you

Font licenses distinguish uses: desktop/print licenses often don't cover embedding in an application, which is what shipping a font in a game is. The safe defaults: SIL Open Font License fonts (the bulk of Google Fonts) explicitly permit embedding and modification; commercial foundries sell specific app/game licenses — read for 'embedding', user counts, and modification rights.

Keep the license file with the font in your repo and ship required attributions in your credits. Fonts are the asset type devs most often pirate accidentally, and foundries do send letters.

Localization coverage decides earlier than you think

That perfect display font may contain Latin glyphs only. If localization is plausibly in your future, check coverage now: extended Latin (Turkish, Polish, Vietnamese diacritics), Cyrillic, and — the big architectural one — CJK, which usually means pairing a dedicated CJK font and building font-fallback into your text system from the start.

Test with real translated strings, not lorem ipsum: German breaks layouts with length, and missing-glyph tofu boxes (□□□) in a shipped build is the classic localization embarrassment that one font-coverage audit prevents.

Consistency beats quality, almost every time

Players forgive simple art instantly if it's coherent. What breaks the spell is mixing: one photorealistic asset in a stylized scene, three different pixel densities in one room, fonts that belong to different games. A modest style executed consistently reads as deliberate; a patchwork of great assets reads as cheap.

Before adding any asset, ask whether it could have come from the same hand as the rest. If the answer is no, restyle it or skip it — the scene is better off without it.

Your game is judged at thumbnail size

Most people meet your art as a 231-pixel-wide capsule, a compressed GIF, or a phone-screen screenshot. Detail that only reads at full resolution is invisible at the moment of decision. Strong silhouettes, high contrast, and one clear focal point survive shrinking; intricate noise does not.

Zoom your screenshots out to thumbnail size regularly while you work. If you can still tell what's happening and where to look, the art is doing its job where it matters.

Plan for the bugs you won't see coming

Whatever else you take from this, build yourself a way to hear about problems. Once your game is on other people's machines, most failures happen out of sight: the crash on hardware you don't own, the save that corrupts once in fifty exits, the bug players mention in a review instead of a report.

A lightweight crash and bug reporting setup — even just Bugnet's free tier wired into your engine — turns that silence into a fixable list. The devs who look calm at launch aren't luckier; they just see their problems earlier.

Putting it to work

Don't try to act on all of this at once. Pick the one change that costs you the least and pays the most this week, do it, and see what actually happens before reaching for the next.

Most of this rewards steadiness over intensity. A small improvement made every week, checked against how real players respond, outruns any single burst of effort — in this corner of game development and every other one.

Coherent and modest beats gorgeous and mismatched — and check it at thumbnail size.