Modules, systems, and content

[Josharias]

With the bits of refactoring work done recently (and my apparent obsession with reorganizing), I think a discussion would be helpful about the where the Terasology architects want the lines drawn between content and supporting systems. There is information on the forum describing Terasology as 2 parts: an engine that has "rendering, audio and voxel world support", and modules that provide game play.

What is the vision for how the modules of a completed game type will be organized?

 

[Josharias]

There has been talk about "game types" which, as far as I have understood, is a collection of modules that could be selected by the player as a starting point of a Terasology game. However, I would imagine that there would be more to it than just preselecting modules to enable. A game type could specify win conditions, a set of rules, or a set of mechanics that will exist in a world (I am going to call these core mechanics). Then, content that is compatible could be added to the game type at the user's discretion which would create usable game play.
How would the engine determine what content is compatible with the selected game type?

The core mechanics of a game type would have to be unique, otherwise there would be systems added that compete for the same mechanic (think multiple water simulators, multiple vegetation systems, multiple hunger systems). I suppose one could make an argument to be allowed to add similar mechanics as long as they dont interfere with one another. A good case for that would be 2 different vegetation systems. As long as they did not affect the same blocks of vegetation, all would be well and they could have their own growth logic.
How could one only allow one instance of a particular core mechanic and allow modules to be smart about not intruding on another module's stuff? Would it come down to just not enabling 2 competing modules? What happens when a dependency gets enabled that intrudes on the game type's core mechanics?

Content would be layered on top of or beside mechanics. The tricky part would be to find that line that separates generic systems from their block content. In some cases you would want to package together blocks and systems in order to create a nice distributable. But in other cases, you would want to create separate distributables so that a modder is not locked in to a particular organization of blocks.
How far does one take separating content and systems? Forcing a "systems" module and a "content" module for would be silly for small projects. But then on the other side, it would feel messy to build on top of another module's systems without stepping on the pre-existing blocks.

 

[Immortius]

Firstly - all gameplay can be done through systems. For a deathmatch game type, you would have a system or systems that assign teams to joining players, award ppints on kills and check victory conditions. So there is nothing special needed for that.

A gametype itself then does three things:
* Provides information for a menu item
* Activate and deactivate systems
* Lives in a module, so that module and its dependencies become selected.

A gametype should be usable on its own. Adding, removing, or changing content can be done by applying mods on top of the game type. Alternatively another gametype can use the same systems with different content, if the modules are structured nicely - logic modules, content modules and then gametype modules to draw them together.

Mod modules then need to be able to have both dependencies, exclusions, and requirements. Dependencies are modules they need and automatically add, requirements are modules they require a game to already have, and exclusions are modules they are not compatible with - although that list could never be complete.

And yes, at some point we have to expect players to use some smarts when selecting mods. Other than that we just do our best to allow things to work together. Two crafting systems could live side by side for instance. Events help here.

This is what I am envisioning anyway.

 

[Cervator]

It is a good topic and somewhat related to http://forum.movingblocks.net/threads/game-balance-and-longevity.860 - although that's more about content and this more about architecture

I've been looking for a multi-hour block of time to reply thoroughly to the other thread (sorry UberWaffe for leaving your great post waiting so long!) but in super short I expect we'll come up with a few game types to sort of funnel content of different types/feel to into sensible bundles of stuff. And yeah I could see a game settings screen filled with tweaks for one specific game type including difficulty and such.

That is coming but on hold waiting on other stuff like NUI and more logistics work with the structure of things

Keep an eye out for a mega-post in the other thread sometime soon'ish(tm). It is a good read although really more for content focus.