System Dynamics

This week we discussed the topic of game systems. A system in general is a simply a set of components or elements that work together as a whole by communicating with each other and acting on those communications. A simple example of a system is a management hierarchy in a department store chain.

In the example of a management hierarchy, as shown in the diagram above, retail employees, department managers, store managers, the district manager, and the headquarters are all objects.

Objects, in this case every box in the diagram above, are the foundations of any system. Without objects, there is nothing. But objects alone are not enough to create a system. Objects need to do something.

Every object has properties and behaviours. Properties are any physical or immaterial attribute. For the sake of simplicity, we will say that every employee has just one property; their job title/description. Behaviours describe how an object acts in a given state. In the case of the department store, assuming everyone is a robot, the behaviour of every employee is defined by their job title/description.

Now our objects - err, I mean employees  - can actually work! But there's just one thing missing that is keeping these objects from becoming a system. Sure every object on its own works and can do something, but they are all just individual components doing things on their own, and a system requires that these components work together. This means we have to define the relationships between employees and their managers. To wrap this example up, we can simplify the relationship between all employees too say:

Retail Employees----Report to--->Department Managers--->Store Managers--->District Managers----------->Headquarters

Headquarters----Assigns jobs to-->District Manager--->Store Managers--->Department Managers--->Retail Employees

And there we have it, the relationships between employees is defined and we now have a simple system (assuming the product is always there to be sold).

Now in games, the only difference is that the system is designed for entertainment purposes. The theory behind system design doesn't change, but the system's primary objective should be to entertain players in the system. Another factor in games is that we concern ourselves with how players will be interacting with the system. Players require information about the system to make decisions, and will require feedback as they interact with the system to learn more about the system and be able to master it. Players are of course, just another object in the system, and as such have behaviours, properties and have relationships to other objects in the system defined and/or restricted by a designer.

The final comment on game systems is that they need to be complete, balanced, and fun but challenging.

We can't leave a system with a big gaping whole in it, it must be finished. For example, creating a mandatory unsolvable puzzle that eternally locks the player in a room.

The system has to be balanced otherwise it could create frustration or lack challenge. An example of this is in PvP multiplayer games that match newbies with experienced players; the newbies have a stick while the veterans have machine guns, grenades and armor that makes your stick obsolete.

Lastly, if your system provides no challenge and isn't fun to play, then people will stray away from it. You can make sure your game is fun through playtesting, with friends, family, and best of all strangers.