Modding terminology!

[Cervator]

Or "Hooray for bike sheds!" (pretty sure it is blue, btw)

You've come across some of the terms at least: mod, addon, plugin, extension, game mode, etc

We've used just about all of them interchangeably, to great confusion and limited amusement. Time to attempt straightening something out

We're going to have a modding system - that's a no-brainer. The exact details for implementation are flying around all over the place but not really that important to this topic. Point is: There'll be content of different degrees and type. Now how do we classify it?

• We have simple content definitions in JSON, for instance. Blocks, probably individual potions, stuff like that. Any one of these pieces of content may not make sense as a whole "package"
• We have entire systems that work related bits of content - think alchemy with potions for instance, there are a few bits of a few different pieces of content. You could package this and think of it as a typical "mod"
• We have whole game modes we expect to see, that rely on a whole series of systems that work together to create a coherent play experience

I've mentioned elsewhere that maybe it would be an idea to make up our own terms to get away from preconceptions of what a "mod" really is (since for us that could be an internal system, a packaged third party piece of functionality, or even a whole game mode), one that could fit within the game universe. But I haven't had any good ideas for actual names - just weak examples like Ruby using "Gems" for extensions, Java "Beans" or Ultima Online calling servers "Shards" ('cause that's what they were)

I approached the Oracle of Nomenclature (Stuthulhu) and brought before him my humble offering, being careful to balance myself between the expected scorn and the danger of getting slapped for being silly, and lo! I escaped alive with an example that might still be silly, but at least finally illustrates what I'm thinking. He may or may also unknowingly have taken part in shaping his shiny new title, should he deign to post here sometime

Individual pieces of content ("Genes") together make up mods ("Genomes") together make up a game mode ("Genus"). And coincidentally our working title for the first game mode is "Genesis". Coincidence? I think not! "Genius" is more like it.

Thoughts? ... flames? I thought so

(Incidentally, this might all just be me trying not to do work, so this may make no sense at all. Commence with the scorn and slapping of community manager types when ready)

 

[overdhose]

Sega might sue you (genesis), but besides that I don't see why we couldn't accept it as a way to identify Genes etc.

Actually might make some nice sounding badges like "mad gene creator"

 

[woodspeople]

As a former evolutionary biologist, my reaction is - not good. Genes make up a genome, but a genus is not made up of genomes. A genus is a unit of evolutionary classification (species, genus, family, etc). It's like saying a machine uses gears, and gears are made of lemon juice. Also, for me the whole metaphor brings in limitations that damage flexibility. Genetics works in very specific limited ways that do not match what we are trying to build. Mitosis, meiosis, recombination, jumping genes, morphogenesis, ontogeny recapitulating phylogeny, genotype-phenotype, a mess. Metaphors can be as limiting as they are inspiring. [Edit: Also, be careful of bringing the intelligent-design enthusiasts to consider this a place to set up camp...)

I'm more for the non-living assembly type metaphors, because they match better and have fewer intrinsic restrictions. Maybe the names you keep trying to find metaphors for ... are the right names. Pieces, packages, modes. ?

 

[woodspeople]

I may have said this before but: the reason I don't like "mods" as a name is that it implies there is something to be modified, some central or default or unmodified game. Modules, packages, whatever else, does not imply a default, simply a base. Which is distinguishing.

 

[woodspeople]

The central question is: what experience do you want the user, facing the task/opportunity of building the game they want to play, to have? What do you want that experience to feel like? Like programming? Like system administration? Or like playing a game?

What if the names for the three levels (snippet, module, package) could be configurable? You could choose which you like to call them?

Which game do you want to play as you build your game?

Literal: bits 'n' pieces (BnP - gotta love that in-group jargon); modules; packages
Worldview: ideas, genres, ideologies
Magical: spells, charms, effects
Foodie: flavors, concoctions, feasts
Steampunk: gears, assembly lines, factories

Etc etc, and the user could supply their own?

Too far out?

 

[eleazzaar]

