I think the intent was to be like a wiki/knowledge base, but I agree with your and GPs sentiment though.
Aside: is there a wiki platform for things like these? I know there's fandom wikis which feels like the wrong platform for these sorts of things, and that you can host your own, but sometimes that's just overkill...
Do we have a business idea here (with a free tier, obvs)?
Fandom (and a few others like it) is really what you’re looking for although the adverting on these sites makes it very user hostile. I don’t know if there is a better business model for this other than charging directly. I would probably just do a one-click digital ocean deployment
Kinda parallel to this, if anyone has any recommendations on a good book about game design, more focusing on design patterns, how to structure code, good practices, etc rather than how to program or use a specific engine I'd be grateful.
It's not really clear what you are asking for. You term your desire 'game design', but that generally means the arrangement of systems (ex rules) for a game . But, your first list sounds more like 'video game architecture'.
I found Chris Deleon's Hands-On Intro to Game Programming in HTML5 a helpful book of graduated exercises that also demonstrates how to reuse components of previous games. [https://gamkedo.gumroad.com/l/hands-on-game-programming] It is, however, somewhat expensive and I only sprung for it as part of a larger bundled deal. I imagine that you could find similar works, or it might not jive with you. His udemy course, using this as the text, has a preview video. [https://www.udemy.com/course/how-to-program-games/#instructo...]
The best book I've read about making games is the two Blood Sweat and Pixels by a games journalist.
Regarding design, Vlambeer (Rami Ismail and JW Nijman) is kind of the template of the contemporary indie game. Watch their talks.
HN frequently links to stuff that could appear on "Awesome X" lists on GitHub but I don't personally find it very useful.
Honestly you will not find good books about these things. Games culture writing almost entirely falls into the wrong side of cultural materialism: since the vast majority of game creators are still living, talking about them is marketing. Marketing is survival. It's very hard to have a negative subjective opinion about anything to do with games, including engineering and design, and participate in the gaming ecosystem. All of the games industry operates, essentially, under the "Banning the Negative Book Review" (https://www.nytimes.com/2013/11/30/opinion/banning-the-negat...) premise, in a Darwinian way.
So like if it's a book by a game creator... At the end of the day, they have to promote their game. If they were dead, and someone else were writing about it, okay, the bad stuff won't be omitted, it will be authentically bad. It won't be mea culpa or here's-what-I-learned badsplaining. But that doesn't happen because everyone is still alive.
This is difficult to express because there isn't a succinct humanities idea for this - it's cultural materialism, but that covers a lot of ground - but it is the reason you can't just like, find a book about game development that is mind-bendingly good. It's why there isn't an idea as succinct as The Hero's Journey for games like there is for books. You have to accommodate any and all ideas for making games, not because there's no objective truth to it (there is), but because you might make someone's thing less marketable.
I would not recommend Blood Sweat and Pixels. While it does have details on publishing decisions and crunch of making games, it has little insight into any actual game development. It's more of a sensation piece on how difficult games are to make. GP seemed to be looking for design and pattern references.
I second Game Programming Patterns! I created a little indie game [1] using the design patterns mentioned in that book. Still not quite complete, (good) games are HARD, but even this small game would've fumbled into a mess of spaghetti if it weren't for what I learned from that book.
I haven't read it, but Tynan Sylvester wrote a book about game design while making Rimworld. I've seen the way he's discussed some of his decisions in public forums and it's always seemed insightful, so his book it probably good.
Out of curiosity, would principles about how to structure code be different in games vs other software?
I quite enjoyed "Theory of Fun for Game Design" by Raph Koster.
It has many great insights about what we'd call product or design decisions, but it feels like a philosophy book, and you'll also learn stuff that applies to daily life.
It's exciting to see experienced people in the game industry trying to break down barriers to show how things are/can be done. Everyone seems to do it differently, especially at smaller game studios. It's so easy to get caught in your bubble of how to make games and not figure out all the different tools out here that can pop you out of your comfort zone, biases, and blind spots.
This seems like a good start and has the potential to be useful. But some of the documents are hard to consume because it looks like you need more context to understand nuance and how they fit together with other things.
I'm not very familiar with Notion. Will this be something that is easy to expand with Notion or is this the wrong platform for such things?
There is probably nothing better for a technical wiki. It's usually bundled as part of the cpanel software on cheap webhosting sites.
For $5/m or less you can have something professional looking, rather than the notion document linked above.
And if your community can't collectively (eventually) cough up $5/m for the hosting costs, then you don't have a community anyway, so it would be pointless having a wiki.
dokuwiki is nice. It's a bit different than mediawiki, so you might want to try both and compare to see which you like better.
One of the biggest differences is that Mediawiki is database-backed while dokuwiki is filesystem-backed. Another is that dokuwiki is closer to markdown syntax while mediawiki has its own more complex syntax.
Overall, dokuwiki is notably simpler and easier, but mediawiki might have some more management stuff that could be helpful if the site has lots of activity and needs more moderation.
For a lot of uses, they're pretty comparable and it would come down to preference.
Or are we calling any published document a wiki these days?