What do we call a feature that allows many kinds of game object to be "plugged in" modularly?

Question

I'm currently at a very abstract level of designing a certain game (if interested, see this meta post), so my question is a bit abstract, too. But I'll provide a reasonable example, so please bear with me.

My Description

In the game, there should be various "kinds of objects". The game would be too big to do alone, so - as I am currently working alone - I would need a high level of modularity to ensure I can later just "plug in the content". Here "content" means not something like "extended story line" but new "kinds of objects". E.g. in a game where you just have food, armor and weapons I want to add kitchen supplies, without having to touch the core code much. I'm a seasoned programmer, so I know this is hard and weird.

One way to do this would be that I would implement some sort of "template" what a "kind of object" could look like and what would be possible to do with it regarding interaction with the game world. "Kinds of objects" would be written in plain text (with a certain structure to it, e.g. XML), I could then write an interpreter for these files, so they can be loaded in runtime. Then, in the game, specific objects can be created from a "kind of object", which then can be interacted with as previously inscribed in the text files.

Question

I want to know the name of the feature/method described in the previous paragraph. If possible, I would also like to get resources where I can learn more about this subject and/or which other games also use this concept. Opinions or references about how far this feature/method is helpful or not and for what games or not are appreciated, too.

I only know one game where something similar has been implemented, now presented as example of my abstract concept.

Example for Description

YGOPro is a program where one can play the Yu-Gi-Oh! Trading Card Game. The source code for the underlying engine can be found here. As it is typical for TCGs, there are often new cards (with new effects) introduced in regular intervals while the overall rules stay the same (most of the time). YGOPro deals with this by implementing the overall rules normally and implementing an interpreter that can read and implement the various card effects, which in turn are implemented for one card at a time, see full list and example. Within a play of the card game (called "duel") within the program, specific instances of a card can have different properties due to the gameplay in general and their own and other card's effect specifically.

In comparison to my abstract idea, a "template" would be the implementation of a card, a "kind of object" would be one of the several cards, represented by their effect, and an "object" would be a specific card in the game. Of course this isn't exactly what I'm imagining, e.g. only the card effects are separately handled in files while all other base properties of the cards are stored within a database. But I think it is good enough to understand my idea.

Why I ask this here

Note that I'm not asking "what technology some particular game used" but what it is called. I don't ask "which technology to use for [my] game idea" or "how to make (or start making) a particular type of game", because I thought of a concept myself, but I don't mind if you post an alternative solution in the comments. So as far as I'm concerned, this question is on topic regarding the help center.

Would a professional game developer give me a better/different/more specific answer to this question than other programmers?

I clearly think so. My basic question, written in bold above, could likely be answered by other programmers as well. But my specification about how/if other games used this feature (in which case I would study these to help me understand the feature better as well as its benefits and drawbacks) or which type of games should use/avoid it, which, if asked standalone, would be considered off-topic, can provide a more specific answer and deeper insight into the topic, instead of e.g. giving me some financial program with that type of feature where I have problems seeing the analogy.

Thank you

This question was difficult to formulate and type and I'm sure also difficult to read, so thanks for your patience. English is not my native language, so I'm very open to edit suggestions if some part of the text is especially difficult to digest (except for the "My Description" part, which is by nature of its abstraction difficult, I think).

Answer 1

This sounds to me like "data-driven design" or "data-driven content & behaviour"

You want each kind of object to be a piece of data, rather than relying on each kind being implemented in your game's codebase.

Ways in which we often do this in games include:

• Scripting systems - like in your Yu-Gi-Oh example, using an interpreter or bytecode pattern, with scripts written in text or node graphs.

  These let you load completely custom behaviours at runtime, but they do place a medium bar on the technical skill required to create new content, and can result in a lot of duplicated work if you don't have shared script libraries (imagine scripting up 100 breeds of dog, each with their own version of the "bark" script).

  There's also a bit of a security implication: you need to carefully vet and sandbox scripts that might have been produced outside your control, to make sure they won't corrupt the game state, break the rules beyond what you want to allow, or cause harm to the user's computer / privacy. Many mobile platforms won't allow apps that execute untrusted scripts for this reason.

• Component systems - here we look at each object/kind as a collection of traits and behaviours it has. Each component is defined within your game's code, but content defined in data can combine, configure, and remix those components freely.

  For instance, you might have a Breakable component that accepts parameters for its durability against different types of damage, an effect to fire off when it breaks (including triggering other components), and a list of other object types to spawn as fragments once it's broken.

  An object data file can indicate that it should include a Breakable component with the following values/parameters. When spawning the object in your game, you create a new game entity, and attach to it a new instance of the Breakable component configured with those parameters. Then continue through the rest of the components the object's kind file specifies, adding them as it goes, assembling a complete object with arbitrarily complex combinations of behaviours.

  Components put more work on the main game's code to expose an expressive, modular collection of behaviours, but lower the bar for being able to define new content with those modules, and guarantee more safety against malformed or malicious content.

You might like to look into Scribblenauts as an example of another set of games that use data-driven content to try to simulate an aggressively vast range of possible objects.