Point is: There'll be content of different degrees and type. Now how do we classify it?

• We have simple content definitions in JSON, for instance. Blocks, probably individual potions, stuff like that. Any one of these pieces of content may not make sense as a whole "package"
• We have entire systems that work related bits of content - think alchemy with potions for instance, there are a few bits of a few different pieces of content. You could package this and think of it as a typical "mod"
• We have whole game modes we expect to see, that rely on a whole series of systems that work together to create a coherent play experience

The first two seem to be only different in quantity not quality. I don't think it is very useful to make different terms simply according to the amountof content. Assuming TS is a success, there will be things with one new or altered block, all the way up to things with hundreds or thousands of new pieces of content -- and probably everything in-between. Where's the line? Any number of pieces of content could be packaged together for convenience, not because they share some thematic unity, but because somebody things they are all cool.

I may have said this before but: the reason I don't like "mods" as a name is that it implies there is something to be modified, some central or default or unmodified game. Modules, packages, whatever else, does not imply a default, simply a base. Which is distinguishing.

If you call something a "module" it will pretty much inevitably be shortened to "mod".

 

[woodspeople]

Assuming TS is a success

This assumption may not be questioned.

However "where is the line" is a good point. I think having a line is a good idea because it shows up the EASE of doing cool things when you can't do complicated things. For every person who can build a full mod/module/whatever, there are a hundred who would like to and can't, but could do something smaller. There is much research on volunteering success improving with small, easily overcome obstacles to contribution (like the various clickworkers projects). So I think a "you can do this" level is useful even if a line has to be set up and maintained by hand.

I always thought "mod" meant "modification". Research: "drupal modules": 921,000 results. "drupal mods": 52,000 results. I don't concur that people will always shorten it to "mod" if it says "module" on official places. In fact knowing it is "module" and not "mod" could be a noob distinguisher. Need lots of those.

 

[Cervator]

On genetics- I realize the term setup isn't exactly accurate, and Stuthulhu certainly also warned about making the terms too complicated. I would say a mechanical example would be more like gears make a machine that stands in a lemon juice factory tho on the gene-genome-genus bit, or that would be the intent, anyway

I was going more for terms that could make some degree of sense to a non-geneticist while also having a certain ring to them (fun). I know I won't convince geneticists or likely win many of them as friends...

Point was - Terasology is about creatures, their characteristics, behavior, etc. In my humble vision, anyway. Wanted to try to come up with some term that might relate to that somehow

As for whether there should even be terms? I don't know. I just know the current soup is a mess. Yes, the separation between genes (content) and genomes (systems / mods) is artificial, at best just a way to differentiate what you might ship in a package (even 1 "gene" solo could package into a "genome") vs what you might reuse from one package in another (a single piece of content). Asset, Package, Mode would be about the same thing, just boring.

Two terms, three terms, no terms, completely different examples - I dunno. That's what I started the discussion for

Incidentally, I hadn't even considered the secondary potential to call modders mad scientists causing mutations in the world of Terasology.

 

[Cervator]

Okay, now that I'm home and able to gather my thoughts - I forgot some stuff from earlier thinking sessions in my eagerness to geek out on terms, rushing stuff since I was probably supposed to be working

Earlier I just threw out some terms without really backing them with technical heft or examples - there is actually a tie-in to functionality and a distinct difference between genes and genomes. And the usage of them as terms would probably more specific to explaining / referring to scopes. Like a flowchart meant to explain the architecture / flow of content in the game.

Genes are exclusively data - in our game where content is data-driven and tied to the entity system (entities and their attached components holding data). You can't use or move data around without some sort of container - which is what genomes are: a definition, the systems in the ES that makes the data work, plus similar supporting stuff (events etc). Using books as an example (not accurate to current implementation)

Books and Bookcases are data (genes)
BookSystem and BookCaseSystem manage data (and collectively make up a genome with the data when wrapped in some definition stuff)

