Is it worth to implement game mechanics/rules separately from the main code?

Question

Not sure whether it fits the scope of this community, or should go to Stackoverflow instead.

Let's suppose that I want my game be easily extendable in its core, i.e. I want that a lot of people, even without decent programming knowledge, would be able to not only tweak existing rules, but even add totally new game mechanics into it. I'm not good programmer myself, but I'm ready to learn, I'm just need some directions and assurance it can be done.

What I've thought about is whether it's possible/feasible to somehow implement game mechanics separately from the main utility code? I mean, for tabletop games we have those rulebooks which don't contain actual algorithms of all actions, but rather describe some protocols and limits, referencing context of each such item heavily. Is it possible to do something similar for PC game, like, describe all the rules in some very high-level, easily readable (and changeable) by a human programming language, which is then "consumed" and parsed by the utility code into a working instance of game mechanics?

That really seems like I need to write my own language and a compiler for it )) Which I won't be able to do, of course. But may be there is an easier approach to the problem?

FYI: my language of choice for the utility code will be Python 3.x

Answer 1

Generally speaking, the ease with which any system can be extended is dependant upon the degree to which its subsystems are tightly or loosely coupled. Usually, the more loosely coupled the subsystems are, the easier it is to modify them as they are isolated & don't necessarily require a complete understanding of the system as a whole.

Nothing is free though - such system typically require more resources (various combinations of time, money & skill) to build. The degree of extensibility you've described strikes me as being directly at odds with the level of skill you've attributed to yourself. It could be done, but crafting software as you've described it is a very challenging undertaking.

The closest existing things I'm aware of is Vassal (which is far more programmatic than you've described), or making a mod for Tabletop Simulator (which mostly depends human interaction to interpret & enforce any game rules).

Answer 2

What I've thought about is whether it's possible/feasible to somehow implement game mechanics separately from the main utility code?

It is absolutely possible. One way used often in gaming is Lua scripting.

From the linked article:

Lua was originally designed in 1993 as a language for extending software applications to meet the increasing demand for customization at the time.

Many games use Lua. (I would link but new-user reputation is limiting my link count.)

Lua scripts can be compiled at run-time. This means they can (for example) be text files sitting in your game's "scripts" directory, easily editable by a modder. Your game loads them up and runs them.

I've seen Lua scripts define the properties of in-game units. Here is a random example from TA Spring.

But you want to "describe all the rules". That's possible in theory, as Lua is a full language, but the trouble is you have to be prescient enough to have the core game code know to look for scripts to extend its behaviour.

For instance you might develop a card game that knows to look for cards in a "scripts/cards" directory. That's great for adding new cards, or editing existing ones. But if you later want to expand your game to include miniatures on a grid you're going to have to edit the core code -- no amount of Lua fiddling is going to get you there on its own.

Please note: I bring up Lua because I know it's commonly used both in gaming and in software for customisation. I'm not suggesting it is the only solution, nor the best for the questioner's needs.

Answer 3

There is a continuum of approaches and whether any particular one of them is worth it will depend on exactly what you are trying to do. Specifically, how much control do you want to offer the tweaker?

On the extreme end of control, you can simply let the tweaker modify the code of the entire game. At that point you would essentially be publishing the utility code and at least one example of how to use it. A tweaker could use as much or as little of the code as they want.

An approach that offers a little less control would be to somehow "freeze" your utility code (say by compiling it beforehand) and only let tweakers fill out specific functions (callbacks), restricting what they can do. Depending on what you want to do, this approach can take many forms. A common method would be to put all the display part in the utility/main code and all the mechanics in the tweakable portion. Or, you may want to keep some mechanics in the "frozen" part because players are unlikely to want to change them, or making them changeable is too complicated.

On the low-control end of the continuum is only letting tweakers change values within a fixed range. A data file which let you select the colours of things within the game would be an example. You could, however use this approach and still offer a lot of customization. It would be possible to define a selection of functions and allow tweakers to compose them to create the callbacks from the previous approach, but not allowing them to define new ones. Or maybe you skip the composition part and just offer a finite selection.

The details of all these approaches and which one fits your use case depends on what kind of base game you want to make and how much control you want to give up. Note that commercial games generally use only the second and third methods because the first allows players to make entirely separate games, which introduces complicated licensing issues. Note that as these approaches form a continuum, the second approach may introduce these issues as well.

Answer 4

It is absolutely possible to separate the rules of the system from the code that applies those rules. I prefer to structure my code that way for complex projects, as it makes it easier to add new rules or change the rules later without introducing bugs into the underlying system. And bugs in a rules engine get found faster than bugs in a system where the rules and other code are mixed together higgledy-piggledy, because the same rules engine gets used over and over by every rule.

Whether it is worth it depends on the complexity of the system. Like I wouldn't bother for Pac-Man, but I couldn't imagine writing Dwarf Fortress any other way.

Answer 5

It's definitely feasible. If it's worth it depends on your goals.

You don't have to invent your own language or write a compiler to make this work.

If you want your game to be easily extendable, it's probably a good idea to go for it.

It's probably more work for you, at least short term, to create understandable systems and make things easy to modify.

