Image Description
Game README template
A game needs slightly different documentation from a general utility.
Before anything else, a player normally wants to know what the game is, how to start it and which key stops them repeatedly walking into the same wall.
The template
# [GAME NAME] [A short description of the game. What kind of game is it and what does the player actually do?] ## Requirements - [Supported operating systems] - [Required runtime] - [Audio, display or input requirements] ## Installation [Explain how to install or extract the game.] ## Starting the game [What does the player run? Is there anything they need to do the first time?] ## The aim of the game [Explain the objective in plain language.] ## Controls - [Key/button] - [action] - [Key/button] - [action] - [Key/button] - [action] ### Menu controls [Explain menu navigation if needed.] ## How to play [Explain the basic game loop. Give enough information to start without spoiling everything.] ## Audio [For an audio game, explain important audio concepts: stereo positioning, important sound cues, headphone recommendations, etc.] ## Accessibility [Screen-reader support? Self-voicing? Keyboard-only support? Remappable controls? Volume controls? Anything else relevant?] ## Saving and loading [Is progress saved automatically? Does the player need to save manually? Where are saves stored, if that matters?] ## Settings [Explain important settings.] ## Troubleshooting ### I get no sound [Things to check.] ### The game won't start [Things to check and where logs/errors can be found.] [Add problems players genuinely run into.] ## Reporting a bug [Where should reports go? Ask for the game version, steps to reproduce and logs if useful.] ## Credits [Developers, testers, music, sounds, libraries and other credits.] ## Licence [State the game's licence. If music, sounds or other assets have different licences, explain that too.]
Put the controls somewhere obvious
If somebody has forgotten the pause key, they want the pause key.
They do not want to read three paragraphs of backstory about the ancient kingdom of wherever before discovering it.
Audio games need audio documentation
If the game uses sound to communicate direction, distance, danger or state, explain enough of that language for somebody to begin playing.
You don't have to spoil every surprise. But if headphones are strongly recommended because stereo positioning matters, tell the player near the top.
Accessibility information should be useful
If the game self-voices, explain whether the player should leave their screen reader running. If it talks through a screen reader, say what you've tested.
If there is a known inaccessible area or feature, explain the limitation. "Accessible" on its own isn't very informative.
Assets may have different licences
Your code, music, sound effects and other assets do not necessarily all use the same licence.
If they differ, make that clear rather than putting "MIT" at the bottom and accidentally implying that somebody can reuse every sound in the game under MIT too.
Further reading and external resources
Previous: Software README template | Back to Writing a useful README