The holidays have come and passed, and I’ve been working on a Game Design Document (GDD) for my first commercial game. In practice, it’s a comprehensive, living, descriptive software design document that will serve as the implementation guide. Right now, it’s about 4500 words, and it’ll grow a bit more, but I’m also going to do an editing pass; it should be accessible and useful. It’s over half done.

There are a lot of resources available for GDDs, such as Gamescrye’s archive, Jason Bakker’s GDD Template, and Indie Game Academy’s Template.

Right now, there are two main sections: Concept and Details. Concept is the most fleshed out: introduction (including elevator pitch and tagline), setting, hook, differentiator, structure, and features. Details get into the Story, Characters, Level Design, Art, SFX, Music, UI, and some related topics. There are some subsections in there that I’ll likely reorganize.

Timothy Cain’s How to Write Design Docs (one of Fallout’s main designers) recommends an easily describable setting, the high-level story description. The system details the mechanics that support the setting and the story. Every mechanic should have specific goal(s) to explain why it’s included.

Looking at Tom Hall’s DOOM Bible (one of Doom’s designers), there are three sections: Game Specs, Game Info, and Appendices. Scanning through it, I notice a lot that didn’t make it into the original game; it’s revision .02 from 1992-11-28; it launched a little over a year later on 1993-12-10. While the term “Bible” in game development is dated, its use here is interesting as the religious text evolved over time and was interpreted in many ways. Both the cut content and flexible interpretation are good reminders that plans should be able to evolve while still maintaining the core fundamental concepts.

I’m making myself nervous with some of the ambition I have in the dialog system; similar to works like FTL and Fallout, if conditions are met, then your dialog options change. There should be some variation and exceptions, but it should be a treat, not for every encounter.

I want to use Ink, but that will require me to use the C#/mono version of Godot, and I feel that learning a whole new language and building, marketing, and shipping the game is a bit much. I am aware that Godot can mix GDScript and C#, but I’m prioritizing shipping for now. The Godot Dialogue Manager looks to be a better fit for my needs in the meantime.

I need to ship a fun and compelling game; it doesn’t have to be perfect, but it has to be good. The tools matter less than the result, and I’m not shipping the source code with the game.

In the meantime, back to the GDD, the system mechanics & goals are going to be my next major tasks.

A meta note; I also met with a new SCORE mentor and had a great conversation. Broadly, he validated my business plan and the approach I was taking to start development, and steered me away from putting the cart before the horse (insurance and an LLC too early).

My first mentor was very helpful in getting the main business set up and introduced me to someone who worked on board game development; that was really useful. However, they didn’t have practical experience in video game development, so when my questions got a bit more specific, it was time to find an additional resource. All are sincerely appreciated!