Open msteiger opened 9 years ago
I have a feeling this is what I've been talking about recently. I believe the "isGameplay=true" modules should define a list of world generators they are compatible with and only those should be allowed to be chosen to start a game with, if this gameplay module is chosen.
I think we've had this discussion before. My thoughts:
If you had "gametype" module specify world generators, and you wanted to add a new generator - just create a module with that generator and have the previous "gametype" module as a dependency and set the flag for the new module to be "gametype" as well.
But it isn't a gametype.
Then maybe introduce a "setting" module type that defines "gametype" module and "worldgenerator" type and allow only choosing a "setting" module.
Alternatively, add 2 new flags to "gameplay" module:
And then modules can also define what "gameplay"s they are compatible with, the same for generators.
So, if a "gameplay" module allows only compatible modules, only those that mark as being specifically compatible with that gameplay module and version can be enabled in addition to those that are dependencies of that "gameplay" module. The same applies for world generators.
That will allow strict approach to "gameplay" types defining what is being included, as well as a free-form if someone wishes to create a "Minecraft" experience.
This is getting into "optional" / "supporting" module territory IMHO :-)
Maybe use "soft" systems on either side plus disclaimers. A module can declare a default world it expects, in which case any other choice would provoke a disclaimer / confirmation prompt. Yet then another module could declare itself to override / augment something specific which would either remove or alter the disclaimer.
At no point do we then explicitly block anything or need an action taken elsewhere to make a change in a new module available.
I'm fine with that, as long as the disclaimer is clearly visible to the user and specifies that this might make the game unplayable.
Hmm, what I would like to see is less world generators and more things that introduce additional facets and rasterizer steps. What I had in mind was that rather than all-or-nothing world generators to choose between, a mod would be able to provide additions on top of a base world generator. This would help avoid these sorts of problems.
That aside, I'm happy with whatever solution as long as it doesn't block support for mods.
So kinda like how the Caves module could be enabled with Perlin and expose additional world config options for it. I like that.
Caves is probably a bad example, as it causes trees growing midair and requires changing all the other facets to stop that.
Hehe. But it is an example :-) We just need to make it better :D
Maybe we should have @Josharias tackle a new tutorial episode on clean integration of a new facet attaching to an existing world gen. Doooo eeeeet!
Related topic I wanted to put somewhere: we should flag world preview options better and maybe default to off. TTA currently does technically try to produce a preview but it is empty and takes maybe 20-30 seconds with a stalled game. Then crashes the game if you try to return to the main menu :-)
In that case it may just be easier to flag it as un-previewable until effort is put in to making it.
If better cooperation between world generators / facets is introduced where preview won't be as brittle that could be another option too. Needs hardening in general like we've talked about on occasion.
Currently, a module must be loaded in order to discover all world generators. There is an extension that defines the default world gen, but the others are unknown. As a result, players do not know which world gens. are available and in which modules.
I therefore suggest adding the list of world gens. as a (standard) module extension (probably together with a list of gameplay modes). Thus, required modules for a gameplay or a world generator can be activated automatically.