One game that does this is Rimworld (I have no affiliation) and you might be able to see & learn from how they did, basically putting a lot of game data and mechanics in XML files that are in the game folders for anyone to see and modify. The core/engine of the game was made using Unity.

There is also the possibility of extending the game further/deeper by actual coding, I know less about that but you can learn by looking at the mods forum.

The possibility of modding makes the game more interesting to a lot of people and I think it has contributed a lot to its success. It also allows the developers to bring in any mod content they want into the core game and in a way, that speeds up development and improves the game since they get assistance from a lot of people, and they can decide to take in things based on what is popular, what seems to work, etc.

And of course, especially for a small independent studio, they have hundreds of people coming up with ideas and testing them for them, which is a lot of work they couldn't do themselves, nor probably hire people to do.

Answer 6

You might want to look into Object-Oriented Design. Python has good support for that.

Thick books are written about this which can be scary when you are new, but the main principles are fairly easy.

The main point is just that you identify what kind of objects you are working with. You don't say what kind of game you are thinking about, but things like Player, Monster, Item, Equipment, Weapon, Armour and so on are typical objects.

If you want different game types, you will probably want a Game object that takes care of victory condition and such. Perhaps a Map object too?

Sometimes it is not clear if something deserves to be an object or not, e.g. damage. If you don't make damage an object the code will be simpler, but making it an object makes it easier to customize.

Subclassing: Both Weapons and Armours are Equipment. Equipments are Items. There are probably other types of Items. You will probably find it useful to define a class Combatant that both Players and Monsters are subclasses of.

The idea is that for example Weapons will have many things in common with all other types of Items, they have a weight, size and other properties like that.

So, subclassing gives you a way of saying that "Weapons are like other Items, but in addition you can wield them, they affect the damage you do, etc etc."

Subclassing also lets your mod builders say "My new type of weapon is just like the standard weapons except that ..."

Then you have to decide which object is responsible for what. This is not as easy as it seems and you should do some thinking about it. Making the wrong choices will not affect the basic game much, but will make it harder to customize.

As long as you are just tinkering on your own you can change things around but the moment you release something to the public, making changes becomes much harder! People will make mods that depend on things being just like they are now. Even bugs. People will write mods that depends on bugs staying in the code. If you change things, those mods will break and lynch mobs will appear at your house.

For example:

A Player wielding a Weapon attacks a Monster wearing multiple Armours. This takes place in a particular Game mode and on a certain Map.

Both Combatant may have Skills like Critical Hit and Dodge.

Now, which object is responsible for what?

There is not one right answer to this. A lot depends on what kind of customization you want to allow.

If you never call an object (e.g. the Map), that object cannot change the attack in any way.

After making all these decisions, document them. Write a "Modders manual" that lists exactly what moddable methods each object has, what parameters they take, what they should return, and so on and on and on...

Good luck!

Answer 7

A simple way to get some basic support for this would be to separate most numerical values into one or more separate text files to allow interested individuals to tweak them into oblivion.

For example, you mentioned tabletop games; if you had a game based on D&D you might have a weapon_damage file containing lines like Battleaxe: 1d12. Your utility code would read that file and whenever damage was dealt by a Battleaxe your code would generate a number from 1-12, 1 time(s) and add them. Tweaking the line to read Battleaxe: 4d6 would instead generate a number from 1-6, 4 time(s) and add them. Similarly, you could have a folder Creatures and inside you have a file for each creature, including lines like AC: 12; then adding new files to that folder would create new creatures. It could even be done for character classes, terrain types, a ton of things.

This style of non-code customization can still be very powerful and cover a lot of pieces of your game. However, this doesn't really allow a user to make changes that you didn't explicitly specify. For example, you might enable Sneak Attack: [damage] to be given to any Creature or Class to add [damage] to any attack that meets the conditions for a Sneak Attack. You could even provide ways to change what the conditions are, such as "whenever you attack from stealth" or "whenever you are flanking" or "whenever you have advantage". However, if a user decides that they want sneak attacks to be "When you make an attack roll, you can also roll stealth against the target's perception. If both rolls succeed, then add the Sneak Attack damage" then the user is out of luck unless you predicted that exact scenario.

If you wanted a user to be able to add completely new behavior to the game without needing coding skills at the same level as the developer, then as people mentioned you're looking at essentially creating either a game engine or a separate programming language. For modifications that don't require coding knowledge, text-based data files and folder structures can still provide a lot of options. If you want users to modify more than that then you'll need to ask them to learn or know a programming language.

Answer 8

[I'm a decades-long software developer, but with no game development experience, so maybe the games industry takes different approaches, maybe for good reasons...]

Your approach absolutely makes sense to me. The core gives the basic functionalities that mechanics and rules build upon, so it's an API that is to be used by the higher-level components.

And when designing an API, my favorite guideline is to create the language that you want to express your higher level code in (of course, withing the syntax limitations of your programming language).

So, a good approach would be to write some hypothetical rules and mechanics just the way you'd like them to be expressed (withing Python's syntax, of course), thus finding out what you want the core API to provide to the rules and mechanics layers.

And of course, I'd recommend to have a look at the scripting facilities of existing games to get an idea what they do.