As such the genome would also be the namespace of the mod. The way you'd interoperate between mods (mods requiring other mods) are through the genomes, which would hold a definition of what type of data they can use (genotypes? heh, butchering another term) and what dependencies they might have (other mods/genomes that must be present). So a pile of packaged up books (genes) in a "mod"(pure data plus the definition = genome; dependency on the book mod/genome) would be able to add its stuff into the world if the book mod is present.

Other systems/mods/what not would be able to reach into a mod/genome to reuse genes from there for a new mod/genome. Gene splicing! I didn't really mean to dig up more terms, but they just keep fitting in perfectly...

.... yeah okay, this sounded better in my head. I might still just be totally off my rocker and this be a solution in search for a problem

Edit: Incidentally this is also in part to make modding itself sort of like playing a game, or doing it in-character. Could base ranks off it and stuff. "Splicers" and what not

Doesn't need to be genetics, just wondering if the concept has any merit

 

[woodspeople]

We spent some time discussing this last night, and here is what we came up with. We compared the sorts of mod-type-things that need to be named with ... a game we've been playing a lot lately (okay, Minecraft) and, for balance, with a game I played a lot as a teenager, D&D.

== Level one

The first level of modding is the little thing that adds fun and/or functionality to the game. It doesn't make any major changes, but it gives you a tool you didn't have before.

In Minecraft, this is something like the Ender chests mod: you can now use chests that are connected. (I hear this has just been enveloped by the vanilla game...)

Another MC example is the mod I was planning to make after being begged "let's make a mod". I didn't make it, because after looking at the deobfuscated code ("function_34234") and the recompilation process, I whined about this to my husband, who said "why don't you just find an open source game to mod?" and we found TS! The child is still waiting to mod TS and we hope to soon, but our first attempt will surely be of this first category. Anyway, the mod I had INTENDED to make would have been simply called "the fog mod". It would have consisted of one craftable block, fog, with which you could obscure mysterious places. It was just a little idea. That's the first level of modding.

In D&D, this would be like the little things we did to tweak the game as we played it. For example one of my characters was a marsh-wiggle named Puddleglum (from Narnia), and he had extra abilities and tools that weren't in any of the books, just so I could cheat a little. (Actually, all of my characters had extra cheats slipped in and scribbled in between the real things on the pages...) Also, when building dungeons we often made up new things like "The Sword of Unending Ability to Walk Up Walls" and things. First level of modding.

So, for players, the image is of throwing a set of things together to see what happens; bits and pieces; tools in a toolkit; colors in a palette. For modders, the image is of a low bar, a fun experiment, something to try on your way in to the modding world.

Our best tries at words for this level, thinking not of metaphors but of what it means to gameplay (since that is what will attract modders and users of mods):
tweak
tool
atom
add-on
add-in
component
element

== Level two

The second level of modding is one where your capability to do something is bumped up considerably. At this level there is usually not one extra thing you can do, but several in a coherent, meaningful complex.

In Minecraft, any of the industrial mods fit into this level: Buildcraft, Industrialcraft, RedPower, Railcraft, WWII guns; and the creature-type mods: Mo' Creatures, MobDisguise, Baby animals, etc. These mods produce the ability to do lots of things, related things, that add to gameplay in a large way but without changing it entirely. (Actually, in Minecraft there are very few fog-block type mods, probably because it's a pain to even try to mod the game.)

In TS we already have something operating at this level: miniions. !! Hooray !!

