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.
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.
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.
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).