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.
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.
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.
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 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.
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.
I’d like to have a go at filling the in-game Thriveopedia with content from the wiki. What does everyone think of this approach to the architecture?
Create a section in the wiki for pages that will appear in the Thriveopedia.
Write a script (based on the credits updating script) that takes content from pages in this section and populates:
A JSON file with an array of objects, each representing one page.
Content within each page object in the JSON file, including an array of page sections. These sections would have a type (paragraph/heading/etc.) and an auto-generated translation key of the format PAGENAME_SECTIONNUMBER.
The English translations of these keys in en.po based on the actual text in the wiki. The script would have to run the localisation update before this step for the newly populated keys to appear.
Have the Thriveopedia code create an in-game page for each object in the pages array. These would of course use pre-defined heading/paragraph/etc. scenes as appropriate. I created a proof of concept for just this step and it worked well.
I believe this should allow translations to work, since as far as the translation process is concerned, the Thriveopedia content works exactly the same as that in any existing JSON file. All the section keys will be available to edit on Weblate as normal. We don’t need to maintain multiple languages on the wiki.
This script would have to be run manually to update the code, e.g. before each release. While this means we won’t have instant updates, it does prevent the code falling over in the case of malformed wiki pages. That’s a possible threat if we instead set the game up to gather wiki data at runtime.
One question I do have is what to do about images. Would images embedded in the wiki page have to be downloaded to the game’s asset files as part of the script too? This might lead to asset duplication in the case of organelle icons for example, so maybe there’s a way around that.
Yeah, this should work and with basically the only downside which you identified: the community translators will only get updated pages to translate about once per release. And I imagine we’ll update the in-game wiki pages in time for the release candidates, so community translators would have just a week to translate any new wiki pages. Which again is not optimal, but I think we can live with this especially considering that there’s only 2 fully finished translations currently.
I think it makes more sense to download the embedded images on the wiki to the game content rather than having a system where the player’s computers would download the images on-demand (and cache them on disk). We might need to rethink this if we have hundreds of megabytes of wiki images (which we are ways, ways off).
I just tested with the disturbance file and it is possible to write content on the image pages (for example: File:Disturbance by sciocont-d57qa0b.jpg - Thrive Developer Wiki). So the wiki content extractor could use some special text on the image pages that would have an alternative file path to load the image from (if it is one that already exists in the game).
Edit: we also need some way to embed the bbcode needed for icons or keybinding references on the web version to make this work nicely. This could be as simple as having some html content that a custom style on the wiki can hide, or maybe some kind of custom hidden content tag is needed (maybe a plugin for mediawiki)?
I think this approach is a case of overengineering. What is the goal for linking the Thriveopedia to the wiki? If the objective is to more easily lift-and-shift a large amount of text from the wiki pages without doing extra work, I think that you will find most of the existing wiki pages are out-of-date, based around future stages, or both. If the goal is parity between the wiki and the Thriveopedia, I think you’ll find that most wiki pages are written with the development team as the intended audience instead of the players.
Can you think of some pages from the wiki today that you would want ported? Or is the idea to maintain seperate wiki pages with the primary purpose of supplying the Thriveopedia?
Well the point is that it’s much more likely for team members to write good wiki pages rather than go for example on weblate and modify one page at a time, with the caveat of not being able to add images or even easily follow links to other pages. So this is a matter of having an extremely easy way for non-programmer team members to be able to write, edit, and check content outside the game for the in-game wiki.
Ok, so it sounds like the goal here is to just use the wiki as an easier way for contributors to modify things than weblate or making PRs against the repository, then use this new script to port the information over into the repository. That makes more sense to me, although I still wonder if this ETL process will end up being to maintain as the wiki and repo update APIs and security protocols.
The wiki uses MediaWiki software and we have full access to change any settings etc. I got the picture that this would be just a manual script to run locally and then commit the changes, similarly to how the localization update script works. Instead of being some automatic service that tries to keep things in sync.
