Tweaking Module categories

[Cervator]

Goal: Core Project - new engine feature (or gestalt-module - Immortius ?)
Brief description: Add a category field to module.txt and make the New Game / Modules screen decorate them accordingly (and allow only selection of one "Gameplay Module")
Meant to be useful for: Distinguishing modules better from each other plus allow treatment of them to be more customized

Synopsis: Right now modules are all treated the same and only dependencies in module.txt really do anything unusual. Along with world generation options becoming available in the Create New Game screen I suppose, but that I believe just comes from scanning enabled modules. There's no obvious way to select your gameplay like in the days of old when we had a game type / mode drop-down, you have to just know that "Throughout the Ages" offers unique gameplay.

I suggest we add a category field to module.txt and use that to decorate modules on the "Modules" screen. We could also present modules defined as "Gameplay" separately, as a sort of game type / mode selector replacement. Categories could include:

• Library module - no standalone purpose, purely utility for other modules. Example: BlockNetwork, or even the ScalaLib Skaldarnar just prepared ?
• Asset module - plain art / passive content module, possibly with basic block/model definitions. Example: LASR, Minerals, Soils
• World module - adds world gen feature (maybe specifically a "plugin" for the world gen process?). Example: AnotherWorld (I think - this category might be tricky / not needed)
• Augmentation module - some sort of plug and play content that can be enabled and seen/played, but doesn't force particular gameplay. Could work in combination with a gameplay module. Example: NightTerrors
• Gameplay module - defines a game type/mode that may depend on a large number of modules and force a particular style of play. Unlikely to work well with other gameplay modules. Example: WoodAndStone, LightAndShadow
• Special module - Core, Sample, Malicious, maybe the module discussed previously to save user generated content in? Or nah ?

Along with introducing these categories we might get more strict about what you can put in a single releasable module (encourage making them topic specific, use multiple if needed) - increases reusability and helps avoid conflicts

The "Gameplay" module might be the most important entry as this would define a game type / mode and do away with the confusing type/mode thing I can't ever seem to get consistent with anyway. On the current" Modules" screen we could simply add a second list box and purely put Gameplay modules in there. You can select one of those and the dependencies will auto-select as usual but you can only select one gameplay module - with the possible exception of one gameplay module being a dependency of a fancier gameplay module, in which case it would get activated as a module but not in the gameplay box

"Augmentation" I just came up with as a general term for content module with stuff in it you should be able to use pretty easily in multiple settings. Wrote up the NightTerrors design as an example - it isn't a gameplay module as it doesn't force a particular style of playing, although it does encourage it (survival). You could enable NightTerrors in addition to L&S or W&S or even alone and it would work in a sensible fashion in any case (make nights more dangerous)

The main module listing would gain some icons and/or colors to better indicate what's what. If something is selected as a dependency of something else the selection color should differ from a choice you've made manually. Library modules should be partially faded out but selectable for testing (no point in ever enabling them solo for actual playing)

The category field would also allow for better listing elsewhere like on a module tracker GitHub page, whole module site, or a module preparation thing in the Launcher.

Thoughts?

 

[Cervator]

Small addition: Got to thinking about a future where the user no longer selects modules directly. Gameplay modules clearly would be available, and might be compared to MC "mod packs", while Augmentation modules could be comparable with normal "mods" and thus should be available too. The others might be left out in favor of working them exclusively as dependencies of gameplay or augmentation modules, or maybe it should be allowable for a module to be in multiple categories and/or have a flag indicating whether they can be toggled solo. Not quite sure there.

Might be best to follow the practice to split out something like Soils into an Asset module not normally available, since none of the added blocks would be obvious added content to a new/typical user without console access, along with an Augmentation that actually puts them to use at some point (like register them for placement in layers during standard world gen). That way you can reuse the assets elsewhere without being weighed down by whatever initial integration was attached. Admittedly Soils (Asset) + FancySoilsWorldGen (World gen module putting them to use) might be enough without an Augmentation to enable them. Perhaps World modules should also be available individually for the user to enable.

For testing there could simply be an advanced mode toggle that allows modders to enable any module.

 

[msteiger]

Are categories exclusive? In other words, can a module be a "GamePlay" module and a "World" module at the same time?

Maybe we can think of other classifications, too. How about "Fantasy", "Medieval" and "Post-Apocalyptic" tags?

Either way - afaik these extra properties can be added to the module.info and also be supported in the Module Index/Tracker infrastructure..

 

[Cervator]

I'm not sure about module type exclusivity - I'd say yes, they are, although I expect some gameplay/augmentation modules might retain embedded content matching the other types if the author doesn't want to bother splitting them out into more reusable modules.

Adding tags for module descriptions is a great idea imho

 

[Josharias]

Here is a thought I had on how to implement this for a Version 1. https://github.com/MovingBlocks/Terasology/pull/1199. It does not do anything too fancy with categorization or module compatibility, but it does make "gameplay" modules to be clearly visible. It also adds "isGameplay" and "defaultWorldGenerator" to the module.txt.


After adding isGameplay and defaultWorldGenerator to a handful of mods, you end up with something that looks like this:

Notice that "perlin" is the selected world generator as it is specified in the module.txt like this:

{
   ...
    "defaultWorldGenerator" : "Core:FacetedPerlin"
}

After selecting the Cities module, it also autoselects its default generator:

And after clicking on the modules button, it brings you to the normal modules screen with that module selected along with its dependencies:

Now for some tricks, lets say you want to enable the BlockPicker. And then afterwards, you change your mind and switch back to the Core gameplay module. You module selection still persists as the UI only deselects the particular gameplay module.

The world generator drop down displays all generators from user selected modules *and* their dependencies.

 

[Cervator]

I like it. Any reason to not merge it as-is?

I ran the branch but without having tweaked any module.txts I only had the Core gameplay option. Amusingly (bug report?) I was able to deselect the Core module, retain its entry in gameplay as well as world, start a game, not crash, get open void world

Screenshots show it well enough IMHO. Ship it!

 

[Josharias]

Ill look into updating the selected gameplay module after editing the modules screen manually. Hopefully will prevent running the game with no modules.

 

[msteiger]

I agree - that's cool stuff @Josharias!

Would it make sense to even go one step further and move the World Selection Screen to the "Config" subscreen?
We would have a set of configurable gameplay modules and some of them allow changing the World Generator, while some do not.
For example, L&S might restrict the WorldGen to symmetric ones (to keep the gameplay fair), but "Open Sandbox Gameplay" allows every WorldGen.

EDIT: I can look over the PR code tomorrow if that's soon enough

 

[Josharias]

Re: move the World Selection screen to the Config subscreen

I would be worried about the balance between:
- trying to push the player into a known good configuration (by giving them less dials on the create game screen)
- showing the player that there easy ways to change up your world generation.

Relocating the world selection would essentially hide the different options from the player. If you didn't explore and click through each button, I do not think timid players would ever find the different world generators.

However, doing more work on the module compatibility/categorization front would probably help a lot to eliminate bad options for world config by not allowing players to enable mods that are incompatible with each other. This would then help keep incompatible world generators out of the list because their associated module could not be enabled.

 

[Skaldarnar]

Is it possible to categorize the module list with the current state of the UI (does this actually make sense or would you rather employ several lists?)?

I'm still thinking of a gameplay creation screen where the user can select different modules (similar to the current selection) from a categorized view to assemble a new Gameplay module.

In general I like the idea of a Gameplay Settings buttons which hides all detailed configurations for a gameplay module (including world gen and other details). If the overall world creation interface is cleared up it will be easy to see the settings button, anyways.

 

[Josharias]

Custom gameplay compilations sounds like a neat idea!

I wonder if the module categorization topic just needs some mockup wireframe images to help get some developer action.

Would one categorize in a tree view like this lovely mspaint drawing? Other ideas?

Oops, forgot to put plus/minus signs for expansion. Meh, you get the point.

 

[Skaldarnar]

A tree-like hierarchy for module selection might work well. My initial thought was to just add sub lists for the categories introduced above. I attached a quick sketch of how I imagined the module creation window.

I actually like the idea of dealing with module compatibility at this point (as you did with the separation of in-/compatible modules).

 

[Mike Kienenberger]

A tree-like hierarchy for module selection might work well. My initial thought was to just add sub lists for the categories introduced above. I attached a quick sketch of how I imagined the module creation window.

View attachment 1520

I actually like the idea of dealing with module compatibility at this point (as you did with the separation of in-/compatible modules).

I wonder if we should be more generic and have lists of tags for modules.

For example, "sci-fi", "artwork", "ai system", "soil blocks", "world generator".

This might be in-place-of or in-addition-to what has already been suggested.

 

[Cervator]

@Skaldarnar used a fancy font. @Skaldarnar wins!

On a more serious note: good ideas. I also like "tagging" in general, for genre / sub-type, maybe the top level categories can be hard-set to support more exact structural/decorative items?

Unsure how easy it would be to define compatibility though?

 

[Skaldarnar]

+1 for supporting both, general structural categories (as mentioned in first post of this thread) and additional tags (such as setting or characterization).

This can be very useful for implementing a good search box for modules, by the way.

 

[Skaldarnar]

As the discussion recently popped up on IRC again I wanted to leave a note here as well.

For some modules the user might want to select a precedence order by hand, e.g. the loading order of different assets modules (i.e. texture packs). Thus, we could stack texture packs (or other asset modules) and still control which ones are more specific - and should be loaded last.

Restricting this to asset modules sounds right to me, although I'ld like to hear @Immortius opinion on this. Should this be supported in general, is it absolute non-sense or could it be applied to specific module categories (e.g. assets). Do the possible dependencies for asset modules need to be restricted further in order to still allow correct dependency handling/loading.

 

[Immortius]

If you look at something like how mods work for Skyrim, then order is crucial, but also very tricky for a user to select correctly in the general case. The Skyrim modding scene ended up with multiple mode managing apps to deal with ordering and conflicts. It would be nice to avoid exposing ordering decisions to users, but perhaps unavoidable.

When it comes to ordering, dependency-based ordering must come first. After that we have a choice of:

• Detecting and preventing conflicting selections (modules that provide/override the same asset that are not part of the same dependency tree - it is ok of both A and B override an asset, if B depends on A. This indicates B intends to override A). At the very least we should disallow modules to define the same class including package name. This isn't ideal if you have a general texture pack and a more specific texture pack though.
  
• Allowing the user to determine precedence between conflicting modules.
• Allowing modules to provide some non-dependency precedence - suggested order relative to other modules. This wouldn't be sufficient for all cases since it requires a module to know about all other modules, but could at least reduce cases where user action is needed.

Conflict detection needs to occur after version resolution, or as part of version resolution, since different versions of a module may override different assets. So precedence selection should be a second screen (perhaps an advanced tab).

 

[Marcin Sciesinski]

Ideally, non-gameMode mods should not be overwriting anything. They should just provide systems and prefabs for anything new they introduce. It should be up to gameMode developer to define any overrides and integrating all mods to work together.

 

[Skaldarnar]

Ideally, non-gamemode mods should not be overwriting anything. They should just provide systems and prefabs for anything new they introduce. It should be up to gamemode developer to define any overrides and integrating all mods to work together.

Actually, I think texture packs are the best example for _overwriting modules_ that are not game modes. I agree with @Immortius that the dependency-based ordering is most important, but there are definitely use cases where non-game modes override assets.
Just to name a few: texture packs, balancing modules (make mobs stronger/weaker, ...), more extreme effects (e.g. weather, ...), and so on. The main game experience still is determined by the game mode, but small changes (especially for single player mode) are most likely desired by users.

 

[Marcin Sciesinski]

Well, that's only true if players add additional modules on top of the prepared game mode. I wouldn't worry too much about this case, as it will be rare (lets hope) and also - you will never be able to get it right, which is why game modes were introduced as that's what the game mode developer does - integrates all the modules in a correct manner.