The Thriveopedia

I have the beginnings of the Thriveopedia in place.

It can be opened from the main menu or pause menu, and when opened from the pause menu, you can access the statistics page, which currently is just the evolutionary tree (that doesn’t update beyond the first generation). The back and home buttons work.

I went with a very non-extensible approach to tabs for now, following the model of the options menu rather than something where you can have multiple tabs open at once. How important is it that a proper tab system is implemented as part of my fossilisation PR? I don’t want to spend ages on it, and the rest of the Thriveopedia probably won’t come along for a while.


I’d say a full on tab system wouldn’t be very important to implement right now considering the limited content of initial implementation. But I think there should be some minimum structure set up that’ll allow fleshing this out to a proper system easily in future.

1 Like

I don’t like that as being open source is one of the things that will set Thrive apart from basically all other games (that a lot of people might get on Steam). So I think it should be kept as a very unique feature. I commented on that PR that I want to keep the very visible source button but also have the social github button.

In game wikis are not that unique, I wouldn’t say. And also I can’t remember the civilization wiki having a button in the main menu for it.

At most I’d put it in the tools or extras sub menu.

I think if you don’t consider the future now (especially the left side where we’d have the content tree) the tab functionality you are writing now needs to be just completely ripped out, and the layout sizing may need to be completely rethought.

I think that system needs to interact with the back and forward buttons, no? And doing that properly also from the start saves requiring to redo that system as well in the future.

Though, I’ll leave it to @Oliveriver how future proof these are made, or will we need to entirely replace these parts of the Thriveopedia later.

1 Like

Alright. There is redundancy but I do see your point. I’ll put the Thriveopedia at the top of the Extras menu.

I think I’ll go for something slightly more future proof than my current prototype by having Thriveopedia page scenes that can be derived for the specifics, but otherwise I’ll keep everything as simple as possible. It will have to be torn out later, but I’m hoping I can keep the amount that’s torn out minimal.


I’d like to bring up a problem that I’ve been kind of thinking about that’s very hard to handle, which is that how are we going to handle the static page content?

For maximum ease of editing we should for example have the content up on the developer wiki and a script to download and convert that to a form usable by the game. That way anyone on the team can easily correct Thriveopedia content. Needing to remember to run the game content update script would be a tiny annoyance. Bigger problem with this approach is that how are we going to handle translations? I can’t think of a way right now how we could handle that easily. Maybe it would be possible to have some JSON format that’s understandable by weblate to have a separate translation component for the Thriveopedia.

Another idea I have is that we could have the Thriveopedia text directly in the Thrive repo as files. This would make editing the content a bit harder, but I’m much more certain that with this approach we’d have a way to make translations work.

Third option is always the hardest one: writing a bunch of custom software to handle things. In this case I think a custom wiki software that allows people to write translated versions of pages (and as an added bonus, suggest edits to the English text) would work, but would be a ton of work to do (and much harder than any programmer initially thinks).

Any other thoughts on how this could work are very much welcome.


I am personally in favor of importing the text directly into the game for ease of translation. I feel like it wouldn’t be too hard to edit as we presumably won’t have to worry about the same length constraints as tutorial popups and tooltips.

Much of the content such as available upgrades, mp cost, process input and output, compound concentration, etc could all be automatically kept up to date using the game’s own content so that leaves us with only things like real-world descriptions and information or walkthroughs on how to use the feature most effectively.

Edit: This also grants the added bonus of better modding support, allowing modders to more easily create thriveopedia articles on their own content if they so wish.

Well git seems to be pretty difficult to use for a lot of non-programmers.

Anyway that still leaves out the last piece which is what kind of format to use. Technically a JSON file could define the Thriveopedia structure with the content having translation keys that are extracted with the current tools. That way people need Poedit or another local editor when they want to test locally, but otherwise it could be editable on Weblate, though there’d be no syntax verification or anything like that. Also browsing the Thriveopedia outside the game would be basically impossible. I was imagining that if we have the Thriveopedia content on our wiki, someone could use the search there to find a relevant page and link it to someone who really needs to read it in some discussion.

Well I don’t think any of the choices I gave really have any benefit versus each other in regards to modding. If mods want to add their own Thriveopedia entries, we anyway need to add a system the mods can call into to register new pages.

1 Like

Small update of where I’m at now:

I have a Thriveopedia that you can open from the main menu and from the pause menu in-game. When opened from the main menu, all pages related to the current game are hidden. The back, forward, home and hide navigation buttons are all completely functional.

So far, I’ve added placeholder pages for the home page and museum. I’ve added world generation settings data to the current world page, and the evolutionary tree page now displays the first generation properly with functioning species selection. My next task here is to display the updated tree in future generations.

I also added the patch map as a separate page alongside it. Surprisingly easy compared to the rest.

Open for something silly

Now, because you can open the Thriveopedia from the pause menu, and because you can open the pause menu inside the editor…

Yo Dawg