What Games Are Made Of
Six connected views cover the player experience, simulation, presentation, data, services, and production work of a game.
Think of a game such as a small farming adventure. The visible feature may be planting a seed. Underneath it sit controls, world time, seasons, soil rules, an inventory, animation, sound, saved progress, balancing, tests, and tools for the people building it. Change the example to an online tactics game and many of the parts remain recognizable, but their risks and connections change dramatically.
The Game Knowledge Library is AGC's growing map of those parts. It covers the experience a game is trying to create, the rules and changing state, controls and presentation, content and saved data, online or platform services, and the production work needed to build, test, release, and repair the game.
The internal library is detailed and machine-readable. This public version uses familiar examples and leaves detailed specifications, test material, generated records, and private coordination notes where they belong: inside the project.
A shared vocabulary helps designers and developers notice missing connections. It also helps distinguish “many games need this idea” from “many games should run the same code.” Those are not the same claim.
Improving one genuinely reusable part could help every adopting game. A defect could also reach every adopter. The library therefore maps ownership, failure, cleanup, testing, staged upgrades, and rollback alongside the attractive features.
A creator could explore everything involved in crafting, saving, turn-based combat, dialogue, input, accessibility, or an online trade. A team could compare what stays common across games with what must remain specific to a genre, engine, platform, or particular design.
The pages below begin with the whole-game map, then explain connections, reuse risk, action flow, and specialization.
This is a public explanation of a foundation-stage knowledge library. It is broad but not exhaustive, and its categories are not working modules. No page claims that an implementation exists, that similarly named systems are interchangeable, or that a real game has accepted them.
Six connected views cover the player experience, simulation, presentation, data, services, and production work of a game.
A sword purchase, a save icon, and a controller adapter show why game systems need clear owners and understandable connections.
Reuse can improve several games at once, but shared bugs demand exact versions, independent testing, staged adoption, and rollback.
A puzzle move and an item trade show what can happen between a player's choice and a confirmed result.
Genre and game-specific modules reuse higher-level contracts while keeping their distinctive rules, content, balance, and feel.