Finishing the microbe stage roadmap

Very exiting roadmap! And from a laymans perspecitve it feels like the features are quiet evenly distrubuted both in terms of how hard they are to implement and how fun they are going to be.

There’s one feature which hasn’t been mentioned and I’m not 100% sure if it’s been decided that we want to include it but I’m going to mention it anyways:
There has been an idea for a difficulty setting which made it so if the players species dies out, the player will take control of the species which is most closely related to it, i.e. the species which has most recently diverged from the player.
Is this still planned as a setting? Imo it would be a very fitting and unique difficulty setting.

That is already on the roadmap wiki page and my idea was not to exclude it, just make it only available in easy mode.

1 Like

I must be illiterate because I’ve read the Release Roadmap for a third time now and I still didn’t find where it was metioned^^
But nevermind, the important thing is that we haven’t forgotten about it.

First bullet point in the “planned” section: Release Roadmap - Thrive Developer Wiki

  • Allow player to play any species occupied patch upon death/reproduction
1 Like

Oh, I did read that… But in that case I misinterpreted what it meant.
Anyways, sorry for wasting your time:)

Forgive me if I am mistaken, but I thought that was limited to the player species.

As in; the player has died in X patch, so now they can choose to play in a prior patch as it has some population in it.

Likewise after reproducing they would be able to play in any patch their species currently resides in.

2 Likes

Well I think whoever wrote that initially wasn’t really clear as it seems to be two separate features.
Now reading it again, I see it says “species occupied” and not “any species” so the wording was unclear. I’ll switch it out to be that the player can switch to any patch their species is in or next to while in the editor.

And put the take over a related species on game over (only in easy mode), to the end of the feature list.

2 Likes

I’ve been thinking about this a lot.

I think we could drastically reduce the number of features we want to implement before shifting the focus off of the Microbe Stage. I know we are constantly thinking about what features to implement next, but we really ought to pat ourselves on the back because we now have quite a decently fleshed out Microbe Stage, something that seemed very unlikely at this project’s inception.

Additionally, I think there is huge value in having more content in the later stages. People are fundamentally more interested in macroscopic biology than they are in microscopic. Macroscopic biology is also better understood scientifically, has more interesting and complex mechanics that govern it, is more audiovisually immersive, and can provide for more interesting gameplay. We can also get better footage from later stage gameplay to use to market the game. It’s hard to sell this game with just microbial footage. Having an interesting macroscopic game can help us grow our team, and some of those devs can then go back and help fill out more Microbe content. Lastly, the beauty of Thrive is that the stages synergize so well. Adding content to later stages will inherently make Microbe more fun because it serves as the buildup to any later stage content.

As such, these are the following features I would say are absolutely necessary, after which we can shift focus to Multicellular:

  • Fix framerate performance. For obvious reasons. It prevents us from adding more entities and adding more CPU/GPU-using features.
  • Fix auto-evo performance. Unless we want load times to the editor to reach 5-10 minutes each time. I think this one is much easier to solve, we just need to reduce the total number of species per world.
  • Upgrades/crossgrades/unlocks. In later stages, we will need an ability for simpler organs/parts to unlock more complex organs (such as gills evolving into lungs). So as a foundation for that, we need to have an upgrade/crossgrade/unlock system implemented which can carry over into the Aware stage.
  • Endosymbiosis. Because becoming a eukaryote is a necessary step to becoming multicellular, we shouldn’t have a placeholder system in place to simulate this (which we do have currently). Additionally, this should help us greatly in balancing the Nucleus by giving us more natural restrictions to place on obtaining it, instead of the crushing Osmoregulation and Mutation Point costs we’ve assigned to it currently to prevent all cells from evolving it.
  • That’s it. I think every other feature would be nice to have implemented before we shift focus, but is not necessary. To clarify, when I say “shift focus”, what I mean is that we move the focus of the majority of our efforts to the Multicellular stage, but we still continue to add content to previous stages if we deem it important enough or if individual devs really want to.

Let me know what you think about this. I think the main goal of such a bare list is that, as I said above, having more content in the macroscopic stage will make Thrive fundamentally more fun, and draw in more players and developers, who we can then use to help fill out earlier-game content. If you’re attending the meeting on Sunday, I think it would be a good chance to discuss this thread and designing our future roadmap.

Ehhh, I’m very wary of thinking like that. I really don’t want this game to fall into the Spore or No Man’s Sky (at launch) trap of having the gameplay essentially be an ocean that is an inch deep - many stages, limited replayability. The microbe stage has reached a point where it can be called fun, but there is limited replayability and an absence of certain gameplay elements that would really make for an engaging microbial game.

