The Thriveopedia

Alright, I‘ll try to put it down there in my next mock-up. One concern I have about this is that it may clash with the other UI elements which will remain on the screen (presumably?) such as the main menu button, pause button etc. I wouldn‘t want to make a second gap there soley for the close button, and on the top there already is a gap for the tabs etc. But I‘ll try to find a way to bring it all together!

I think the Thriveopedia is such a big and important thing that it should take up the entire screen whenever it is opened.

Though I guess an additional feature to open it up in a popup window would be pretty handy.

I agree that it should take over virtually the whole screen, as indicated in my mock-ups. But note that while the Sporeopedia does the same in Spore, the GUI elements at the very bottom stay the same wether you‘re in the Sporeopedia, in environemtal gameplay or in the editor.

I think this is a very smart choice as it makes it so opening the Sporeopedia doesn‘t feel like it‘s taking you ‚out‘ of gameplay. It‘s essentially part of the smae whole experience as gameplay, it’s just an informative overlay.
It‘s for the same reason that you still see a bit of the editor background at the top and at the bottom when you‘re in the patch report.

That’s different. We are trying to put the Thriveopedia in our pause menu. Also designing the Thriveopedia to fit the overall GUI of 8 stages is going to be a nightmare and heavily constrict the designs that can be used elsewhere.

I see… I always assumed that we‘d want to have it be accessible with one click from gameplay. But the thing about the 8 stages is a very compelling argument.

Could we make it accessible via a keyboard buttton in that case? That would totally make up for having it accessible via an on-screen button.

If this is done:

that would be possible.

1 Like

Given that this PR adds a GitHub button among all the social links, we’ll end up with duplicate links to GitHub on the main menu. I think it therefore makes sense to replace the ‘View Source Code’ button with a ‘Thriveopedia’ button, making it more prominent than if it were contained in a sub-menu. Please let me know if there are objections.

1 Like

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


Updating this thread now the initial Thriveopedia work is all but done. Here are some screenshots of it in action.

Open for screenshots


I think now that we have the Thriveopedia in the game, we should unify the help section into it. I think creating a help pages main category with one help page for each stage and each editor would be the best. Then the help button in the pause menu and bottom left could open directly the relevant Thriveopedia page. The editor help pages could then especially link to the stage’s help and vice-versa to make things easily discoverable to the player. Thoughts?

Also I think an issue should be opened about adding a search bar to the Thriveopedia for easily finding pages relevant to keywords or their content.

And finally the new help pages should explain osmoregulation in the microbe editor what it is.


Could have posted this in existing thread about Thrivopedia… we’ve already got quite a few scattered around:

Everything else sounds good to me.

1 Like

That’s a good idea, moved the posts.
I mainly just quickly opened a new thread as I didn’t just want to make the executive decision of just opening a couple of new Github issues about reworking those things. I probably should have thought things for a little bit longer and realized that it would be more natural to post in the Thriveopedia thread.

1 Like

Seeing as no one objected I opened issues about these changes: