This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
Designing game mechanics is part science, part artistry. Typically you have to make trade-offs between simplicity and accuracy. All sorts of factors should be weighed in a design decision: How accurate of a simulation do you want? How well known is the mechanic you are trying to model? How simple will it be to tune, retune, and balance? Will other team members understand it enough to work on it? Will the end-user (player) understand it? And so on.
Sigman Design Rule 41a: Choose the simplest mechanic that satisfies your design goal.
KISS and all that. This is similar to a very handy axiom in AI Programming. Remember that your goal is not to make the most eloquent/advanced/innovative SYSTEM, but rather to accomplish a DESIGN GOAL with the minimum amount of required work. In other words, your game mechanic only needs to be as clever as it needs to be. A bit Zen-like, but true.
This isn't to say always go simple -- sometimes a design goal can only be achieved with a complex system. But always go as simple as you can get away with, because that will facilitate easier tuning, adjustment, iteration, and understanding.
In order of simplicity of implementation:
However, don't confuse implementation complexity with the complexity that the player sees or experiences!
Sigman Design Rule 41b: Complexity of implementing a mechanic does not always equal the player's complexity of understanding that mechanic.
Non-linear mechanics are usually more complex to implement than linear mechanics, but they aren't typically hard to understand! Like I mentioned earlier, concepts like "diminishing returns" are intuitively familiar to many people. The reason is that we encounter tons of different mechanics in everyday life, and many of them are non-linear.
It is not hard to understand that a car's acceleration varies over its 0-60 run (as gears are changed), or that bunnies multiply exponentially, or that your financial investments can behave any number of ways in between key time periods. People observe mechanics all around them every day, even if they aren't thinking about it.
If you are making a simulation or an arcade action game, studying real-life mechanics is hugely important to game design.
A Few Linear Mechanics in Life
A Few Non-Linear Mechanics in Life:
Ok, enough about real life. Let's do a couple quick case studies of actual game mechanics.
Quick Description: Characters gain "levels", which correspond to predefined improvements in key attributes and skills. It takes a certain amount of Experience Points (earned through completion of various tasks) to gain levels. Later levels cost vastly more Experience Points to advance than early levels.
Typical Experience Point / Level Chart
When it comes to an experience point system, there are two main ways of skinning the cat. Method 1, which is by far the most popular, uses an experience point curve like that shown above -- experience to reach the next level increases non-linearly. Only 1,000 may be required to achieve level 2, but you'll need a total of nearly 200,000 to reach level 20.
This system was used in the grandpappy of all RPGs, Dungeons and Dragons. The advantage of this system is that bigger monsters award the player larger XP numbers, so it is easy to compare monsters on an apples to apples basis. Also, the players feel a sense of accomplishment in gaining the larger rewards.
For completeness' sake, the other common system for XP/Levels involves keeping a constant level ramp (say 1,000 XP per level) but adjusting XP awards for monsters to be relative to the players. For example, defeating a kobold with a level 1 character may yield 50 XP, but defeating the same kobold with a level 10 character might only award 5 XP.