Of course we can still develop two stages at once theoretically, but realistically, we just don’t have the manpower to devote resources and focus well across two stages. Moving on to the macroscopic stage too quick would definitely leave many aspects of the microbe stage neglected, and with many bugs still remaining, a lack of some polish, and missing gameplay elements, that wouldn’t make for an engaging experience and would reflect poorly on the quality of future stages (I’m sure many people would interpret a lackluster microbe stage as an indicator that the macroscopic stage would similarly be lackluster). And the microbial stage really serves as the pillar for the rest of the game. Everything we implement here will have effects on the later stages. Especially with emergent software or really any program that is writing itself throughout a long period of time, hastiness can be a very bad thing.

Of course, we need to make sure we have a set point where we force ourselves to stop, assess the stage holistically, and then cut the fluff if we realize we really don’t need additional features. I’m just as itchy for a macroscopic stage (my body plan and germ layer concepts are ways I’ve released that yearning). But we really can’t afford to minimize a stage just because we want to shift focus to another, potentially more captivating stage. It could lead to sloppiness and an uneven gaming experience.

But I do think I know what you’re getting at; we are filling out gameplay wise. Now, the mentality we need is to wrap everything up in a way that creates a very engaging and replayable experience. I’m beginning to create a google doc detailing the most important gameplay elements in Thrive, the state of them as of now, and ways we can improve. I’ll share it soon.

6 Likes

At the very least I would add dynamic compounds and other environmental variables to your list. Things like the great oxygenation events with subsequent glaciations will make the game much more dynamic. The procedural patch map infused the game with a lot of replayability and I think dynamic environmental variables will do the same once more.
Beyond that I see your thoughts about marketability and the positive effect more traction will have on all stages, the microbe stage included.
All in all I agree more with Deus. We have come such a long way with the microbe stage. The last few big remaining features will tie the great things we already have together. It would be a pity if we did this crucial part sloppily.

2 Likes

I’m just about to start working on the gameplay for the macroscopic stage, but my initial guess is that as there’ll be just one graphics node per game entity, the performance will be wildly better in macroscopic than the current microscopic stages.

So fixing the performance in microscopic likely won’t have any relation to later game performance.

Do you mean endosymbiosis lite or the full implementation? I really hope it is not the full implementation as that’s a huge mechanic rework that I kind of don’t want to tackle at all.

I think we should still try to finish a roadmap for the microbe stage. I think that once I’m done with the prototypes, and especially if I can work fulltime starting next year, I can make super quick progress on a lot of the features on the roadmap. I’d say that it’d be possible to finish the entire roadmap (as long as we still get the occasional other people helping out) within a year so a bit optimistically I’d say microbe stage could be complete by the end of 2023 or the first half of 2024.

This is actually something I forgot in my initial post in this thread, we have nearly 500 issues (and well some are new features) in our backlog currently. Some of those are probably pretty important for the enjoyability of the microbe stage and should be put on the roadmap.

This is an excellent point. I’ve myself thought that many issues with the microbe stage players can tolerate if they know there’s more to the game afterwards. But I’ve since realized that the main menu and the microbe stage is what gives players the initial impression, if it’s not good, they won’t play for the two hours needed to get later into the game.

This is one of my biggest annoyances in Thrive, the fact that people post ideas and suggestions to slightly tweak (or entirely rework) already very good systems in the game. These discussions (if they are accepted) just lead to extra work for a tiny bit of extra polish to a small part of the game when we still haven’t made all of the microbe stage yet (and we have even bigger stages to tackle).

5 Likes

Yeah you guys all make good points, and actually now that I think more about it, I change what I think.

I don’t know when would be the best time to shift our PRIMARY focus of what stage we’re working on, that is a good question to think about.

