One Guidebook, Two Repositories: Where abagames’ “Joys of Small Game Development” Actually Lives

Evidence note: This article rests on publicly circulated addresses for a single project — a web edition and two source repositories — and on the guidebook’s own framing of itself. None of those three facts has been independently corroborated here beyond the addresses themselves resolving as links; no archive check, no commit-history review, and no test of any kind was performed for this piece. Where a specific claim depends only on a link, that is marked at the claim. Readers who need certainty should open the links and confirm directly.

The Guidebook: abagames’ "Joys of Small Game Development" and What It Sets Out to Do

"Joys of Small Game Development" is a guidebook published under the developer handle abagames, and its subject is exactly what the title says: the pleasure of making small games, rather than the mechanics of shipping a large commercial one. The English edition presents itself as a written guide addressed to people building tiny games on their own terms (English web edition).

That framing matters more than it might sound. Most game development writing is organized around a destination — a store page, a funded studio, a portfolio piece. A guidebook organized around enjoyment is organized around a process instead, and the practical consequences are different: scope discipline, fast iteration, and finishing as a habit rather than as a milestone. PlayAgit’s earlier profile of abagames’ guidebook on making games for the fun of it covers that argument in more depth; this article is about something narrower and more practical — where the text physically lives, and why that turns out to be two places rather than one.

Reading It Without Cloning Anything: The Web Version Hosted on GitHub Pages

The guidebook is readable in a browser at an abagames.github.io address, which is the domain pattern GitHub Pages assigns to a user account’s hosted sites (English web edition). (Evidence level: the public link resolves to that address; that it is served by GitHub Pages rather than some other host mapped to the same domain pattern has not been independently confirmed for this article, and the guidebook’s hosting arrangement is not documented in any source cited here.)

The reader-facing consequence is simple and does not depend on resolving that uncertainty. No clone, no build step, no toolchain: the text opens in a browser. For a guidebook whose whole premise is lowering the friction between wanting to make something and actually making it, a zero-install reading path is consistent with the message.

What the public record does not establish is the relationship between the web edition and the source — whether the site is generated automatically on each commit, built manually and pushed, or maintained separately. Sources cited here do not confirm any of those, and readers should not assume the web page and the repository are guaranteed to be in step at any given moment.

Why a Guidebook About Enjoying Small Games Matters to Developers Working Alone

Solo and very-small-team developers face a problem that larger teams mostly do not: there is no external structure forcing scope to close. No producer, no milestone review, no publisher deadline. Projects expand until they stall, and the stall reads as personal failure rather than as a predictable outcome of unbounded scope.

A guidebook built around small games and the enjoyment of making them is, in effect, a scoping argument dressed as an attitude. Smaller projects finish; finished projects teach more than abandoned ones; the loop tightens. That is a claim about developer practice, not a measured result — no study is cited here, and none should be inferred.

There is a second, more mundane reason this matters, and it is the reason this article exists. Free, openly hosted developer guidebooks tend to get cited badly: a reader links the rendered page when they meant the source, or links a repository when they meant the reading copy, or links the wrong one of several similarly named repositories. That failure mode is familiar from other open developer texts — PlayAgit’s write-up on where the SFML Game Development Book’s code actually lives documents a near-identical mix-up between similarly titled repositories. The same trap is set here, and the shape of it is worth naming.

Following the Source: The Guidebook Is Maintained in Repositories Under the abagames Account

Public links for the guidebook’s source point to repository addresses under the abagames GitHub account (base repository, English repository). (Evidence level: repository URLs under that account namespace; whether those repositories are actively maintained, what their commit cadence is, and whether the account is the sole maintainer are all uncorroborated — no commit history, contributor list, or license was examined for this article.)

So the accurate statement is narrow: the guidebook’s source is addressed under the abagames namespace on GitHub. Everything a reader might reasonably want to know beyond that — activity level, contribution policy, licensing terms for reuse or translation — is open, and this article does not close it. Anyone planning to fork, translate, or quote at length should read the repositories themselves rather than rely on this summary.

The English Version Is Its Own Repository, Not a Language Folder

This is the structural detail that most affects anyone citing the work. The guidebook is addressed as two separate repositories rather than one repository with a language subdirectory: a base version at joys-of-small-game-development, and an English version at joys-of-small-game-development-en (base, English). (Evidence level: the two distinct repository URLs are the entire basis for this. That both exist as independent repositories, rather than one being a redirect, mirror, or archived predecessor of the other, has not been independently verified here.)

The distinction is not cosmetic. A language folder inside one repository shares an issue tracker, a commit history, a star count, and a single canonical clone URL. Two repositories share none of those. Each accumulates its own issues, its own history, and its own stars; a pull request opened against one does not touch the other; and a translation can drift from its base without any visible signal in either repository’s interface. Sources cited here do not establish which repository is upstream of the other, or whether changes flow in one direction, both, or neither.

What Two Repository Names Change for Anyone Citing, Linking or Contributing

Three practical consequences follow, all of them actionable without resolving the open questions above.

Citing. An English-language article, syllabus, or resource list that means the English text should link the -en address. Linking the base repository and calling it the English guidebook is a mis-citation, and it is the kind that propagates — curated link collections copy each other, and PlayAgit’s survey of game development resource lists on GitHub found link-health problems of exactly this family.

Linking for readers. If the intended audience is meant to read rather than fork, the web edition is the better link; a repository landing page asks a casual reader to work out which file is the book. Course pages and reading lists routinely get this backwards — the same publishing question PlayAgit examined in its look at what a game development course publishes versus what a student published instead.

Contributing. A typo fix in the English text belongs in the English repository; a correction to the underlying argument may belong upstream in the base one. Which is which is not documented in any source cited here, so the safe move is to open an issue asking before preparing a pull request — cheaper than a PR filed against the wrong tree.

Developer Takeaway, and the One Question the Public Record Does Not Answer

The takeaway is small and concrete. There is one guidebook, one browser-readable edition, and two repository addresses, and the right link depends on what the link is for: read at the web edition, cite the -en repository for the English text, and reserve the base repository for work that belongs upstream.

The question the public record does not answer is the one a contributor most needs answered: how the two repositories relate. Is the English version a translation that tracks the base, a fork that has since diverged, or the primary text with the other as a variant? Nothing cited here settles it, and the distinction determines whether a correction filed in one place ever reaches the other.

That question is answerable, and answering it would require actual work rather than reading: comparing the two repositories’ commit histories and file structures, checking whether English-side changes appear upstream, and measuring how far the texts have drifted. No such comparison was performed for this article, and it should not be read as having been done. It stands as a proposed follow-up — a repository comparison with dates, commit counts, and a diff of the two texts — rather than as a finding.