I posted a small section on "Distros" over in my big module tracker thread, but didn't go into much detail and was still pretty raw on my ideas there. So in an attempt to narrow in on some more exact details here's a thread to just consider naming, content, and related.
I went with Greek letters, since Terasology is sort of Greek/Latin inspired, and looking for a few good names simply wrote down the alphabet (alpha sorted by their name, not actual letter). Good candidates are bold, poor ones are in italics (all IMHO):
Iota
Name: Chosen as it represents a very tiny, minimal amount of something. Smallest part imaginable. "Omicron" (meaning "little") might actually pair better with "Omega", but alpha sorts wrong, argh! Probably also less well known.
Scope: Module set, Launcher technical option, Jenkins view, dependency target, primary TWOVANA test suite
Terms: As minimal central content everything is under Apache 2.0 / CC BY SA and community owned + maintained. Only root repos under the Terasology org on GitHub allowed.
Uses: Modders should be able to rely on Iota modules always being present and always being 100% compatible with each other. No stable release is allowed unless Iota is completely green and tested. Iota should contain a few basic gameplay templates that activate almost the whole set of modules and nothing else - notably the few gameplay modules are the main exclusions since you don't want our equivalent of "Creative" active at the same time as "Survival" (clashing rules)
Omega
Name: Chosen as it means "great", "last", "end", etc, and generally is understood well as something large or ultimate. Also, its lowercase form is a pair of buttocks
Scope: Module super set of Iota, Launcher user option, Jenkins view, possible secondary TWOVANA test set
Terms: Ideally same as Iota, but maybe we can be more lax if somebody would really like to prevent something like commercial use of their art assets. So at least "free as in beer" with CC BY-NC at worst for a small subset, but hopefully not (I don't have any plans or desire to see anything NC in Omega and we could probably just agree on CC BY SA if nobody minds sharing their Omega efforts). Hopefully all root repos under the Terasology org and maintained by the community
Uses: Primary distribution of the game including the "interesting" gameplay templates like Throughout the Ages, Light & Shadow, and so on. While most their building blocks are in Iota the gameplay modules are not guaranteed to be compatible with each other, and will not be tested together (although we might test by template)
Sigma
Name: Fairly well known as the "sum" of something. But mainly I just wanted something that alpha-sorted after Omega and could mean "even more" ...
Scope: Module super set of Omega, Jenkins view, Launcher third party "mod pack" type options
Terms: More open to individual modders' preferences. Root repos under Terasology org or forks/mirrors of third party accounts. Possibly some gameplay modules in here could be premium if any such ever show up. Not necessarily maintained by the community.
Uses: Not so much a distribution as a container of a larger amount of stable modules we'd want to offer officially for the game, either directly (our stuff) or indirectly (other people's stuff flowing through our infrastructure). While it might be possible to simply ask the launcher "Give me everything Sigma!" then pick a specific gameplay template in-game my goal here is more to just group and pick stuff by template, not everything at once (which could run into problems if anything premium gets mixed in)
Xi
Name: No good fitting meaning, just a bunch of more or less obscure math hits. But it is short, looks cool, and alpha-sorts last
Could perhaps be convinced to use "Zeta" instead?
Scope: Jenkins view
Terms: Undefined
Uses: Pretty much just the final Module tab in Jenkins that would contain "everything else" such as experimental modules not considered stable yet. Launcher wouldn't care but maybe some modules would be available "loose" in a module manager app/site (with enough disclaimers over likely instability)
Possible extras:
This might be the most interesting part, on how we organize our very base modules. We've slowly been pulling stuff out of the Core module - how far do we go? @Josharias has an outstanding PR on adding a CoreSampleGameplay module that would go in the engine repo and contain the starting inventory so you can leave that disabled if you want (mainly for other modules that depend on Core but don't want the starting inventory)
Purely from organizational Zen I'd want no modules in the engine repo at all, but that would be mildly inconvenient for devs / would-be modders if cloning the engine repo alone wouldn't give you a game that could run without further setup.
If we just have one module then we could continue with the build.gradle template for modules living there. Two modules may get tricky with duplication. Could we have a single module "Player" that just contained a primitive player? Although headless servers might not need that. What about the basic worlds? Primitive "World" module needed to run the game client for testing? Maybe just include the Flat world? But now you need basic blocks too.
Do we keep "Core" or name it something else? I'm tempted to split it into uniquely named pieces and kick them all out (I want "Core" the term for something else). Maybe if we have a Gradle convenience command able to fetch everything Iota at once, maybe automatically if they're not present. Or should we do that but with an extreme minimal set like Player + World instead of all Iota? Or could we just declare the Player and World as dependencies (on the PC facade?) so they'll get pulled as binaries on the first "gradlew" call? That actually could work?!?
So kick out all modules, move the Core build.gradle into /templates, and attach some module dependencies to the PC facade so you'd get them on trying to run the game from a source workspace? Logically the player, a world, and so on are dependencies for the PC facade, even if they aren't functional code dependencies. That way the engine could be truly isolated (repo and dependency-wise) and you could have assorted projects purely depend on the engine without any connection to facade or modules.
Thoughts?
I went with Greek letters, since Terasology is sort of Greek/Latin inspired, and looking for a few good names simply wrote down the alphabet (alpha sorted by their name, not actual letter). Good candidates are bold, poor ones are in italics (all IMHO):
- alpha - development phase, poor choice
- beta - same
- chi
- delta - confusion potential vs delta prefabs and "change" in general
- epsilon
- eta - confusion potential vs the time term (are we there yet?)
- gamma - slight confusion maybe possible vs rare development phase or radiation ..
- iota - "minimum modules needed to play normally"
- kappa
- lambda
- mu
- nu
- omega - "iota + official content (TTA, L&S, etc)"
- omicron
- phi
- pi
- psi
- rho
- sigma - "ALL stable module" (sum thereof)
- tau
- theta
- upsilon
- xi - Anything else (Jenkins view only)
- zeta
Iota
Name: Chosen as it represents a very tiny, minimal amount of something. Smallest part imaginable. "Omicron" (meaning "little") might actually pair better with "Omega", but alpha sorts wrong, argh! Probably also less well known.
Scope: Module set, Launcher technical option, Jenkins view, dependency target, primary TWOVANA test suite
Terms: As minimal central content everything is under Apache 2.0 / CC BY SA and community owned + maintained. Only root repos under the Terasology org on GitHub allowed.
Uses: Modders should be able to rely on Iota modules always being present and always being 100% compatible with each other. No stable release is allowed unless Iota is completely green and tested. Iota should contain a few basic gameplay templates that activate almost the whole set of modules and nothing else - notably the few gameplay modules are the main exclusions since you don't want our equivalent of "Creative" active at the same time as "Survival" (clashing rules)
Omega
Name: Chosen as it means "great", "last", "end", etc, and generally is understood well as something large or ultimate. Also, its lowercase form is a pair of buttocks
Scope: Module super set of Iota, Launcher user option, Jenkins view, possible secondary TWOVANA test set
Terms: Ideally same as Iota, but maybe we can be more lax if somebody would really like to prevent something like commercial use of their art assets. So at least "free as in beer" with CC BY-NC at worst for a small subset, but hopefully not (I don't have any plans or desire to see anything NC in Omega and we could probably just agree on CC BY SA if nobody minds sharing their Omega efforts). Hopefully all root repos under the Terasology org and maintained by the community
Uses: Primary distribution of the game including the "interesting" gameplay templates like Throughout the Ages, Light & Shadow, and so on. While most their building blocks are in Iota the gameplay modules are not guaranteed to be compatible with each other, and will not be tested together (although we might test by template)
Sigma
Name: Fairly well known as the "sum" of something. But mainly I just wanted something that alpha-sorted after Omega and could mean "even more" ...
Scope: Module super set of Omega, Jenkins view, Launcher third party "mod pack" type options
Terms: More open to individual modders' preferences. Root repos under Terasology org or forks/mirrors of third party accounts. Possibly some gameplay modules in here could be premium if any such ever show up. Not necessarily maintained by the community.
Uses: Not so much a distribution as a container of a larger amount of stable modules we'd want to offer officially for the game, either directly (our stuff) or indirectly (other people's stuff flowing through our infrastructure). While it might be possible to simply ask the launcher "Give me everything Sigma!" then pick a specific gameplay template in-game my goal here is more to just group and pick stuff by template, not everything at once (which could run into problems if anything premium gets mixed in)
Xi
Name: No good fitting meaning, just a bunch of more or less obscure math hits. But it is short, looks cool, and alpha-sorts last
Could perhaps be convinced to use "Zeta" instead?Scope: Jenkins view
Terms: Undefined
Uses: Pretty much just the final Module tab in Jenkins that would contain "everything else" such as experimental modules not considered stable yet. Launcher wouldn't care but maybe some modules would be available "loose" in a module manager app/site (with enough disclaimers over likely instability)
Possible extras:
- Zeta as simply referring to all wholly third party modules entirely outside our infrastructure? Not sure we'd have a use for such a term, but maybe
- Applet simply to have an alternative module list for the applet (less soundtrack, more notable content)
- AWT if we ever awaken that facade again.
- Maybe a module list for Android/OUYA.
- Etc.
- Module set is primarily just a way to group things for various purposes. Each of the main distros is a super set of the prior, so everything Iota is assumed to be in Omega and so forth. Gradle could be made to auto-retrieve source modules for everything in a distro like Iota with a little work. A module managing app/site might organize modules by distro (among other ways)
- Jenkins is one of my first uses for distros, in particular since we've gone "Omega" for the main game download. I'd like to reorganize the views to "Iota, Omega, Sigma, Xi" (alpha sorts in order, yay!) and promote / demote modules automatically between them via @Gooey on IRC. Iota modules wouldn't be in the Omega view, no Omega in Sigma, etc
- Launcher should mainly care about Omega as the "standard" download. With module customization it might want to grab a base Iota zip instead of a barren engine zip to start with? It could query for "mod packs" (think FTB launcher) available in Sigma (everything considered stable) without having to care about a Sigma zip (we don't even have anything presently that would be a Sigma module)
- Dependency set - down the road there may be a use case where you'd want to depend on a gameplay archetype without having to explicitly call out every module. The gameplay templates in Iota could offer that ("survival", "creative", etc). Alternatively I'm tempted to offer editable templates, like everything Iota as an "optional" dependency so you can play survival but disable "Breathing" if you're scared of drowning.
- TWOVANA - we'd want to run automated acceptance tests on a specific suite of modules, Iota makes the most basic option (with some question of whether to enable all modules or only the most "normal" gameplay template)
- Terms: Grouping modules in "rings" from our core sounds a bit like what I wrote in the ancient licensing/guideline thread - although keep in mind that's an old, obsolete, and never-made-it-past-draft-stage thread. I really want to keep Omega like Iota (Apache 2 + CC BY SA) but we haven't formally tagged our art assets yet so need to confirm with our artists first
- "Distro" as a term may be kinda inaccurate in the first place ... feel free to suggest alternatives!
This might be the most interesting part, on how we organize our very base modules. We've slowly been pulling stuff out of the Core module - how far do we go? @Josharias has an outstanding PR on adding a CoreSampleGameplay module that would go in the engine repo and contain the starting inventory so you can leave that disabled if you want (mainly for other modules that depend on Core but don't want the starting inventory)
Purely from organizational Zen I'd want no modules in the engine repo at all, but that would be mildly inconvenient for devs / would-be modders if cloning the engine repo alone wouldn't give you a game that could run without further setup.
If we just have one module then we could continue with the build.gradle template for modules living there. Two modules may get tricky with duplication. Could we have a single module "Player" that just contained a primitive player? Although headless servers might not need that. What about the basic worlds? Primitive "World" module needed to run the game client for testing? Maybe just include the Flat world? But now you need basic blocks too.
Do we keep "Core" or name it something else? I'm tempted to split it into uniquely named pieces and kick them all out (I want "Core" the term for something else). Maybe if we have a Gradle convenience command able to fetch everything Iota at once, maybe automatically if they're not present. Or should we do that but with an extreme minimal set like Player + World instead of all Iota? Or could we just declare the Player and World as dependencies (on the PC facade?) so they'll get pulled as binaries on the first "gradlew" call? That actually could work?!?
So kick out all modules, move the Core build.gradle into /templates, and attach some module dependencies to the PC facade so you'd get them on trying to run the game from a source workspace? Logically the player, a world, and so on are dependencies for the PC facade, even if they aren't functional code dependencies. That way the engine could be truly isolated (repo and dependency-wise) and you could have assorted projects purely depend on the engine without any connection to facade or modules.
Thoughts?
Last edited:
