Designing Games with Xconq - Units and Actions

Go to the first, previous, next, last section, table of contents.

## Units and Actions

Players can do all kinds of things with their units. They can push the units around, they can make units build things, they can get into fights, or they can just let them sit around. You as the designer decide which kinds of things make sense in your game, then set up the action parameters appropriately. Is moving through swamps going to be slow? Can a small town build any kind of ship, or just small ones? How often can Godzilla breathe fire?

Now, what the players work with is the interface, which can do all kinds of intelligent things -- whatever makes sense for that interface. However, no matter what the interface, no matter what kind of play automation, player input eventually breaks down into unit actions. The set of action types is predefined and can't be changed. They are also very primitive. Each action takes a number of arguments, such as the type of unit to build or the location to move to, the action just happens and either succeeds or fails on the spot. There are no actions that take longer than one turn to complete, and a unit can perform only one action at a time. This may seem horribly restrictive, but actions are just the low-level building blocks; players rarely see actions directly. You have to be aware of them because the game design specifies which unit types are capable of which actions. Each Xconq interface will adjust itself to disallow input that would result in types of actions that you have prohibited.

The number of actions that a unit can do in one turn is limited by its action points. A unit with zero action points cannot do anything at all. A unit with lots of action points can do lots of actions, unless each action costs many action points. You can define the action point cost of each type of action for each unit type. In some cases, the cost will also depend on the action's arguments.

Acp is actually a little like a bank account, since by not doing anything for awhile, a unit can accumulate extra acp (up to `acp-max`), and it can go into debt temporarily, down to `acp-min` (which may be a negative value). A unit in "action debt" at the beginning of a turn cannot move or do anything else, and must wait for a turn when its acp goes positive again. This can be a simple way to implement both fatigued units and units that can do more if they plan for it.

Actions always include both an actor and an object. The actor is the brains, and that is whose acp gets used up, but the object has the action actually happen to it. This is so animate units (like humans) can manipulate inanimate units (like swords). You enable this by setting the acp of the inanimate to zero, but requiring nonzero acp in the various `acp-to-` tables.

In most cases, the actor and actee are the same unit.

Go to the first, previous, next, last section, table of contents.