In D&D, the best example I can think of this was what my sister did. She was a young adult into D&D when I was a teenager into D&D, and she wrote lots of dungeons for us (and was a great DM). One dungeon I remember had a physical prop: a set of cards she drew up, with names and pictures, to describe things we found and things that happened to us. When each card came up she pulled it out and handed it to us. (It was essentially Magic: The Gathering, only we didn't know it.) None of the things on the cards were in "vanilla" D&D, and they worked together, but they didn't make any huge changes to the underlying system. They just added a new capability to it.

So, for players, the image is of adding capability, leveling up one's skills and abilities to do cool things, but within a chosen world, not changing it. For modders, the image is of a set of integrated tools that form a functionality for expanding and advancing what the game can do.

Our best tries at words for this level:
capability
functionality
expansion
extension
platform
package
planet
system

== Level three

At the highest modding level are things that totally change the game experience, until it feels like a different game. They may change the premise of the game, or the way you interact, or your goals; but they transform rather than supplement the gaming experience.

In Minecraft, a good example of this is Tropicraft. This mod makes only a few minor changes to the normal world: pineapple and bamboo grow on/near beaches. You have to find some of those, then craft a beach chair and a pina colada, then sit on the beach chair sipping the pina colada at sunset, and you are transported to a new dimension: the tropics. In the tropics many things are different: how the water looks, what kinds of animals run around, how the wind blows, even what creepers do. It's a whole new world. (The Aether mod is another example.)

The equivalent transformation experience in D&D was the book sets. I played in general with the "Advanced D&D" book set, which cost me a pretty penny. I once went to a party where people were playing the version of D&D for those lacking in imagination, the one with the stupid plastic people you moved around on a table. Different game, same game. I also found out many years later that my husband played D&D at the same age as I did, but he played both "vanilla" D&D and an offshoot that took similar game mechanics into a futuristic sci-fi world. This was done with another set of books that laid out the world you entered and the rules therein.

So, for players, the image is not of adding something to the game experience, but of entering into an entirely new game experience, of entering a game within the game. For modders the image is of creating something unique that stands alone, that isn't combined with other things but contains other things.

Our best tries at words for this level:
destination
transformation
city
orbit
sphere
cosmos
universe

Our favorite set of these is element - system - universe, because it all sounds so inviting.

As always, hopefully helpful

 

[overdhose]

It is, personally have no clue what the best decision is. While I personally don't hate the fact that a project tries something different, like naming the mod genes and actually builds on that concept with mad scientist titles and the like, others might not and as you said prefer easy recognizable terms. I guess it possibly depends on what kind of crowd you want to attract? I do believe that in the long run, if your game is fun enough and the system easy enough to understand, this is a detail that will remain open for discussion untill eternity, whatever you opt for, some will love it and some might hate it. That's why personally (sorry woods it's not that i don't appreciate your input) I would vote for the mad scientist within the world of Terasology, because well when I read it, it just sounded... refreshingly cute.

 

[Cervator]

Thanks for the write-up, good stuff as usual. And yeah, those are the three layers I'm sort of looking for too. I also agree that it'll be a detail that ultimately is just a small piece of the whole and the exact details will be a toss-up to some point: different pros and cons.

Anybody else? Don't even have either mod specialist in here yet, boo

 

[woodspeople]

I agree and disagree with what overdhose said. Coolness is wonderful, BUT there is a tension in game development between insider-cool and outsider-ease. The question is, how would each of these two events impact the game?

1. What does that mean? Oh, cool, now I know what it means, I can torment the noobs. I have advanced in conquering the mystery. I am playing the game.
2. What does that mean? Ach, this thing is too confusing to be fun. I don't have time for this, I'm outta here.

If the names for things are memorable and simple and clear, you will get little of either reaction; but if the names are cool but mysterious (and confusing), you will get lots of both. Is getting more of #1 (some people love the game more) worth getting more of #2 (some people walk away)?

I can think of two situations that would influence that decision:

• This is our game. We are all happy to work on it forever without any help. We don't want any help. We want it the way we want it. We like our funny/cool/mysterious words, because they make it more fun for us. If you can't figure it out, go away because you probably wouldn't be any fun anyway.
• We really, really want lots of people to join us in playing and improving this game. We want people to try it, not go away, like it, and (commercial=pay us money, open-source=contribute stuff). The most important thing is to bring more people in, smooth their paths, help them like the game, understand it, and find things they can do to make it bigger and better. We should call things whatever makes all that happen, cool and fun or not.

Myself personally, I'm a bit more toward the get-lots-of-people-to-help motivation, because I'd like a fun game to play but I have nothing like the time some of you people have. It sounds like overdhose has a lot more spare time than I do, so he's understandably more on the "our game" side of things. I would almost certainly, no, certainly, be on that side if I was suddenly 20 again. So I guess it comes down to what the whole team wants. I can certainly see the argument for "coolness first" and I agree that whatever it is called people will accept that ... but it is also undeniable that confusing things often prevent people from trying things or (worse) produce a "lame" reaction on their way out the door.

Also, I find it hard to believe that the "mad scientist" label can only work with a genetic metaphor. You could get the same coolness from steampunk machinery, magic, lots of other metaphors, some far less confusing. People will say, is this a game about genetics? And I guarantee you will get Intelligent Design debates sprouting all over. (There is a reason I tell people my degree is in ecology, even though it's in evolutionary biology.) The worst thing about the genetic metaphor is that because genetics is not technology, it has limitations that would contradict what mods actually do and offer to the gamer.

I thought of one more metaphor for the three levels of modding:

1. It's a donut ... with sprinkles on top!
2. It's a donut ... with a cream filling!
3. It's a .... bagel!

Is that useful? Probably not. But it makes me want baked goods.

And yes Cervator, we do need the mod specialists to weigh in

 

[Cervator]

Om nom nom I'm eating baked goods right now! Well, more like a non-baked concoction of a similar nature, but either way it is delicious!

I'd be all over a set of Steampunk terms, that's probably another very promising "bag of words" - and yeah, possibly less controversial. I have a feeling the ID types would find something else to cry about anyway

Ultimately I think the way we present whatever we come up with will be more important - if we just throw it together as an after-thought then confusion will reign regardless. But if we can present whatever terms (even the traditional ones if we go with those) in a very nice format (including a nice diagram!) I imagine we can make any choice optimal on the pros and minimized on the cons

 

[woodspeople]

GUI also has an impact on that. I've been picturing a "build your game" screen where you mix and match available things you want to use. Regardless of names it could succeed or fail based on how quickly understandable that is.

 

[dei]

I agree with woodspeople, we should name things how they will be named in gui afterwards (any diff will create confusion among devs)...

For the most upper level I would go with a simple "game-mode" or "gameMode" (camelCase as we're developping in Java ). TA Spring uses "Game" for the same aspect, but I think using "mode" in it it's more clear that Terasology is one game with different flavors and it doesn't produce misunderstandings.

For the next level "extension" fits well into my understanding (if being swiss doesn't disqualifies me, inventing words like "emmentaler" etc ) of being an added element in gameplay. It literally extends the gameplay by a certain limited extend...

This could then consist of several "components". This word suggests "small" and "used in compound with other components" in word itself.

Gene, Orbit and the like seem a little to nerdy, as I hope TS is beeing played by non-developers one day and from personal experience with our customers they don't like to consult a wiki/documentation/etc before understanding what is meant by a term so crucial to the game they meant to play. We just renamed release cycles from "spring", "summer",.. to planet names in my company, and it really confuses our customers , so why not stick with simple and meaningful words that say what the mean?

However the only thing an average end user will probably see will be the "gameModes". Other things are for modders or devs and it wouldn't be that a big success factor. eg. MCs modding-system overstrains many player's skills and will (including mine's)

 

[Cervator]

I'm close to yielding and going back to the boring normal terms on this topic, but still wonder if I've explained myself fully yet. With an example I used elsewhere at a slightly different scope, but potentially linking into terminology elsewhere

Using an extreme example, say the actual setting of the world (or the game universe) is that of a playground of the gods. They interact with the world through demi-gods, lets think of those as Tolkienesque"Ainur" (modders), with the ability to change and impact the conditions and shape of the world. They, in turn, may see their changes actually executed in the world by the "Valar" (server admins). Among the mere mortals (creatures in the world) there are those of greater strength and stature, the "Maiar" (players exist at the "Gandalf level" so to say) who themselves put their mark on the world.

That might be a little melodramatic (or megalomaniac), and I might have Tolkien's hierarchy screwed up some, but point being: a link from within the game to envelop even activities outside the game with a touch of role playing some might enjoy. But then some others might not, it may just be confusion for some, or even be completely out of place when you consider just what the setting within the game could actually be (think a scifi mod or something entirely arbitrary and devoid of mythology)

Anyway, point being, the only part that's within the traditional game definition is what happens when users play Terasology. But the "in-character" feel can expand beyond that if you set up for it

I know not all of that would be visible or meaningful at each level or to each player. Most of it could be completely hidden and irrelevant when you actually play the game, perhaps outside of obscure bits of lore scattered in books. I think it could make a nifty backstory, but admittedly it could make little sense outside a core game, and yes, confusion is bad.

 

[AlbireoX]

Modules. Things you can add, like plugins.
Bases. You know.

 

[Cervator]

:golfclap:

 

[woodspeople]

I think what Cervator is/has been suggesting sounds really cool and fun and motivating. Building and changing the game should be as fun as playing the game, because that's another bigger game. The only issue is, what names will succeed at filling both the fun-for-builders need and the not-confusing-for-newcomers need? And this does matter. It matters a lot. Naming is an important part of design, as any product designer will tell you. Great names motivate, promote, express, cohere, create. I have had great names for projects and horrible names, and I can tell you that names do matter.

Maybe the emphasis on coming up with a suite of names is getting in the way. What if all the "things" were called the same thing, and we used modifiers like "mini" and "mega", or Level I, II, III to differentiate them? Then you could just use one exceptionally cool and in-character word like "mystery" or "invention" or "power" and then people only have to learn one weird term. That is not very hard, and any confusion easily dealt with in a GUI with a little popup or on-screen explanation.

I can think of seven contexts in which names will be used:

1. in the engine/API code itself
2. in discussions about basic implementation of the engine, API and "default" content
3. in discussions among the "modding community" of people who build the module-things
4. in the code for each module-thing
5. in descriptions/GUIs of the module-things on module-thing wikis
6. in the community of end-users who use the module-things
7. in the interface where end-users choose which module-things they want to play with, and in the wiki that describes how to do that

The same name has to be compelling but not confusing at all these levels.

The rule for naming a dog is, go to a local park and yell out each name you think you might want to call your dog, in public. If you can't stand yelling out, "Weiner, come!" in public, don't call your dog that. (We actually did this for our last two dog naming occasions and thereby narrowly missed using some really bad names.) Another one we used when we named our child was one I read about somewhere: go to Google Images and type in the name you think you might pick, then look at the pictures of the people you see. Whichever name has pictures you like best, pick that name. The people with the name we chose looked like great people, and our kid is great, so that worked out well.

In the TS case for Google-Images test we would think of names, then think of other software/games that use each, then look at what those are like and see if you want your game to be like them. A little of that has been taking place on the forums here, unofficially. Drupal uses modules, for example. Somebody could canvass those more systematically and see what they come up with.

However, I think the dog-naming test might work better here, since we are thinking about coming up with names not previously used by anybody. So the best way to proceed with that is to write up some pretend text that would reasonably appear in each of the seven situations above:

1. some engine/API code (class <name>Manager)
2. a discussion post about the engine/API coding and default content (what if we made it so the <name>s ...)
3. a discussion post about module-things people are building (I'm building a <name> that ...)
4. some module-thing code (class <name>Item)
5. a GUI or wiki page for a module-thing (this <name> is all about ...)
6. a discussion post about a module-thing (what I like about this <name> is how it....)
7. a GUI or wiki page where the end-user chooses module-things to load (add another <name>...)

Once you have these templates with spaces for the <name>s, one at a time, pop in all possible names, and see which feels right in the most places. Then you have yourself a name. You do have to write good templates, though; if the templates are no good the naming process will not be useful.

Useful?