But I DO think that we should create the barebones of future stages as soon as possible. I think hhyyrylainen was bang on the money with this point when he first advocated for it. These are the reasons I think why it would be good to do so as soon as possible:

  • Once we have the foundation of the later stages there, volunteer devs can come in and volunteer to work on those later stages. Devs that otherwise might not have been interested in helping if only the Microbe Stage was available to work on. This is basically free development power. And remember as a volunteer team we are highly dependent on people voluntarily deciding “huh I feel like helping out”, so we want to inspire as many people as we can to do so. Getting in the foundations for future stages lets us tap into more potentially interested developers.
  • As an open-source and volunteer project, we rely a lot on the “energy” of the community. It creates both activity on our platforms, and also feeds us a steady stream of developer applications by giving the game attention. The initial addition of the Multicellular stage had a lot of symbolic power even if functionally not much was added in its first iteration. Yes individuals are rational, and rationally speaking an individual could look and see “oh its a very barebones implementation of the Multicellular stage”. But crowds are not rational, and for many fans and passersby just knowing that Multicellularity was added can be enough to intrigue and energize them, get discussions going on our platforms, get the game shared more often, get word of mouth to share it, etc. And funny enough when people criticize our game online, the most common defence I always see is “Well to be fair they’ve actually started work on their second stage I thought that’d never happen”. Sometimes symbolic acts have a lot of power. And we can use that energy/power to actually grow the team and consequently develop the game faster.
  • Small point but wanted to mention, our game currently doesn’t catch a passerby’s attention very well. Like if younger evolution-obsessed me was scrolling through YouTube and I saw a thumbnail of a Thrive video, I don’t know if I’d watch. I probably wouldn’t recognize what the thumbnail was, since I’d expect an evolution game to feature giant toothed dinosaur like beasts or flying three winged aliens or bioluminescent mushroom forests or what have you. Not some brightly coloured cells swimming through some brightly coloured clouds. 3D macroscopic gameplay will just be leagues better in producing us good thumbnails, screenshots, and footage we can use to catch viewership for our game. This is part of the reason I’ve been working on Audio and Visual ambience so much lately (new ambient tracks, blurred backgrounds, pushing for more compound chunks, etc) since I want to make the game more presentable for when we do outreach. Thrive is really strong at retaining players because its mechanics are so deep and unique, but I think we fall short in attracting them in the first place.
  • Some features apply across Microbe, Multicellular, and Aware. And I’m wondering if it creates us extra work if we implement an iteration of such a system now, and then have to come back and redo it once Multicellular and Aware are more filled out. Like for example, we now have to revisit Auto-Evo to make it take colonies into account, and we will have to revisit it every time a new mechanic is added. Perhaps some systems can be saved for later so that they can be built with all three stages already in mind?

Finally, just to be clear, whenever we do “shift” towards later stages, that doesn’t mean we stop producing the Microbe Stage, or cut any unimplemented Microbe features from our roadmap. We’ll obviously always continue to improve it. We will just focus the majority of our efforts towards later stages and reduce the priority of Microbe Stage features.

3 Likes

Well here it is finally, my “finished” roadmap, which if people agree or at least mostly agree I’ll edit onto the wiki. I worked on this instead of the macroscopic prototype, hopefully it is worth it.

So here’s the roadmap split into release ranges (the ranges work so that 0.6.x releases incrementally add the features listed under that version, and once all are complete we can release 0.7.0).

0.6.x (the combat and part upgrades updates)

0.7.x (the graph updates)

0.8.x (world and auto-evo updates)

0.9.x (finishing things off updates)

1.0.x (the road to multicellular updates)

  • Microbe stage is finished
  • We should have at least the early multicellular no longer marked as a prototype by this time

I went through all of our issues on Github, which is why I picked up quite a bit more than I expected, but I think most of those are needed or should at least be attempted to see if they are easy as they’ll add some needed polish to the stage (I did put in a few easy things in 0.6.x that aren’t really needed just to fill it out a bit). But do feel free to say if some issue is not required to have a perfectly enjoyable microbe stage and we can discuss. Some of the feature lists seem a bit long but there’s quite many bugs in there that don’t really need discussing and can be done easily. I think I overall got the amount of stuff to do to be quite equal (with just 0.6.x being quite bare) even without needing to break the “theme” of the updates too much. 0.9.x has more bugs than new features as I think we’ll really want to polish things then and as always happens, we’ll probably have picked up a ton of more bugs by then which we’ll need time to sort out to not have the bug backlog keep growing.

Once this discussion ends, I’ll update the wiki and put things into a better order where the new features are put between the bugs to make it easier to build milestones for releases (0.6.1, 0.6.2, 0.6.3 etc.).

7 Likes

Some very good points here I agree with, I don’t agree with everything of course but I’ll save this for future reference. My main point with making the prototypes has been to silence the people complaining that we still only have just one stage.

I posted my finished roadmap for microbe stage “completion” a couple of hours ago. I think that’s when we should say microbe stage is done and announce the focus officially moving to multicellular. That’s because as was discussed before we need to have the microbe stage be a polished experience, not try to rush it too soon.

