0
\$\begingroup\$

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

\$\endgroup\$
  • 1
    \$\begingroup\$ You're essentially talking about writing your own game engine. You want to predict every impact to the game a future item/object could have prior to creating the class, so you can add items based on their parameters. It's nearly impossible. You should start with a simple template and update it as needed. For example weapons have image, cost, damage. Food class has healing. Etc. \$\endgroup\$ – Kyy13 Mar 2 '18 at 15:38
  • 1
    \$\begingroup\$ Would call it "modding", but why would you want to mod a game without having the game in the first place? \$\endgroup\$ – wondra Mar 2 '18 at 15:48
  • \$\begingroup\$ @Kyy13 "your own game engine" Oh, haven't thought of it that way, yet. "It's nearly impossible." I understand your reasoning, but can you provide a reference of some kind? Some paper about how computers are unable to comprehend our universe or some big virtual life games that were never finished? \$\endgroup\$ – SK19 Mar 2 '18 at 16:15
  • \$\begingroup\$ @wondra Basically because I'm thinking ahead. I'm a good programmer and a good author, I could always just make a somewhat exiting text based game with a couple of items that do a couple of things without much work. Actually, I think I might just do that now. But what I really want is a sandbox game without restrictions, see meta post. This is really hard (or in Kyy13's word: "nearly impossible"), so a lot of preparation is required. \$\endgroup\$ – SK19 Mar 2 '18 at 16:25
  • \$\begingroup\$ I'm just relating it to the Yugio example. Certain cards get rules specific to other cards, so the "formula" will keep changing. If you know for a fact that the rules will never change, then you can create a static formula that uses your parameters, but it's very difficult to keep a game alive just by changing parameters. Players get used to the parameters, e.g. more health, more damage, more defense, more power, etc. You can keep creating more cards with different parameters, but eventually they all start to feel the same. Then you need a new mechanic. \$\endgroup\$ – Kyy13 Mar 2 '18 at 16:29
1
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ I didn't know about Scribblenauts and currently read the development section of its wikipedia page. Your answer is perfect, many thanks. \$\endgroup\$ – SK19 Mar 2 '18 at 18:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.