Posted: 05/27/07 Built on top of #018 - Composition Command, a simple command structure using branching to fine tune commands.

The Composition Grid series is a group of gameplay mechanics that revolve around customization of one's game or abilities by placing objects at specific places on a grid. Where these objects are on the grid, as well as where they are in relation to each other, makes as much of a difference as what those objects are in the first place.

Entry #018 - Composition Command made a sort of progress towards programmable combat with it's queue system. However, it was purposely designed to be simple in nature. It's purpose is to design simple special attacks, not coordinate complex maneuvers or replace the default attacking system. This entry is what happens when you do go that extra step and create a more complex programmable system for combat.

I won't pretend to be the first person to create a system for programming combat. Games like Core Wars, Robot Wars, or Carnage Heart (also, I think one of the Armored Cores) all offer a system for programming one or a few robots to engage in combat for you. Carnage Heart is notable also for providing a tile-based programmable system that stood out against the other Robot Wars-like games which required actual knowledge of programming and writing scripts of code.

This game is still a turn based tactical game. Unlike those other games, you do not program everything your robot thinks and does. You still decide where your unit will move, which other unit it targets for attack, and even which kind of attack it uses. This idea is closer to FFXII's Gambit System than one of those games. Instead, this entry is just a few additions to the previous idea that brings it closer to programming - namely, variables, subroutines, and conditionals.

Some things to keep in mind is that each unit may only be moved once per attack. Also, units which rush to the opponent's board will disappear after their action. For instance, a knight will rush ahead up to three squares doing X damage to the first enemy unit he runs into (or, if it's enough to kill the enemy unit with Y damage, rushes ahead again for X-Y damage). Once the knight's action is over, he gracefully exits the field to allow units behind him to rush as well, or perhaps just as likely, opening up protected units to the enemy. Units that do not leave their OWN board, such as archers or wizards, do NOT disappear, thus blocking units behind them from moving forward.

Some of the special actions available to units is intended to move the positions of other units, either your own or the enemy's. In this example, the Heavy Knight rushs forward two squares and does a spinning grab, causing all units in the neighboring four squares (in this case, two ninjas) to rotate one square clockwise. Having completed his move, he gracefully exits the battlefield to make way for the Gold Knight's charge. Then the Gold Knight is able to rush ahead with mucho power and kill those two ninjas (now in perfect position) and meet the enemy's captain head on.

Each action in the queue takes place sequentially, each action completing before the next one starting. A defending unit does not have a queue and pretty much just sits there and gets hit, except when attacked from the front. In that case, both units proceed in the same order (magic, ranged, then melee) simultaneously. If there is a case of two units entering combat, both using a command queue, each block is taken simultaneously. For instance, if the first block is archers for the defender and knights for the attacker, both will attack at the same time. In the case of speedy units (like thieves), perhaps they have a slight head start or something.

Actions that change formation can only happen at the end of a command queue. You can have several of them (such as changing to a formation and then rotating twice), but they must be the last actions in the queue. If your opponent's queue is longer, it is possible that some of his combat actions may be played out during each formation action. In that case, the combat action launches first and after it is done, then the formation action. They both must play out to completion before moving on, regardless of what sort of actions (if any) follow.

As shown in the previous entry, one designs their own command which they can call later. One could think of these as sub-routines. You could call a command routine from within another command routine (maybe even multiple times). Use it to store part of a command that you'd like to reuse between different commands. Either you could use a naming scheme to indicate incomplete commands, or you could perhaps have the program flag only complete command routines as ones that can be called from the field map.

A routine will basically just insert itself into the command queue as is, such that each block executes as if it were part of the queue. Nothing complicated here.

Let's say you've got this command queue ready to go. It's not very receptive to change. If one of the needed units is dead or otherwise incapacitated, then it continues on (that block is considered a PASS). But if you have a situation where one command depends on another command succeeding, then you've got a problem. That's where conditionals come in. Basically, it's a branching path that branches based on some criteria.

Here, certain blocks are only acted upon if the previous block succeeds (the unit has completed its move like it was supposed to). If the previous block did not succeed, for one reason or another, it skips those three blocks. They are not counted as PASSes but are actually skipped, causing later blocks to act sooner than they would have otherwise. You can use this to your advantage if you need to vary the time before certain actions happen.

Here is an actual branch, with two different sets of blocks to activate depending on the success of the previous block. One could assume that each one of those paths could split as well, but there should be some sort of limit in place for actual branching paths. Perhaps there is a max total limit to the number of blocks you can use, or simply a maximum number of branches possible.

Of course, success isn't the only conditional available. At the very least, there should be basic boolean operations (AND, OR, NOT) so that you can make sure that more than block successfully completed. Also, there should be conditionals for whether or not a unit is still alive and well, whether a wizard is capable of casting a spell this turn, how many enemy units are still alive, and so on. Don't need to make it too complicated, but enough that you can make some fairly important decisions within a command.