Strudo: Game Development Documentation

News & General Discussion
,
1

I’ve been working on my own game, Project: Catalepsy, for quite a while, and I ran into a problem with our documentation.

We were using Notion and Google Docs. It worked well initially, but as the project grew, programming, art and design ended up working from different versions of the same documentation. Eventually, it became difficult to tell what was actually implemented in the engine, what had changed, and what had simply been cut from the design.

That’s what led me to build Strudo.

There are plenty of good general purpose tools for notes and wikis already, and if that works for your project, you probably don’t need this. Strudo exists for a narrower problem: documentation that’s supposed to drive a game production, not just record ideas. Each document type (GDD, TDD, LDD…) only surfaces the information relevant to that discipline, and everything stays organized by department and priority, so a design decision doesn’t get buried three pages into a doc nobody has opened in months.

The current document types include:

  • GDD: Game Design
  • LDD: Level Design
  • NDD: Narrative Design
  • TDD: Technical Design
  • ADD: Art
  • DOC: Free-form Documentation

Each document type has blocks designed for the kind of information that needs to be documented there.

You can see the available document types and blocks here: Documentation: [docs.strudoapp.com]

Here’s the editor with a real project loaded: Mario Bross. — Mario Bross. | Strudo

Strudo is currently in closed beta, and I’m opening access to developers from this community.

The Indie plan is free and will remain free, so you can try it on your own project without paying anything.

Beta access: Create account — Strudo

If you’d like to give feedback or follow development, there’s also a: Discord

image
image1915×789 88.1 KB

image
image1915×800 118 KB

2

That’s good thinking but immediately I wonder: did you explore the existing options for documenting things?

There’s like a gazillion like-minded tools already out there, many of them are free, most of them are some form of wiki (like yours) and flexible enough to support your exact use-case.

One of the most powerful ones is logseq, which also acts as a journal, and supports both agentic workflows and version control. Paid tools like Gitbook (and yours) are increasingly becoming hard sells because anyone can create them, tailor-made, fully local, built on open source, for under $20 worth in tokens. Much like you did, presumably. Except you’re trying to sell it.

The use-case you are targeting is going extinct. All my documentation is managed by AI. If I want to read something specific, I prompt and I get a webpage that’s tailor-made to answer the prompt in the way I want it, derived entirely from existing local project artifacts (no hallucinations). If I dump a buttload of losely connected notes for the record, the AI puts each in the correct document in the right place.

You may want to research a workflow like this for your internal needs. It of course depends on whether you want everyone on the team to drain the company’s tokens, and how much that will cost you. I bet it’s going to pay off. :wink:

And thanks that you brought this to my attention. I tasked an agent to review whether it makes sense to formalize our documentation processes and tools. Among all the options, it recommended to merely add a SQLite query index generated from the existing .md files for faster lookup. And extracting tasks out into their own database, so I got my own Monday.com in a couple minutes too. :smiley:

3

I think we’re actually solving slightly different problems, even if they overlap.

I had the same thought when I started building Strudo: a lot of this can be built internally, and AI agents make that cheaper than ever. For some teams, that’s enough. The question I had was how much time it takes to maintain that custom solution as the project grows and more people depend on it.

There’s also a difference in what we’re solving. Your system starts from local project artifacts to describe the current state. That’s genuinely useful. Strudo starts from the other direction: the information the team needs to define and agree on before it becomes part of the implementation. Code can tell me how an ability works right now, but not necessarily what behavior we intended, what was decided during design, what’s still pending, or what was cut.

One clarification: Strudo doesn’t use AI at all. The structure is native to the application: documentation types, blocks, and relationships between them, designed to represent the game’s systems rather than just store text for later retrieval. It also has an API layer to connect that structured information with the tools used to build the game.

And Strudo does have a free individual plan permanently, so it’s not really a free-tools-vs-paid-tools situation.

Your own Monday.com example is actually a good illustration of the trade-off: you can build exactly what you need, but then you also own the maintenance. That’s a perfectly valid choice; it just means you’re probably not the user Strudo is targeting.

Your workflow may simply not need that extra layer, and that’s perfectly fine. That’s exactly what the beta is for: finding out how common this problem is for other teams and how much value they actually get from solving it this way.