Update: I totally forgot something important in my first post – state!
So last night I had a rather interesting discussion about gameplay with an acquaintance of mine. He hadn’t seen Dwarf Fortress or heard of Boatmurdered before, and was blown away by the game, from a gameplay perspective. He showed me a game as well, called Harvest: Massive Encounter. It was interesting to be able to compare the two games. They both seemed to contain some basic elements that made the game fun. He told me how Harvest only has a few basic units that you can create throughout the entire game, yet depending on how you combine them you could end up with some pretty different scenarios or effects. Dwarf Fortress, on the other hand, seems to have a huge amount of complexity and levels to the gameplay, with a near infinite combination of possibilities. My friend was amazed at the story of Boatmurdered, and how the dwarves seemed to develop their own behavior (for example, making items with carvings of elephants on them after a series of elephant attacks).
It really made me think about the core game mechanic that I would like to work with, and it would or wouldn’t be fun. From the two previous examples, it seems that there is a lot of cool stuff that comes out of emergent behavior. I think that it takes a few basic things to establish a concrete mechanic that is capable of some cool behavior:
Entities are what makes up the game. In a game like Tetris, the entities would be the arrangement of the blocks, or the blocks themselves. In a game like pac-man, the entities are the walls, the little pills (both types), the ghost, and the player. In a game like dwarf fortress there are a ton of entities – rocks, trees, elephants, bits of ground that can be tunneled out, gems, lava, water, dwarves, switches, gates, mandrils, barrels, etc. Basically, entities are the “things” in a game.
A state describes the current condition of an entity. States describe things like position, orientation, health, visibility, etc. Think of these as the member variables of an entity. In a game like Dwarf Fortress, a dwarf could have a state of walking, sleeping, digging, attacking, swimming, etc. States don’t necessarily have to be a high level concept. In a physics simulation a state could be the current velocity of an object, and whether it is colliding, whether it is movable, it’s mass, and so on. Think of a state as tracking the ‘how’, such as “how fast is this object moving?”, or “How healthy is the player?”.
Actions are what entities can ‘do’. This often involves changing an entity’s state. In Tetris, the blocks can be rotated. That’d be an action. They also fall downward, which is an action. In Pac-man, the ghosts move around the maze, Pac-man eats the pellets. In Dwarf Fortress, dwarves can dig, mine, swim, walk, talk, carve things, attack other entities, get injured, etc. In a game like Halo, an enemy can attack, retreat, throw a grenade, jump sideways, talk to another enemy, badmouth a player, ride on a vehicle, drive a vehicle, shoot from a vehicle, etc. All of these things are changing the state of entities involved in the action. For example, an action of “kill player” results in a player’s health being set to 0. In short, actions are what the Entities (the ‘things’) can do.
Rules define what actions can be performed. For example, in Pac-man, the player can’t walk through walls, and ghosts can’t eat the pills. Pac-man is limited to moving how the player tells the character to move, except when a wall or a ghost is in the way. In a racing game, the competing cars are limited to the rules of physics when racing against the player (or at least they ought to be!). In Tetris, the player cannot move the pieces wherever they want, and can’t pick what shapes are falling down.
Rules are not always constant. A classic example of this is in the Mega-man games, where half way through a boss fight, when a boss’s health was less than 50%, the actions that the boss could do would change. So for example, instead of teleporting from one side of the playing area to another, the boss would start to run back and forth and shoot, or something to that effect.
Rules define the appropriate behavior for the entities, by determining what actions are allowed and which are not according to the state of the entities. The state of the entities can be used to determine the allowable rules. The rules of physics determine that I can’t jump 100 feet in the air, or that I can’t (or shouldn’t!) fall through the floor unless there is some state that allows me to do that.
Triggers are what causes an entity to perform an action, or rule to change. One of the most obvious triggers is player input. For example, if a player presses a particular button, an action is executed, such as the player walking in a particular direction, or a sword being swung. Other triggers can be based on time, such as a platform falling out from beneath a player after the player has been standing on it for a certain period of time. In a previous example, the trigger of a boss becoming hurt below half it’s health is a trigger to change the rule set that the boss entity follows.
A combination of entities, states, actions, rules, and triggers is what makes up the behavior of a system. These things in combination really define the reality that the game takes place in. The real challenge of development is coming up with a set of entities, states, actions, rules, and triggers that are believable when in combination with each other.
I’m really interested in taking this concept and running with it to create a game. I think that the real difficulty in designing a game is coming up with a proper set of entities, actions, rules, and triggers that create interesting scenarios for the player, and the challenge of programming a game is implementing such a system.