I’d say it would depend on how often new people join the project and how large the project is. Can’t speak for large development studios, but for small indie teams who often outsource or work with third parties I’d say some documentation that’s essential would be:
Top Level Application Description: What the project is and does from a users perspective. What the projects trying to achieve. Aesthetic styling, target levels for asset budgets quality and detailing. Game world background history and lore. Doesn’t need to be more than a few pages but is also good for existing members to keep focus on the projects main objectives, or for sending out to any third parties or prospective new members to give a description of the project.
Use cases: How the user will use/interface with the application and actions they can perform. The main game menu states (Top menu, game setup menus, network lobbies) and in-game states (game setup, in-game, micro-games, tear-down). Also actions users can perform both in menus (menu items and options) and in game (how the user will interact with the game). This should just be top-level abstraction, so just a list of the states and actions with a brief description of what they are, what they do, and when they can be used. Again this is also good for existing team members as it keeps mission creep in check and for keeping track of what has and still needs to be done.
Structural Overview: A listing of your main classes and a very brief overview of what they’re for, what they do, and the main classes they interface with (what uses them and who they use), a class or flow diagram would also be useful.
Class Descriptions: A more in depth description of each of the main project classes, the functionality they are responsible for and any major data structures they contain.
The design docs are useful for solidifying the top level structural outline of the project, clarifying the design, and highlighting things that might not have been thought of pre-implementation. They’re also super useful for new members of the team to have an overview of where to start looking in the code rather than being greeted by a wall of code and function names.
As other people have said, below top-level design documents, keeping functional, variable, and api documentation up to date is generally a nightmare and not worth it as you can spend twice as long documenting a function than coding it, then it will change the next week and someone will forget to update the documentation. Most large companies and projects auto-generate most of this now. If you keep the code itself well documented that’s usually enough.
Documented Code: Seriously worth including good in-line documentation in your code both to remind yourself later and for newcomers. For complex algorithms or formulaic equations its a good idea to have a document somewhere referencing source materials, research, or description of the algorithm.
Another really useful piece of documentation is auto-generating call sequence and flow logs by embedding debug printouts into the code at the entry/exit point of each major function (just print out the function name, argument values, and any other useful data), and save the logs for later reference. Can’t count the number of times this has saved me when a complex boot sequence has suddenly stopped working…