It’s a good thing to reflect over our roadmap, and I agree and disagree with some things here. This is a bit of rambly reply, but this is a very important topic, and it’s good to be open.
I think the important thing to keep in mind is that Thrive 1.0 more generally indicates the completion of the Microbe Stage. I personally think that the current roadmap is generally pretty adequate at giving us a solid cut-off line for calling the Microbe Stage “complete”.
Keep in mind that, atleast in my mind, a complete stage does mean “this part of the game is done and set in stone, and everything that could possibly be represented is represented in Thrive.” I don’t think such a thing is possible, given the scope and open-source nature of the project. Instead, by saying the Microbe Stage is “complete”, we are saying that the Microbe Stage:
- Adequately represents the evolutionary pressures microbial life faces.
- Offers robust gameplay which is sufficiently engaging and replayable, in a concise but unbloated manner.
- And is presented and polished to a sufficient level, with no unacceptable graphical issues or bugs.
None of this is exclusive of additional features; it’s just that the roadmap is a very important tool for us to fight excessive scope creep, so I’m wary of altering it to be dependent on two features which require a lot of effort and could have uncertain timelines behind them. There will always be something to pick at, something we can improve, and some more work to be done. We just need to be able to organize our efforts into manageable and trackable milestones. And besides, I think the sentence that “Thrive has completed its first stage” will have an immense effect of dissolving a lot of the previous baggage the project has gotten; reaching 1.0 doesn’t mean too much outside of that context in my opinon.
I do think we should have a period of reflection as our road map winds down assessing whether or not Thrive has notable gaps in its gameplay experience. And make no mistake, I also occasionally advocate for adding a new mechanic, or reworking existing ones, because I anticipate future reflection to see certain gaps. I primarily advocate for slightly tweaking the gameplay of certain metabolic strategies, or surface area to volume ratios (I more often nag our programmers to add the latter as part of our road map). But I do so because I believe the value of implementing those features significantly strengthens our Microbe Stage, and is worth the additional work.
So do know that I am not necessarily anti-amending the road map; I just think that its primary function is to limit scope creep, and that scope creep is the #1 enemy in Thrive’s development (besides manpower of course). In a game representing a topic this extensive, we need to place immense focus on defining stopping points - because if we let ourselves, we could very easily lose momentum forward and hyper-focus on a mechanic which, in the future, proves to be a rather insignificant part of a Thrivian playthrough as a whole. Knowing that, I’d rather be more strict and restrictive when it comes to adding things to the roadmap.
If nothing else, I ask that I have three and only three genie wishes from hyyrylainen for features to add to the Microbe Stage in 0.9, no questions asked. /s
Also, though I don’t think we should bind 1.0 to them, I do agree with you when you say that the planet generator and the macroscopic creature editor are the features which draw the most attention to Thrive, and which currently represent our largest hurdles (procedural animation too, though that is a part of the editor; auto-evo too, though we’ve been making very good progress there). We are lucky to have you working on the planet generator with a clear vision, great expertise, and high energy. If we are able to find another volunteer capable of devoting similar attention to the other “big features”, Thrive would be in impeccable shape.
Having well fleshed out renditions of these features would be the most powerful marketing tools for our project. And even besides that point, making progress on these two features now, at a moment in time where Thrive has a decent web presence and its highest rate of development, would help make future development a lot more stable and guaranteed, even if funding and manpower falls off a cliff. I don’t know much about software management, but I anticipate that quality-checking and implementing these features would be easier on a team with atleast one full-time programmer on it - even if said programmer is not the one working on the planet generator, 3D editor, or procedural animation, having them as the root of the programming team offers a stability and base which makes every other feature better and more optimized.
It doesn’t even have to be actual programming work on these “mega-feature” in my opinion this far out to the actual stages where they are used: even having well-defined concepts surrounding the feature will atleast help volunteers think “oh okay, this whole thing is overwhelming but I atleast can do this part”, which is a very powerful tool over a long enough time horizon. TJWhale, the old game design team lead before Buckly, had a very powerful post a while ago arguing for implementing an engineering mindset behind the auto-evo simulation which I think played a very important role in ending up where we are now, with GameDungeon and Thim’s very impressive miches presenting a really unique and engaging evolution mechanic to expand upon (maybe we should contact him to share how far his project has gone).
I have previously tried to devote some attention to macroscopic editor mechanics, under the theory that defining one aspect of the macroscopic editor, then another, then another, then another, even this far out, will help volunteers now and in the future manage work on the feature better (Macroscopic Editor, Progression, and Principles - #30 by Deus). For example, understanding how our “torso” would work could help someone get started on that, which can then make work on the limbs easier, etc. I will say that there were some concerns about us not fully understanding exactly what is required of the macroscopic editor until we get to a point of needing the mechanic.
So - again - though I don’t think these “mega-features” should be binded to 1.0 for reasons I listed above, I do agree with you when you say that these features are significant to the success and appeal of Thrive. I don’t have much of a solution regarding how we can begin organizing around these features now, and don’t know if the current moment is the best time to do so. But I will say that if anyone thinks they would want to create prototypes for the editor, I’d be very willing to lend a game design perspective there to help you organize the project.