Discussing a Coherent GDD
The first draft of the Game Design Document (GDD) for my game is about 80% done, and with it, I’m now able discuss it coherently and start getting feedback. On Tuesday, I attended my first ROC Game Dev open project night and chatted with a number of other developers, played what folks were working on, and discussed my project. I heard a cautionary tale of patent squatting on procedurally generated enemy systems; what I was planning didn’t intersect, but it was a good warning.
I reconnected with Doomlaser, who I collaborated with on a couple of projects since a 7DFPS Game Jam in December 2020. I did the soundtrack, contributed SFX, QA’d and discussed mechanics on his project called GUN FLESH; it’s been on hold for a while, but it should move forward again in 2026. I have an entire mastered album’s worth of music waiting for its release that I’m looking to time with the game’s release. Here’s a dev log video of the project from 2022:
We discussed both his and my plans, technologies, and so forth; it was great to talk shop.
I also had an off-hand conversation with a volunteer at a local cat rescue that turned into a great in-depth discussion of games, mechanics, and development. They were very interested in what I was doing and had some really neat insights; I wrote down the site, and they joined the Discord that night (thank you and welcome, Yeti!).
As I’ve been working on the GDD, I’m reflecting on the experience I had last year when I built a prototype that was a variation on the standard card game Casino War. It worked, it checked a bunch of boxes, you could play and win (or lose), and it was coherent. It also wasn’t much fun; the base game, War, is deterministic. Casino War adds betting mechanics, and I implemented a variation of that; instead of betting, you would boost, and the opponent would also have to boost. Practically, you’d max boost every time.
I learned a number of things from this experience:
- It’s fun to have strategic choices.
- My cousin Ed Forth made a fantastic “game” implementing Candyland that took away the illusion of choice; you would give it your names, press a button, and it fully simulate the entire game and declare the winner. which my cousin Ed accurately pointed out was deterministic.
- Having to manually “fill up” every time is repetitive and annoying; if maxing out is the best strategy, why even bother?
- A standard deck of playing cards on its own has no personality; you need to decorate.
- Don’t add music too early in development, you will get sick of it, even if it’s “good.”
- Default button focus goes a long way towards unconsciously improving usability.
- States are essential, and Godot doesn’t have a built-in game state management system; that was quite the rabbit hole!
I also didn’t have a GDD and kind of riffed the development. It wasn’t utter chaos; I knew I wanted to make a game based on War, it needed a menu, credits, sound, keyboard and mouse support. When it became obvious that it wasn’t fun, I iterated. When it wasn’t scaling, I refactored.
I reorganized my GDD as I’ve been working, so the current structure for my GDD is:
- Concept
- Elevator Pitch
- Introduction
- Tone
- Rating
- Platforms
- Inspirations
- Players
- Genres
- Features
- Setting
- Lore
- Stages
- Game Structure
- Characters
- [redacted]
- Gameplay
- Presentation
- Art
- Sound
- User Interface
- Controls
- Implementation
- Accessibility
- Monetization
- Achievements
- Localization
- Milestones
- Appendix
This week, I’m going make some wireframes for the layout and I’m going to try to physically prototype the gameplay with some blank playing cards. That will inform the mechanics that I’m trying to articulate so I have a clear vision when it comes time for implementation.