People are free to help me with the prototypes, and some people have helped with the multicellular prototype already, though I kind of at least want to get the basic code structure and refactoring done needed for further stages as I think I have more insight into the overall code structure and what should be done with it. I can’t imagine how much code structure reviewing would be required if someone else started a brand new prototype stage now that isn’t connected to anything. I’ve been bogged down by small but big impact bugs and reviewing PRs for the past weeks, but now I’ll have about a month (I’ll need to save some time at the end to do last minute bug fixing) before the next release to work on macroscopic prototype more.

1 Like

I know I’m in the minority here, but I’m much more interested in a finished Microbe Stage than anything else in the game. In fairness, a lot of that is because I’m doubtful anything else can ever be completed, but I also like the uniqueness of the Microbe Stage compared to other games and the balance it strikes between gameplay and realism. As I’ve said before, the big picture of the Microbe Stage is done - there are many holes to fill, but we know exactly what those are and can narrow in on them, as hyyrylainen has done here.

And I definitely agree with this. I’m concerned about the current frequency of suggestions for big mechanic overhauls when the current game is very solid and we have a definite route to completion.

I don’t have any thoughts on the particulars of the roadmap. Everything looks sensible to me.

My main concern is how we approach it without abandoning the volunteer nature of the project, which is very valuable to me (and I would assume many others). I’ve picked the list of features I’ve worked on for 0.5.9 and 0.5.10 through a combination of factors: what’s appropriate for my coding skill level, what sounds fun, and what I want to make sure isn’t missed on the road to a complete stage. I want some assurance that other people can do the same in future without feeling like they’re forced into picking from a set list. That sounds risky for a volunteer project.

Related: what happens if some features are completed out of sync? I’m still hoping to get the thermosynthesis revamp done for 0.5.10, yet you’ve listed that as part of 0.9.x. For one or two features it’s fine, but there comes a point where an entire version plan becomes redundant. If we get to 0.7.0 and find planet generation, radiotrophs and all the features you’ve listed for 0.8.x have already been completed, what do we do?

I interpret the roadmap less as an instruction manual telling us when to do stuff and more as a guide letting us know when to say enough is enough. Its purpose isn’t telling us when to do what (unless people want it to of course), but instead setting a clear cutoff point so that we don’t go down a rabbit hole of trying to improve a good mechanic, hence derailing us from completing a minimally viable cell stage. In other words, it gives us a clue of when to shift focus to another feature/version of Thrive so we don’t unnecessarily focus on a specific feature when there are other features to implement.

So for example, thermosynthesis being listed at .9 is saying “we’ll consider .9 done if thermosynthesis is done by then”. If it’s completed already by .9, then great news! It’s one less thing we have to work on.

Try not to get too focused on where everything is in the roadmap. It essentially is just meant to let us know when enough is enough, not necessarily when to do something.

5 Likes

I think that view only adds more reason for people to even doubt Thrive more than just a hardcore cell simulator instead of the grand life simulator it advertises. Yes, later stages might not ever be totally complete but by finishing all or most of the later stages prototypes, we can at least have a minimum justification to include the rest of the stages in the game’s overall concept, even if those prototypes stayed barebones and gathering dust for a long time.

Also roadmap looks solid. It sets a clear path of what to do than just being unfocused as some may say every release completion and planning the next one.

3 Likes

I don’t think we really need to change up how things work.
For the past few release planning cycles I’ve just let people say what they want to work on, with putting just a minimal amount of issues picked by me into the milestones. As a result the last releases have been mostly comprised of issues people just picked themselves.

With this roadmap I’d just fill in the milestones with stuff picked from the roadmap, and we’d be back to the older style where we planned to try to focus on some issues in a milestone, but they didn’t really get worked on any more than random issues. So I’ll just recycle the leftover issues to the next release over and over until they are done and we can call a roadmap stage complete. I don’t see this as limiting people’s freedom to work on what they want at all, it’ll mostly be a gentle nudge towards picking issues from the roadmap.

I’ll let features come in as people finish them like currently. As things get completed they’ll be removed from the roadmap (as long as people remember to do that, though when building the milestones, I’ll probably remember at that point that something got done). If some roadmap stage is completed entirely before we get there, we’ll just skip version numbers. After all the main point of the roadmap is to allow us to pick release numbers based on how close we are to finishing the microbe stage.

6 Likes

The roadmap is now on the wiki. Release Roadmap - Thrive Developer Wiki

4 Likes

I don’t want to constantly approve adding stuff to the roadmap, but I think there’s 2 usability things we really need (and people gave me thumbs up on Discord so I’ll add these immediately):

Turns out that the second issue was already on the roadmap.

1 Like