Implementing New Game Settings

Changing:

SceneManager.Instance.SwitchToScene(MainGameState.MicrobeStage);

to:

var microbeStage = (MicrobeStage)SceneManager.Instance.LoadScene(MainGameState.MicrobeStage).Instance();
microbeStage.CurrentGame = /* reference the setup game here */;
SceneManager.Instance.SwitchToScene(microbeStage);

should do the trick. Though, as this has never been done before there may be a hidden bug in the microbe stage starting it that way.

Edit: also just remembered when reviewing another PR that the free build entering code already does that as that’s how it communicates to the stage that it should be in freebuild mode (though in that case it goes to the microbe editor so the code isn’t exactly the same).

I think I saw that and tried something similar. The issue was adding the WorldGenerationSettings object to CurrentGame in the right way.

GameProperties is not currently setup to accept predefined game settings. I’d change that to something like:

    private GameProperties(WorldGenerationSettings? settings = null)
    {
        settings ??= new WorldGenerationSettings();
        GameWorld = new GameWorld(settings);
        TutorialState = new TutorialState();
    }

Probably have been mentioned before but I think it would be fun if we add placeholder sliders or labels in there, for example sliders like planet mass, planet radius, orbital radius, and habitability percentage indicator etc in the planet tab. These elements would of course be greyed out and only serve as a teaser for the actual planet customization feature.

By the way, where would the options for star generation be placed. I recall that’s also planned way back, would it have its own tab or would it just be bundled in the planet tab?

I think only the planet type should be a simple start option to select from some presets, and that would cause a planet of that type along with a compatible sun to be generated.

3 Likes

Personal thoughts of difficulty levers:

If I were you I’d stay out of the food source classes. Not only are they brittle and hard to test…

Wait, what’s that?

It’s a bird!

It’s a plane!

It’s Hhyyrylainen wishing that someone would implement an auto-evo-exploring tool!

…sorry, got distracted. Anyway, not only that, but those heuristics for fitness are both used to judge the player and the NPC species, so anything that makes it easier or harder for the AI to be big and fierce will do the same thing for the player. You could try to make it more exacting, but that wouldn’t be much of gameplay, it would just pigeonhole the player into a more specific bodyplan.

The mutation code, however, might be more promising. We have some constants that govern how big AI species get, and how fast. This is still naturally selected by the food sources, but I imagine pumping those numbers up or down would make the player feel “out-evolved” to a different degree.

I’d lean more towards changing use of compounds over spawning of compounds. Particularly on hard mode, the game just not giving you phosphate isn’t challenging, it’s punishing. In the difficulty PR I abandonded I focused on the rate of ATP consumption. That forces more pressure on the player, but still gives the same opportunities.

I’d add player HP to your list. Messing with other microbes’ HP runs a risk of serious bullet sponging on hard (some species are already really tough to kill without cheesing a pilus), but Thrive would be very different if a spinning pilus wasn’t a one-hit kill, or if a single toxin shot was.

I’d also take a look at messing with the velocity of toxin particles. Watching other people play, I’ve noticed that the scariest part of most people’s games are when a big linage of toxin-shooters emerge, and the game turns into a bullet hell. Giving players more or less time to react to just that one scenario might do a lot for player perception.

2 Likes

:+1:

I think I get your overall point, but I’d like to highlight that this is kind of a bug:

1 Like

One little thing to bring up regarding difficulty which can be easy to implement and I haven’t really seen: perhaps auto-evo effects and the effects of dying on population could be messed with, with easier difficulties allowing a lot more deaths before extinction and having off-screen auto-evo effects not be as negative. Though that would have to be carefully dealt with - size for example is a very finicky and influential yet heavily tied to realism balancing mechanism.

I’ve spent the last few days putting this feature together, and I now believe I have something ready for people to test and review. See the pull request here:

