(Blogtober Day 4)
I am a big fan of documentation in game development. I enjoy reading it, but I really like making it. In my opinion, its one of the best ways to spread information on a team. But I aspire to do more than that with my documentation. I want to draw a reader in and get them invested in my documentation. Even if they don’t need the information, or have already found the part of the information they needed, I want to make documentation that keeps them reading.
I know, I’m weird. Most game developers I know appreciate documentation of any kind. But some would probably say that creating documentation takes time away from actually developing games, and I totally understand that argument. I’ll even throw in one of my own. Early on in a project, probably even before a team ramps up headcount to make the big production push, documentation is invaluable in my opinion. But as the train of production really gets into motion, and there are fewer and fewer milestones remaining before release, documentation begins to have diminishing returns. There is less need to spread specific information, and the information that needs to be spread tends to be conveyed quicker through chat messages. Although I still think it’s good practice to document things all the way through production until release.
Then there’s the issue of old, undepreciated documentation that lingers like a landmine waiting for someone to read it as gospel only to find out all the information is old and outdated and every step they followed now has to be undone. The poor soul.
I have often thought that for larger teams and bigger projects, having someone in charge of, or even someone whose main job it is to maintain and upkeep documentation. It might seem frivolous, but I could see someone in a role like that speeding up the onboarding process and helping compile accurate and up to date information for milestone presentations to execs. They could make templates, custom to the type of information or discipline. I could see a lot of benefits from it.