It really depends on the project. For brand new games, the best we usually do is in-game comments and maybe some auto-documentation because we're writing a lot of new code as we go and time spent documenting is time not spent writing more code.
For established franchises and lifestyle games (e.g. Call of Duty, Destiny, FIFA, Elder Scrolls, etc.) that continue on using the same codebase, documentation of existing systems is more extensive and robust. This means that, as the last big game/expansion/deliverable ships and the next one begins development, there will be new devs hired on who will need to ramp up and older devs who hold a lot of tribal knowledge will leave the project (either finding new jobs, getting promoted to management, or transferred to a different project internally). This makes documentation of the existing codebase significantly more valuable over time.
My current employer is one of these kind of large franchise developers so we have multiple vectors of documentation of the various game systems. We have tools that auto-parse and auto-format comments in code in order to collate them into a searchable form, we have an extensive internal wiki to search for debugging and implementation information, and we've got tools engineers whose job it is to make sure as much of it is automated as possible so that there's little difficulty in generating good documentation for those who come after us.
[Join us on Discord] and/or [Support us on Patreon]
Got a burning question you want answered?
- Short questions: Ask a Game Dev on Twitter
- Long questions: Ask a Game Dev on Tumblr
- Frequent Questions: The FAQ