Turning a README into a Playable Game Catalog

Martin Delophy, maintainer of the Awesome GPT-6 Astra community collection, has transformed the project's README into a structured, playable game catalog. The gallery parses the Markdown file to generate visual cards with screenshots and links, while a parser distinguishes game entries from navigation and metadata. The workflow supports multilingual maintenance and includes tests for robustness.

GitHub: awesome-gpt-6-astra https://github.com/MartinDelophy/awesome-gpt-6-astra Live gallery: Astra Games https://astragames.aigccreative.com/ Building a game with AI leaves another problem to solve: helping people find it, try it, and understand how it was made. I maintain Awesome GPT-6 Astra, a community collection of games and interactive projects. As the collection grew, a Markdown list became the content source for a visual gallery with screenshots and playable links. This post explains a few design choices behind that workflow: structured entries, a README-driven catalog, real screenshots, and multilingual maintenance. A collection becomes difficult to browse when every submission uses a different format. One project links to source code, another has a screenshot, and a third hides its demo inside a long development log. We use a small, consistent entry format: - Project name → playable demo - Creator → public profile - Platform → browser requirements, controls, access conditions - GPT-6 Astra → model contribution statement or development record - Resources → source code and setup instructions, when available - Preview → an actual gameplay screenshot A demo answers “Can I try it?” Source code answers “Can I study or run it?” A development record answers “How was it built?” These fields serve different purposes. Public source code is optional. A playable project can still be useful to explore, provided its creator is credited and the available information is clear. Maintaining a GitHub list and a separate frontend array creates duplicate work. A contributor can update the README while the gallery continues showing an old description—or misses the project entirely. Our gallery reads the public upstream README and parses it into structured records: README entries ↓ Parse titles, categories, authors, links, and screenshots ↓ Structured catalog records ↓ Gallery cards and playable links Contributors can work with Markdown and pull requests without learning the frontend. The website handles presentation and periodically checks for catalog updates. The tradeoff is that Markdown is now a content interface. Formatting conventions matter, and the parser needs to handle edits predictably. A README also contains navigation, language selectors, contribution instructions, licenses, and creator profiles. Treating every link as a game would produce a noisy catalog. The parser needs to distinguish: The existing tests cover adding, deleting, and editing entries, duplicate handling, malformed documents, caching, and recovery from failed reads. For a project like this, the useful guarantee is straightforward: a normal README contribution should produce the expected catalog update. A short description rarely communicates how a game feels. An actual screenshot helps readers understand its visual style and interface before opening it. We embed screenshots in the README entries so the gallery can use them as covers. For captured images stored in the repository, we also record their source, capture date, and the scope of the check. That last detail matters. Entering the first level is not a full playthrough. A manual describing touch controls is not evidence that someone tested the game on a phone. Keeping those distinctions explicit makes the catalog more useful to both readers and future maintainers. Screenshots should represent the running project, and third-party images retain their creators' rights. The collection has 12 README language versions. Translating a description is only one part of keeping them aligned. For a new submission, we also check that every version includes the entry, uses the same demo and creator links, references an existing screenshot, and has consistent counts and maintenance dates. Model attribution needs the same care. If one version says “awaiting creator confirmation,” another should not describe the contribution as independently verified. The website's current catalog source is the default README. The translated READMEs are additional documentation that we maintain alongside it; translating them does not imply that every language is a separate runtime data source. “Made with GPT-6 Astra” can describe very different development processes: implementing one mechanic, helping design an interface, iterating on game rules, or contributing across a larger project. We aim to preserve those distinctions. Attribution follows creator or submitter statements, and missing confirmation is marked explicitly. Inclusion is not an independent model benchmark or an endorsement from OpenAI. A useful submission explains: These details give other developers something to learn from beyond a finished screenshot. The goal of this project is to give creators a place to show working games and connect their demos with useful development context. Playable prototypes are welcome. If you have built a game with Astra, you can submit it through the repository with a demo, creator credit, a real screenshot, and a description of the model's contribution. Disclosure: This article was drafted and translated with AI assistance from the maintainer's project notes and repository context.