I was wondering if when people made games if they could publish their Game Design Docs.
I want to start programing with my son and It would be nice to see how others have developed their games.
Things like this would be so cool to see. The behind the scenes look into game development.
Another thing I use that is similar but not exactly what I am looking for is this…
https://www.nintendo.co.jp/clv/manuals/en/index.html
These old NES manuals are cool.
A lot of times, I don’t make docs. I just program the game from an idea in my head and add stuff in as I go. For small projects, like ones you will commonly see on the Arduboy such as my Festive Fight game, it may actually slow people down to sit around and draw everything out. I personally find coding to be really fun and I am quick at it, but this may not be the philosophy of everyone.
Normally I don’t bother with documentation because it’s normally just me working on games, or because the person I’m working with doesn’t need all the details of how the game is going to work, just enough to do their part (e.g. the artist only needs to know what to draw), or because I’ve already got a game functional before I ask for any additional help (e.g. I give translators advanced copies of the game so they can see the context and confirm the translation is suitable).
However, when I did my 2.0 revamp of Minesweeper, I did actually do some designing before I started and I made use of GitHub’s project feature to keep track of what I had to do.
I only just realised I forgot to add some of my design work to the repo so I’ll add it later when I’ve improved the quality enough to make the handwriting legible.
When I do make design documentation, I always do it on paper first and go digital afterwards.
And when I do design stuff it doesn’t always have a 1:1 correlation with the code because it’s more abstract than the code itself.
With a lot of games the best documentation you can hope for is git history, and perhaps GitHub issues and PRs.
Some people don’t bother trying to make their git history neat and tidy because it’s extra effort, but I tend to try to spend the time to keep my history well organised and include brief descriptions about what the changes do or why they’re needed.
For Minesweeper 2.0, the commit history is the closest thing to documentation.
You can also look at the issues and PRs.
I don’t know if you can see the milestones, but I used a milestone too.
And I don’t know if you can see projects, but I used a project.
If you can’t see those, here’s an annotated screenshot of the project, part way through development:
It’s a kind of kanban board.
Notably, you can see some ‘stretch goals’ that didn’t make it to the final version.
When you learn how to use them, GitHub’s projects can be incredibly useful for keeping track of things.
It didn’t stop me keeping a todo list on paper as well, but it helped when I accidentally lost the bit of paper :P
When I worked on Dark & Under we didn’t really document things, we discussed ideas and our decisions were documented by our conversations, and we can’t make those public unless redact all the personal information and opinions that were discussed, and that would take some serious effort.
Guilty as charged:
(And that’s one of the ‘neat’ pieces.)
Usually I throw the ‘working stuff out’ pages in the bin, otherwise I end up with too much paper lying around.
My desk looks more like a peice of modern art than desk X3
As I once said to @eried:
If your desk isn’t horribly messy then you’re not trying hard enough.
(Or something like that… I’m paraphrasing.)
Aha, found it.
He showed us this:
So I said:
And then:
I’ll provide better quality scans of these later, but for now I have to rush off for dinner:
Hopefully you can see what made it into the final design and what got scrapped.
I actually had the theme state planned out from the start, but it was one of the last things I added.
Last Wed I contacted support of a company that made a powerbank that I bought from them with a small fault… and sending proof (video) of the problem, they said my desk looks like of an engineer so I am probably able to receive remote instructions to fix the device.
I didn’t know, but in a way, the messy desk seems to be my signature now.
Ahh, yes, most of my design docs are notes that look like this.
I feel like a lot of design documents are really for companies or larger groups of people. 
Yep, they’re more for making sure entire teams are on board with the idea of what’s happening.
And for the benefit of the future of the company when they want to revisit an old game but they realise they’ve fired all the original developers. :P
I think most solo developers do plan, but it’s usually just scribbled notes on scraps of paper.
In my case it’s often on a page of one of my notepads, sandwiched between notes about the benefits of Tau, notes about the group axioms, various todo lists and other game designs.
(Either that or scribbled on a piece of A5 that ends up in the bin before the game is even finished.)
Ouch. This hits close to home… :’(
What I think would be cool is for learning… I have been in programming classes and had to design and program something. It would be nice to have all the parts of a game and then figure out how to code it. This way you can have a project and just focus on coding…
It’s a good idea, but I don’t think you’d be able to do that just from existing stuff on the forum.
I think it’s something we could arrange in future though.
For now I think it would be easier if you just made some documentation for him to follow.
I’d recommend noughts and crosses as a first game.
It requires arrays (for the board) and a state system (for tracking turns), and the way people chose to solve how to test for the win condition is always interesting (some solutions are more elegant than others).
Another game that may be cool to make is Dots and Boxes
Some basic games like these would be fun to work through.
Something like that is surely possible. Not sure about AI, though. Flood fill may be hard to teach a new programmer.
Hello @Agent6,
I find these thing interesting too, take a look at these:
Personally, when working on a game alone I make no docs (except for automatically generated, like Doxygen). The reason is that when I tried I always got stuck in analysis paralysis – I need to simply start working and improvise to get things done. For small projects, well written code with nice comments plus automatically generated docs are more than sufficient. docs are needed when people working on the project can’t keep the whole project in their head at once.
Example of me getting stuck at analysis phase (no, you don’t wanna see the hi-res version 
):
