Here I’d like to discus ways to implement the auto-evo exploring tool. Before I can actually set out coding it, I have several questions.
Auto-evo is evolving. Do I need to code it so that later changes will not break this function? Or does anyone later on who is changing auto-evo need to adjust this exploring tool?
Where should we put it? Only an external tool, or a tool that serves as a part of the microbe free builder (so that players can ‘play’ with what have evolved)?
To what extent can players modify auto-evo? Only making entire runs? Or players can decide which species to run on? Or they can even decide how many tries are made per species?
Can players modify auto-evo parameters?
Can players modify the environment?
Can players add external effect?
Can players modify the other species?
And what’s more, if the tool needs components (such as microbe editor), to what extent can I modify that to adapt it to the exploring tool?
I’m happy to see interest in this; I think it will help a lot!
For a first PR, I would advise focus on a view-only explorer. No editing, no environmental factors, just the basic features:
Player can see what species exist in a patch
Player can select a species to see basic details about that species:
Preview picture like in the multicell editor
Organelles in the species
Population in the species
Value of behavior sliders of the species
Player can see what species evolved from which other species, preferably in a visual format.
Keeping it simple and end-results focused also gets around future-proofing issues: the explorer doesn’t care HOW auto evo works, it just looks at the species that appear out the other end. Since making a list of species is the primary job of auto-evo, we can trust that any functioning algorithm for auto-evo will still be producing this result, no matter how much might change under the hood.
In short a new GUI page accessible from the main menu where you can setup an auto-evo simulation and step it forward observing the results, should be made.
A key feature for developing auto-evo with this tool would be to have a mode to run like 100 auto-evo runs in a row and collect some overall statistics. I was thinking that an option like “auto reset after 50 generations” and a toggle button to “run generations” would get the first part done.
An optional nice to have feature would be to have a button to enter the game in freebuild mode in the world that was generated by the tool to explore around.
The tool should use the auto-evo results and existing result display scenes (extracted as separate components), to reduce the amount the auto-evo exploring tool breaks.
Once the tool is done, it’d actually be the primary way changes to auto-evo are done and checked, so anyone working on auto-evo needs to also make sure the tool doesn’t break. This means that the code quality and maintainability needs to be high for this feature.
Accessible as a separate tool in the tools menu in the game.
I think that’s too complicated.
These are also some really specific things that aren’t the primary goal of the tool. Instead what I think should be the MVP is a button to run auto-evo 100 times (up to like generation 20) and collect averages and other statistics of the run. That would be the primary thing to look at when auto-evo changes are done. Stopping midway through a run to tweak and look at things before generation 20 is not the most useful thing for us as developers. Though, tweaking the auto-evo parameters in the tool would be very useful in getting feedback from non-programmers about what might be good default values.
Changes that decouple or generalize existing logic are good. If instead too much coupling is added between the tool and the normal scenes, I think then the generalizing the approach is needed.
In config tab we list all parameters and the run-auto-evo options. In report tab we list timeline & results & statistics. In viewer tab we can inspect current auto-evo species.
However, I am not sure how patch map can be adapted to this. And because the microbe editor components use absolute positions (relative to the left-top corner), I have difficulty adapting them to this tab.
I think those components could be adjusted to not have the position in them, instead the scenes using those components could then have the right positions for them set that way.
Where would you put the buttons for running / stepping the simulation?
It’s just two components, or am I overlooking something? Just a custom rich text label to show the auto-evo result text, and then extracting the patch map and the right side bar from the map tab of the editor (the map tab of the editor is already a separate scene).
I guess the report tab would also need extracting the entire contents of it to a separate scene then. However I don’t see the timeline tab as very useful because it doesn’t have all of the important things in it anyway, and also it is subject to some extra bugs, so it can’t be even fully relied on. So I don’t think it’s that important and maybe the auto-evo tool would actually be better off without it. Something like a history view of being able to go back and browse through the auto-evo results for each generation would be a much more accurate way to view the history.
I have a few questions regarding the auto evo code.
In EditorBase.cs: EditorBase.ApplyAutoEvoResults() you wrote several lines to deal with extinction. Why don’t you put that in the AutoEvoRun class since you can access CurrentGame.GameWorld with Parameters.World? What’s your concern?
In ApplyExternalEffects() you called results.ApplyResults, so what’s the use of AutoEvoRun.ApplyResults()?
AllowNoMutation and AllowNoMigration is default true. Should that be actually AllowMutation and AllowMigration?
I can’t fully remember, but I think it has to do with external effects. This is because the external effects are not guaranteed to all have happened before the player enters the editor. I think that’s why I made applying the results a two step process, but you are right that now it probably makes sense to put the extinction logic in the results, so that the editor and the tool can both call it to not have code duplication.
It’s probably useful if there are no external effects… I just probably left it as public after adding the external effects, as I thought someone might want to call it from outside the class.
Well negatively named booleans are a bit of a code smell, but I haven’t bothered changing them. I initially wrote them that way because basically always you want to have them in the default position, I just added the variables because it was very easy to do son.
I see, you can definitely see it that way. The variable is actually “allow mutation step to pick to not do a mutation if there is no good mutation” Basically if you set the AllowNoMutation to false, then the mutation trying auto-evo step will be forced to pick a mutation, even if all of them were worse than not mutating the species at all. I think the variable name is clear(er) as a parameter to that step, but I can see why it would be confusing when it is at the top level. Perhaps a better name would be “AllowSpeciesToNotMutate”
Just a general rule of thumb, please use easier to read and smaller fonts for texts inside panels. For example Lato font with about the size of 16px.
Also how do the report tab works, I assume the left-side panel would list selectable items for previous runs and the bigger right-side panel would show all the details?
That doesn’t seem that good to me, could we go with “AllowSpeciesToNotMutate” that isn’t too long yet, but would in my opinion capture quite well what it does? Of course in the GUI it could have a much longer text explanation as the checkbox label.
