Gyms, Zoos, and Museums (godotfest2025)

Chaos Computer Club - recent audio-only feed

Everyone always mentions that people do not read documentation. This is also the case for us as game developers. So what can we do about that? First, it is important not to force everyone to read pages and pages of documentation. Usually, only programmers and other technical folks go through all the effort of reading up on functionality. So what about artists, and designers? Thankfully, solutions already exist: Gyms, Zoos, and Museums. Let's look at examples, see how they work, how they can be built, and how they improve the development of your games. Everyone always mentions people do not read documentation. This even goes for us game developers. So what can we do about that? First, it is important not to force everyone to read pages and pages of documentation. Usually, only programmers and other technical folks go through all the effort of reading up on functionality. So what about artists, and designers? Thankfully, solutions already exist: Gyms, Zoos, and Museums. For example, even back during the creation of Half-Life 2 in the 2000s, and we have examples of zoos, which are levels filled with art assets. Sometimes they are scattered by the kind of asset they are, sometimes they are built up into small vignettes that show how the assets can be combined. And these are still used nowadays, for example for de_nuke and de_aztec in Counter-Strike, and Skin Deep. These asset zoos provide a way for artists and designers to see what the assets are, how they fit together, what they look like in proper lighting, and allow them to document their usage in an interactive level, instead of pages and pages of text. The user experience of the developer becomes a part of the creation of the game, so that the context of the game is inside the game, instead of in an email, slack message, or confluence page elsewhere, where nobody will read it. This can then even be combined with NPCs, so that an NPC zoo is created. This then allows for easy testing of the NPCs, such as for quest design and shops. We can walk through the level, talk to each NPC, and not have to remember their name, what their spawn command is, where they are located in the world, or anything else, as everything is contained within one level. These levels can then be generated using existing folder structures, or manually set up by a lead level designer or art director, who can then make sure the right assets or NPCs are displayed in the level. We have seen the same be done for museums: Levels that contain examples of specific functionality for testing purposes. For example, Unreal Engine has these great museum levels for their cloth simulations, physics simulations and more. These museum levels can get incredibly large, similar to how documentation can get large, but because it they are in-game levels, it becomes much easier to see how something works, why it works that way, and can still include in-game text instead of being in an email, slack message, or confluence page elsewhere, where nobody will read it. Lastly, Gym levels allow for easy documentation and testing of user abilities. They show off the exact scales and angles of doorways, terrain, and where a player can and cannot walk. Instead of document that nobody will read about door heights, cliff angles, etc, you can have a clear and colorful live demo of player movement in the gym. The level is set up with everything necessary to quickly test the player character. Again, it is in-game, as a level, and interactive, allowing quick editing, changes, and testing directly within the applicable context, and not in an email, slack message, or confluence page elsewhere, where nobody will read it. Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://pretalx.godotfest.com/godotfest-25/talk/TTCUNU/