Aside from general feedback, there are three more things I need:

  • Input on the minimum and maximum values for each difficulty parameter, and input on the values assigned for the easy and hard presets (normal has everything set to the existing values). This might take quite a bit of testing and is also dependent on the spawn system rework, since the cloud density parameter especially will work very differently with that in play.

  • Input on what the random seed should affect. Currently it only changes the randomly generated planet name, but once the procedural patch map is done, it should be trivial to plug it in there too. I’m just wondering if there’s anything else @hhyyrylainen in particular intended to use it for.

  • A placeholder graphic for planet generation. I found an old piece of concept art by @DonGororo and used that for now, but if our graphic artists want something to do, it might be a good idea to make a better teaser.

4 Likes

I can’t really think of anything except the planet for now. In the future I think it should be the seed for all random place generation.


I think the classic patch map layout should be hidden from the general view. I can’t imagine that it will be popular enough to highlight, or is that already the advanced view?

Yeah, that’s the planet tab in the advanced view. Basic view has only difficulty preset, life origin, LAWK and seed.

1 Like

I think a menu that goes one deeper than the advanced menu under the policy of you break things and it’s your fault would be interesting. Lets some more adventurous players customize their game even more, and who knows, someone might find some settings that are more fun than the current ones.

Sure, but I’m going to say that’s beyond the scope of this feature. A good candidate for the future though.

That’s fair.

@Thim Based on your suggestion, I added an osmoregulation cost multiplier for the player cell. I did find some unwanted behaviour though. If I had osmoregulation set to cheaper than normal, I could build a cell that ordinarily wouldn’t survive, and because the osmoregulation adjustment applied to only the player cell itself, other cells of my species would be permanently dying in the environment and I’d get a big osmoregulation penalty in Auto-Evo.

Consequently, I think it’s better to apply the osmoregulation adjustment to all cells of the player’s species. Do you have any thoughts on this?

1 Like

Sorry for the delay; I think that makes a lot more sense. My guess would be that players would feel like the difficulty setting is “cheating” if other microbes of the species are following different rules, and I don’t see why it would be a problem for the other individuals to work the same way.

Since this has just been merged into master, I’ll add a few notes to this thread to conclude things.

After a suggestion from hhyyrylainen, difficulty presets are now defined in JSON, specifically difficulty_presets.json. This should make it easier for anyone to modify or add difficulty presets, especially mod makers. Note that these may involve a change to the maximum and minumum values in Constants.cs though. With the devbuilds and community testing from now until 0.5.9, we should hopefully get some good feedback on the optimal values to choose for the existing difficulties.

Adding extra new game settings shouldn’t be too difficult either. Just follow the approach of the existing values to equip a WorldGenerationSettings object with the right information. The hard part will be accessing and using the setting correctly in the right part of the game code.

I added two settings which are currently invisible: patch map type and Easter eggs. These should both be enabled as part of the code changes for these respective features.

While there is a planet generation screen placeholder, filling out the planet generation options will take a lot more design work. I haven’t worried about that at all for now. It’s possible more GUI scenes will be needed, e.g. if the design ends up something like this.

Finally, now that there’s a functioning LAWK toggle in the game, it’s high time we added thermoplasts. Unfortunately the thermoplast branch has an eye-watering amount of merge conflicts. I do think we need to do something with the LAWK setting in 0.5.9, otherwise it’ll be completely useless this release, so I’ll see what I can do about that. Wish me luck.

4 Likes

May your sanity last.

I think that maybe this restriction should be removed? Only the GUI should probably use the min and max values, unless they truly break the game then I think it’s a good idea to mandate those for the JSON set values as well.

Well, having a preset with values outside the min/max will cause the GUI to display the wrong information, and since the game builds the settings from the GUI when pressing confirm, they would be overwritten anyway. So it’s a bit more work than just removing the JSON validation.

1 Like

I see, that makes sense. I guess we’ll just need to live without this for now as it sounds too complicated to make for the benefit it would provide.