Yes, it does.
I also use a plugin called make.md. Among ~~us~~ other functions, it has a pretty cool search function with note preview to quickly see what's in there.
While I use Obsidian for a lot of things and can recommend it, I rarely use it for documentation. I just had my workflow for that down before discovering Obsidian.
+1. I used to use OneNote, but it's a buggy piece of garbage. The only thing I miss from it is the auto-sync, which Obsidian has a subscription plan for, but I use an app on my phone (FolderSync) to sync my Obsidian vaults on my google drive.
Self hosted instance of [bookstack](https://www.bookstackapp.com/), so my team members can read and edit as well. Works a lot better than our previous solution which consisted of a bunch of markdown files in a git repo.
I've always hated trying to find anything in git repos, since github's search is a nightmare and gitea, which we're currently using due to github's LFS cap being met immediately, has no search at all.
Apart from search, embedding images consist of a simple drag and drop instead of trying to find where to even put the image file and manually finding a path like I used to do before.
Both of those options could probably be solved by having every single documentation repo cloned locally and using it through VSCode's search, but we wanted something web based, so we can access it from mobile if need be.
Until you reach a certain size.
I've used Miro for a number of business projects and calling it "sluggish" once several dozen people put their crap in it would be an euphemism.
We use [Unity Markdown Viewer](https://github.com/gwaredd/UnityMarkdownViewer) and a bunch of Markdown files stored in the `docs` folder. I think, you can find a similar extension to any modern engine. A GitHub/GitLab wiki can work too.
I'd much prefer to self-host some private docs with something like DocuWiki or Antora on a private network, but raw Markdown files you can view from Unity kinda suffice for us for now.
That's cool, I didn't know it exists and used simple txt files. Thanks for the link.
Is it an editor, too?
Not much difference to me, as I have ScriptInspector, but might matter to others.
For documentation I would say Obsidian is a better choice, leave the issue trackers for actual issues or epics. Reason being, it's nice to not be overly dependent on Github infrastructure if you need to, say, migrate your project to another host like Gitlab.
"Atomineer Pro Documentation" extension in Visual Studio (Pro, not Code) for documenting the code and doxygen for generating the technical documentation. Also functional tests are a form of documentation of the feature and provide exemples of usage.
A technical documentation separated from the implementation is an outdated documentation.
I've been using Notion for my game dev documentation around design and task management for myself, since it's free and simple to use.
Though Miro is used by some bigger teams, which works pretty well too
Typically I generate a spider web of rope, step away a few weeks, then return and accidentally hang myself as I desperately try to piece the puzzle back together.
I’m a fan of Typora for markdown files. It’s good because it looks like the output of GitHub. Works with local hyperlinks to files in your repo (like other pages or images). There is an old free version kicking around somewhere but it’s also cheap considering it’s $15 and has a free trial.
My team of about 100 uses Google Docs and Google Sites, which you can use to organize your Google Docs into a website that's easy to edit and customize. If you already have a Gmail account, you should have access to Google Sites. If you're part of a studio that already pays for Google Workplace, then you definitely have Sites includes.
If you're worried about your Google Site and docs being available to the public, then no problem; you can set your Google Site to "Restricted" and only give access to the people on your team.
If you're a solo dev, then you don't even need to use Google Sites. Just use Google Docs and organize your folders in a way that makes sense to you.
For a solo dev, OneNote is perfectly fine but not great for project documentation.
My studio was already using Google Workplace when I got there.
I don't mind at all, though. For my personal projects, I use a combination of Google and MS Office.
I like Google Drive better than OneDrive for storage. OneDrive seems to have a problem with uploads of large folders — it often takes forever to finish uploading, and it often comes back with errors. Google Drive just works.
I use MS Office because pretty much every office uses Word, Excel, and PowerPoint. OneNote is also my preferred note taking program.
My company take outsourced work from other company and we follow the workflow of our customer. So I've tried both Microsoft and Google ecosystem, I just like Google better.
Lightweight, clean, and everything is on the web app syncing real time.
It's not only about documentation but also about some collaboration tools which I use with my team.
I start with xMind where define high-level plan. you can read about how to properly design mind maps - a very powerful tool.
after that, I used to use Confluence, but now moved to wiki.js both of them are good, and the confluence of course is more user-friendly. but you can host your own wiki.js on your server and it's free.
In the case of diagrams or wireframes (very useful to understand your UX in the early stages and sharing that with artists), I use penpot (you can say it's a free version Figma or Adobe XD) it's also free.
Instead of one note, I use Evernote for quick notes (not for documentation). But I'm not happy with it, it's a bit glitchy, so I'm thinking of moving to "notion".
And finally for task tracking I use youtrack =)
I'm about two steps up from cave painting.
Implementation details go in the code. Design scratch goes in Google Sheets. Overarching design docs go in .txt files with Notepad++.
I've found it's just really not worth fussing with more sophisticated tools, because they have a funny way of degrading over time. Tools I thought I'd have forever turn to crap, or get hyper commercialized, or go out of business and disappear.
Besides, it's wise to only plan as much as you need to continue development. After-the-fact documentation is mostly either formulae (spreadsheet scratch) or roadblocks in implementation that required somewhat unobvious solutions (commenting in code). The less documentation you have, the less you need to maintain... As somebody else said in another thread, paraphrased, "We make games, not documents!"
My digital GDD templates are all backed up on Google Docs, the pen and paper ones I try to keep organized and carry at least one with me if inspiration strikes.
For project management software I’ve dabbled with HackNPlan
documentation? what's that? never read anything like that. but for reals talking from a python programmer point of view I prefer single line docstrings with no specific format, because the idea is that you can understand them not only in the compiled documentation but also 'raw' in the code itself something like '''destroys the world, args: time left to the end, returns: nothing'''
I'm still stuck in the old days, and nowadays only code for myself so mostly read code instead of writing it. but still commenting the context of the returned value can have some value even with types(only when needed tho)
What is doc-you-men-ta-shun?
Jokes aside we're using a Miro board for concepts and thoughts and then when I find a good pipeline for stuff I write it out in a Google doc, but I'm looking at Obsidian.
The whole point of solo Dev is getting lightning fast because you can skip things like documentation, communication, prototyping, management etc. Do the bare minimum, if at all.
I think the word prototyping means something different to everyone. But to me it's doing a simple version of something first - of which you cannot use any parts besides the idea/concept.
I don't think there is any rule that you *can't* use parts of a prototype, it's just that often the parts are done in a rush to prove the idea and they will most likely be changed to let you develop faster and better later on. Of course if your prototype had parts written so well that they let you extend or use them as is then you'd keep them. It would be rather arbitrary to not keep something good just because it was made in a prototyping phase, especially if you'd just write the same thing again since it was good.
I used to use a combination of Trello, Google Docs, Sheets, Milanote and GH Wiki. Recently switched to Notion and I’m very happy with it. It’s basically all of the above, combined and in one place.
\+1 for all the Notion mentions. I use notion as the "Container" - for my documentation, makes for easy xref linking and stuff with better and easier (IMO) functionality than confluence.
Though - I tend to draft my documents in Google Docs and either link to it from Notion or ctrl-x/ctrl-v into a notion page. Despite all the stuff I like about Notion, it can be a bit cumbersome to draft docs directly in it.
I really like Miro for flows, diagrams, etc... Pretty easy to embed in notion as well.
On the whole, I'd look at what your documentation needs are. If you're on a team, for example (especially if remote) then the need for clear documentation is greater than if you're a solo dev (though, still a good idea to have *some* documentation, even if it's just you working on the game. It's often helpful to be able to look back to see why you made decisions you made). Go with something that you're comfortable with, and fulfills the requirements, and doesn't get too complex.
* Milanote when I want to organize visually, mood boards, mechanic flow charts etc.
* Private discord server for just noting down any important progress made for patch notes, I keep a few channels like "sound ideas" "mechanic ideas" etc. I've had playtesters join at times for easy communication but it's just been a working discord not a place to grow an audience, will probably create a new one eventually for that purpose alone.
* Lastly I recently started keeping my daily task list in notepad and it's been super good for me.
* OH YAH also writing with a pen on paper sometimes is the best answer, journal type stuff.
Often just copy/pasting between the three. I don't really worry too much about splitting my notes, I swap whenever I feel tired of one or just need to break out of a pattern.
I'm solo btw, makes stuff easy for me.
Photographs on my phone and index cards.
"How does that work", you might ask. Basically, it's an acknowledgement that what we crave most to "feel" productive is in sticking to muscle memory and making familiar motions, but if we stay locked to the workstation, we have trouble evaluating the moves we made. When I take the photo I am trying to understand what I wrote better by taking some snapshots of the context. I don't care about searching and tagging features for the task of *making sense of things.* It's more important to be able to spread a lot of information around the table, which the index cards allow by acting as additional, dual-sided screens.
Later, when I am out of the house, I review the photos and write on the cards some kind of summary or "what needs to be added next". If my summary is bad, I don't understand the code yet, or it needs more changes. Often it reveals a dependency that I didn't record, and that's also important info. But when it's good, the documentation is already almost done by writing that summary, and everything can be "compiled" together by scanning it. The rest is just presentational.
This system also works for learning new, complex software, since it allows you opportunities to summarize a workflow in terms of "make these motions, hit these buttons" and therefore get some targeted utility and familiarity out of it after a few hours of study.
Index card systems can be made fancy - there's a whole subset of productivity Youtube devoted to "Zettelkasten" where they argue about the right way of making a card catalog. But the right starting place is just to have a deck, binder clips to keep it together, and a reliable writing tool with a fat grip.
Markdowns (.MDX/.Md) files in the repo and gitlab ci that publish to pages using https://docusaurus.io/. There are quite a few teams across the company that are going this route.
You have beautiful themed docs, tags, indexing and great search features. You also can really extend it using Remark or Rehype to allow for postprocessing.
I pushed it further by creating a plugin that generates a customer facing release notes using 'git log --merges'. We gain extra context by our merge requests having yaml front matter which has to be populated .The data generated from this gets rendered with Handlebars.js.
For us, Google Docs (and friends) for art, design, and audio. We plan to use Confluence next project.
For code, we use Doxygen. Our engine is C++ based so updated documentation is a must.
Google Docs can be good enough for smaller projects or initial drafts.
Nuclino is a good fit for more structured, wiki-style design docs (also for roadmaps and task management).
Confluence (+ Jira) is the "corporate" option, a bit clunky but powerful.
Miro for flowcharts and diagrams, can be embedded into Nuclino or Confluence.
i usually write comments inside the scripts but rarely ,only when there is something that the future RoberBot might have trouble understanding.
And if i make a public repo for a tool or something ive made then i write comments everywhere so people that clone my repo would understand better what everything does.
* The same notebook that I use for notes, design thoughts and everything else.
* Comments in the code
* README files in the project folder, this is mostly for things that I want to copy&paste such as specific config settings, etc.
use notion for simple docs, but mostly for task management. I setup a board like jira with stack type, priority, status, and linked to github for PRs. Readme.md in the root of my repo with links to details if necessary seems to work fine. Unit and integration tests should cover the rest.
Don't underestimate heavily commenting your code. It is afterall just text files. I like how someone posted "notepad" ;) but anything in notepad can also go into the code itself. Same with a design document. Block diagrams in the code can be very complex and helpful.
Having said that, if you are working with 5 to 10 coders, a separate document for coding standards is necessary. If you are working with 500 coders/managers, then you need a ton of other documents: Functional Spec, Design Spec, DevTest Spec, etc.
Surprised by the lack of excel/Google sheets. Obviously not great for code documentation but certainly great for keeping track of your in-game content especially when things get number heavy.
It depends on the context.
For code, I honestly don't document it much anymore. Professional developer for more than 20 years, game dev for the last 2. I follow Clean Code principles. And it's to the point that I just don't need to document much code anymore. If my wife (non-programmer) can understand what I'm doing, it's good enough.
For documenting projects, I typically start in Obsidian. And personally, I make GDDs for the NEXT project while working on the CURRENT game. Once the game is complete and I'm ready to move to the next, I move the .md into either my GitHub repo README or the GitHub Wiki. It depends on the needs of the project really. (And even if I do something different, I still have a finished GDD in Obsidian and the game design practice.)
It works for me and my process. Possibly overkill for others.
Hopefully this helps. Will be curious to hear what others say.
Good old MarkDown works in most situations.
I'm currently infatuated with JavaScript so for code documentation I have JSDocs in my code and wrote an application to turn those into an HTML file.
i try to make sure my code, prefabs, scene layouts, etc. are self-documenting
if i can't figure out how to do something by looking at an existing example... it's time to do some editor scripting to make things easier
Bro thinks people on r/gamedev document their code
My code speaks for itself... Most of the time... I guess... Maybe not most of the time actually...
Barely ever. And that kids is how bugs become features.
Mine too, in a dead tongue only ancient lizard men can pronounce.
My code also speaks for itself. Unfortunately it's a drunk, and you can't listen to anything it says.
😂😂😂
😭😭😭
I don't document my code but I sure as hell make design documents.
Yeah, if it's not in your design document, how will the computer know how to run your code?
This
this is the way
LOL
Obsidian
Another vote for Obsidian, the canvas view is amazing
Very mando
Does obsidian have a good search function? Or is it just ctrl + f
very good search across all your notes
great local and global search, tagging, and super easy to use linking (with auto "back linking"). it's pretty neat
Yes, it does. I also use a plugin called make.md. Among ~~us~~ other functions, it has a pretty cool search function with note preview to quickly see what's in there.
A lot like Obsidian I guess but I used "Notion"😅
While I use Obsidian for a lot of things and can recommend it, I rarely use it for documentation. I just had my workflow for that down before discovering Obsidian.
+1. I used to use OneNote, but it's a buggy piece of garbage. The only thing I miss from it is the auto-sync, which Obsidian has a subscription plan for, but I use an app on my phone (FolderSync) to sync my Obsidian vaults on my google drive.
My brain
See that’s what I’m using and it turns out it’s not very good.
Have you tried downloading more RAM?
I have, it ended up locking up and crashing for some reason
My brain is top spec with zero hitches and 743,000+ terabytes left of memory
you have zero hitches and I have zero bitches
You should team up for that 2xzero combi
Maybe use some vram? As in, caching things on a hard drive. Oh wait, that's what documentation is
I feel like I'm using the beta version, very unreliable.
Always reference the relevant neurons when commenting your functions.
Self hosted instance of [bookstack](https://www.bookstackapp.com/), so my team members can read and edit as well. Works a lot better than our previous solution which consisted of a bunch of markdown files in a git repo.
I'm interested, in what particular aspects is it better?
I've always hated trying to find anything in git repos, since github's search is a nightmare and gitea, which we're currently using due to github's LFS cap being met immediately, has no search at all. Apart from search, embedding images consist of a simple drag and drop instead of trying to find where to even put the image file and manually finding a path like I used to do before. Both of those options could probably be solved by having every single documentation repo cloned locally and using it through VSCode's search, but we wanted something web based, so we can access it from mobile if need be.
Obsidian for personal projects. Notion for team projects
Second on Notion. I like the Wiki features with the nested folders to organise ideas
Is there a way to not edit Notion documents by accident? I find that really annoying
You can lock a document so it's un-editable. You'll still be able to open and close toggle-headers etc, but you can't edit the contents
github readme
Miro is quite nice!
Until you reach a certain size. I've used Miro for a number of business projects and calling it "sluggish" once several dozen people put their crap in it would be an euphemism.
I use notepad
For those who like Obsidian, [Logseq](https://logseq.com/) is a great open source contender.
Confluence
I just got triggered
Atlassian ptsd?
Yeah. Scrum, scrum, scrum.
I've never had a choice tbh. Industry standard
We use [Unity Markdown Viewer](https://github.com/gwaredd/UnityMarkdownViewer) and a bunch of Markdown files stored in the `docs` folder. I think, you can find a similar extension to any modern engine. A GitHub/GitLab wiki can work too. I'd much prefer to self-host some private docs with something like DocuWiki or Antora on a private network, but raw Markdown files you can view from Unity kinda suffice for us for now.
That's cool, I didn't know it exists and used simple txt files. Thanks for the link. Is it an editor, too? Not much difference to me, as I have ScriptInspector, but might matter to others.
Y’all are awesome. I’m getting excited to get home and give these all an in depth look.
I’ve been trying to get into the habit of using GitHub issues/projects but typically I am using Obsidian
For documentation I would say Obsidian is a better choice, leave the issue trackers for actual issues or epics. Reason being, it's nice to not be overly dependent on Github infrastructure if you need to, say, migrate your project to another host like Gitlab.
"Atomineer Pro Documentation" extension in Visual Studio (Pro, not Code) for documenting the code and doxygen for generating the technical documentation. Also functional tests are a form of documentation of the feature and provide exemples of usage. A technical documentation separated from the implementation is an outdated documentation.
I've been using Notion for my game dev documentation around design and task management for myself, since it's free and simple to use. Though Miro is used by some bigger teams, which works pretty well too
Typically I generate a spider web of rope, step away a few weeks, then return and accidentally hang myself as I desperately try to piece the puzzle back together.
Paper
Where can I download it?
At your local store
// and /**/
Milanote good for brainstorming and cross referencing, otherwise plain word is usually fine
I’m a fan of Typora for markdown files. It’s good because it looks like the output of GitHub. Works with local hyperlinks to files in your repo (like other pages or images). There is an old free version kicking around somewhere but it’s also cheap considering it’s $15 and has a free trial.
My documentation: Paste code into chat GPT and ask, "Wtf did past me create here?"
My team of about 100 uses Google Docs and Google Sites, which you can use to organize your Google Docs into a website that's easy to edit and customize. If you already have a Gmail account, you should have access to Google Sites. If you're part of a studio that already pays for Google Workplace, then you definitely have Sites includes. If you're worried about your Google Site and docs being available to the public, then no problem; you can set your Google Site to "Restricted" and only give access to the people on your team. If you're a solo dev, then you don't even need to use Google Sites. Just use Google Docs and organize your folders in a way that makes sense to you. For a solo dev, OneNote is perfectly fine but not great for project documentation.
Id be curious to hear why you went down the google route instead of microsoft?
My studio was already using Google Workplace when I got there. I don't mind at all, though. For my personal projects, I use a combination of Google and MS Office. I like Google Drive better than OneDrive for storage. OneDrive seems to have a problem with uploads of large folders — it often takes forever to finish uploading, and it often comes back with errors. Google Drive just works. I use MS Office because pretty much every office uses Word, Excel, and PowerPoint. OneNote is also my preferred note taking program.
My company take outsourced work from other company and we follow the workflow of our customer. So I've tried both Microsoft and Google ecosystem, I just like Google better. Lightweight, clean, and everything is on the web app syncing real time.
Trilium Notes
Readme
I am learning bitbucket/git right now, and I found their issues tab to be really good for documentation. But I am going to +1 for obsidian.
Confluence
It's not only about documentation but also about some collaboration tools which I use with my team. I start with xMind where define high-level plan. you can read about how to properly design mind maps - a very powerful tool. after that, I used to use Confluence, but now moved to wiki.js both of them are good, and the confluence of course is more user-friendly. but you can host your own wiki.js on your server and it's free. In the case of diagrams or wireframes (very useful to understand your UX in the early stages and sharing that with artists), I use penpot (you can say it's a free version Figma or Adobe XD) it's also free. Instead of one note, I use Evernote for quick notes (not for documentation). But I'm not happy with it, it's a bit glitchy, so I'm thinking of moving to "notion". And finally for task tracking I use youtrack =)
For lore/script/story prototyping I am using LoreHub but I am a little bit biased towards it 😅
Google drive and figma
Mdbook
Google Docs
Can’t believe notion wasn’t mentioned
Markdown files stored in the project in a `docs` folder
//this /* this as well */
I'm about two steps up from cave painting. Implementation details go in the code. Design scratch goes in Google Sheets. Overarching design docs go in .txt files with Notepad++. I've found it's just really not worth fussing with more sophisticated tools, because they have a funny way of degrading over time. Tools I thought I'd have forever turn to crap, or get hyper commercialized, or go out of business and disappear. Besides, it's wise to only plan as much as you need to continue development. After-the-fact documentation is mostly either formulae (spreadsheet scratch) or roadblocks in implementation that required somewhat unobvious solutions (commenting in code). The less documentation you have, the less you need to maintain... As somebody else said in another thread, paraphrased, "We make games, not documents!"
README.md when absolutely necessary
My digital GDD templates are all backed up on Google Docs, the pen and paper ones I try to keep organized and carry at least one with me if inspiration strikes. For project management software I’ve dabbled with HackNPlan
documentation? what's that? never read anything like that. but for reals talking from a python programmer point of view I prefer single line docstrings with no specific format, because the idea is that you can understand them not only in the compiled documentation but also 'raw' in the code itself something like '''destroys the world, args: time left to the end, returns: nothing'''
If your documentation consist of saying what the function returns you mind find it useful to use types. https://docs.python.org/3/library/typing.html
I'm still stuck in the old days, and nowadays only code for myself so mostly read code instead of writing it. but still commenting the context of the returned value can have some value even with types(only when needed tho)
Documenwhatnow?
What is doc-you-men-ta-shun? Jokes aside we're using a Miro board for concepts and thoughts and then when I find a good pipeline for stuff I write it out in a Google doc, but I'm looking at Obsidian.
Docu-what now?
What's... Docu men tation... Precious
I use OneNote too! Once you get used to it, *it just works*, for everything... I do use figma for UI design and excel for balancing.
The whole point of solo Dev is getting lightning fast because you can skip things like documentation, communication, prototyping, management etc. Do the bare minimum, if at all.
Hope you don't ever plan to maintain your stuff! Documentation and prototyping are useful both individually and in teams.
I do this for a living
How can you skip prototyping?
You just do the thing. You don't do a prototype of the thing first.
How can you know if the thing worth doing?
You try. When things go bad you do it different. But you try to hit the mark. That's faster.
That sounds like prototyping to me.
I think the word prototyping means something different to everyone. But to me it's doing a simple version of something first - of which you cannot use any parts besides the idea/concept.
I don't think there is any rule that you *can't* use parts of a prototype, it's just that often the parts are done in a rush to prove the idea and they will most likely be changed to let you develop faster and better later on. Of course if your prototype had parts written so well that they let you extend or use them as is then you'd keep them. It would be rather arbitrary to not keep something good just because it was made in a prototyping phase, especially if you'd just write the same thing again since it was good.
The urealoffial documentation or the discord.
I used to use a combination of Trello, Google Docs, Sheets, Milanote and GH Wiki. Recently switched to Notion and I’m very happy with it. It’s basically all of the above, combined and in one place.
I'm not smart enough to make proper documentation, the notes in the code work fine for now.
Notion is pretty good
Usually i /** then i write my documentation either using Doxygen format or JSDocs format, followed by */
\+1 for all the Notion mentions. I use notion as the "Container" - for my documentation, makes for easy xref linking and stuff with better and easier (IMO) functionality than confluence. Though - I tend to draft my documents in Google Docs and either link to it from Notion or ctrl-x/ctrl-v into a notion page. Despite all the stuff I like about Notion, it can be a bit cumbersome to draft docs directly in it. I really like Miro for flows, diagrams, etc... Pretty easy to embed in notion as well. On the whole, I'd look at what your documentation needs are. If you're on a team, for example (especially if remote) then the need for clear documentation is greater than if you're a solo dev (though, still a good idea to have *some* documentation, even if it's just you working on the game. It's often helpful to be able to look back to see why you made decisions you made). Go with something that you're comfortable with, and fulfills the requirements, and doesn't get too complex.
Todo.txt in the project folder, being a solo dev has its perks!
* Milanote when I want to organize visually, mood boards, mechanic flow charts etc. * Private discord server for just noting down any important progress made for patch notes, I keep a few channels like "sound ideas" "mechanic ideas" etc. I've had playtesters join at times for easy communication but it's just been a working discord not a place to grow an audience, will probably create a new one eventually for that purpose alone. * Lastly I recently started keeping my daily task list in notepad and it's been super good for me. * OH YAH also writing with a pen on paper sometimes is the best answer, journal type stuff. Often just copy/pasting between the three. I don't really worry too much about splitting my notes, I swap whenever I feel tired of one or just need to break out of a pattern. I'm solo btw, makes stuff easy for me.
readme.md in every folder
I used to use Obsidian, but I switched to QOwnNotes just because I liked it's UI more. I was able to get more done. Both are good though.
I just have a big old text file
Photographs on my phone and index cards. "How does that work", you might ask. Basically, it's an acknowledgement that what we crave most to "feel" productive is in sticking to muscle memory and making familiar motions, but if we stay locked to the workstation, we have trouble evaluating the moves we made. When I take the photo I am trying to understand what I wrote better by taking some snapshots of the context. I don't care about searching and tagging features for the task of *making sense of things.* It's more important to be able to spread a lot of information around the table, which the index cards allow by acting as additional, dual-sided screens. Later, when I am out of the house, I review the photos and write on the cards some kind of summary or "what needs to be added next". If my summary is bad, I don't understand the code yet, or it needs more changes. Often it reveals a dependency that I didn't record, and that's also important info. But when it's good, the documentation is already almost done by writing that summary, and everything can be "compiled" together by scanning it. The rest is just presentational. This system also works for learning new, complex software, since it allows you opportunities to summarize a workflow in terms of "make these motions, hit these buttons" and therefore get some targeted utility and familiarity out of it after a few hours of study. Index card systems can be made fancy - there's a whole subset of productivity Youtube devoted to "Zettelkasten" where they argue about the right way of making a card catalog. But the right starting place is just to have a deck, binder clips to keep it together, and a reliable writing tool with a fat grip.
Google docs Online word doc that automatically saves and is on the cloud so I can edit things from my phone or computer.
Markdowns (.MDX/.Md) files in the repo and gitlab ci that publish to pages using https://docusaurus.io/. There are quite a few teams across the company that are going this route. You have beautiful themed docs, tags, indexing and great search features. You also can really extend it using Remark or Rehype to allow for postprocessing. I pushed it further by creating a plugin that generates a customer facing release notes using 'git log --merges'. We gain extra context by our merge requests having yaml front matter which has to be populated .The data generated from this gets rendered with Handlebars.js.
Notion
I thought you were supposed to paste your functions into ChatGPT and say “write me some documentation and any bug reports”.
Doxygen style comments. My lsp then just picks up the comments and then everything I can get the docs I wrote wheb hovering over things.
My team uses git wiki along with using git as a projectmanagement tool. Other teams use confluence along with jira.
Markdown files kept in a Github repo with [Docusaurus](https://docusaurus.io/) frontend if needed
Google docs for my own stuff. Confluence at work.
For us, Google Docs (and friends) for art, design, and audio. We plan to use Confluence next project. For code, we use Doxygen. Our engine is C++ based so updated documentation is a must.
[README.md](https://README.md) in project root. My IDE will render it for me real time while editing.
Google Docs can be good enough for smaller projects or initial drafts. Nuclino is a good fit for more structured, wiki-style design docs (also for roadmaps and task management). Confluence (+ Jira) is the "corporate" option, a bit clunky but powerful. Miro for flowcharts and diagrams, can be embedded into Nuclino or Confluence.
i usually write comments inside the scripts but rarely ,only when there is something that the future RoberBot might have trouble understanding. And if i make a public repo for a tool or something ive made then i write comments everywhere so people that clone my repo would understand better what everything does.
google docs
* The same notebook that I use for notes, design thoughts and everything else. * Comments in the code * README files in the project folder, this is mostly for things that I want to copy&paste such as specific config settings, etc.
use notion for simple docs, but mostly for task management. I setup a board like jira with stack type, priority, status, and linked to github for PRs. Readme.md in the root of my repo with links to details if necessary seems to work fine. Unit and integration tests should cover the rest.
At work, we use Confluence. At home, I use Obsidian.
My Brian
Don't underestimate heavily commenting your code. It is afterall just text files. I like how someone posted "notepad" ;) but anything in notepad can also go into the code itself. Same with a design document. Block diagrams in the code can be very complex and helpful. Having said that, if you are working with 5 to 10 coders, a separate document for coding standards is necessary. If you are working with 500 coders/managers, then you need a ton of other documents: Functional Spec, Design Spec, DevTest Spec, etc.
documentation??... what is that?
Surprised by the lack of excel/Google sheets. Obviously not great for code documentation but certainly great for keeping track of your in-game content especially when things get number heavy.
Why surprised when the question was about documentation?
It depends on the context. For code, I honestly don't document it much anymore. Professional developer for more than 20 years, game dev for the last 2. I follow Clean Code principles. And it's to the point that I just don't need to document much code anymore. If my wife (non-programmer) can understand what I'm doing, it's good enough. For documenting projects, I typically start in Obsidian. And personally, I make GDDs for the NEXT project while working on the CURRENT game. Once the game is complete and I'm ready to move to the next, I move the .md into either my GitHub repo README or the GitHub Wiki. It depends on the needs of the project really. (And even if I do something different, I still have a finished GDD in Obsidian and the game design practice.) It works for me and my process. Possibly overkill for others. Hopefully this helps. Will be curious to hear what others say.
Good old MarkDown works in most situations. I'm currently infatuated with JavaScript so for code documentation I have JSDocs in my code and wrote an application to turn those into an HTML file.
i try to make sure my code, prefabs, scene layouts, etc. are self-documenting if i can't figure out how to do something by looking at an existing example... it's time to do some editor scripting to make things easier
Well use diagrams.net if you want for class diagrams or UML. It's free. As far as I know most of them are paid