Control Logic

Understanding Control Logic

Steel Beasts offers scenario designers the ability to issue complex instructions during a mission both to units the player does and does not control. The game also allows a player to use pre-programmed instructions (defined during scenario construction) as activating parameters for other in-mission activities. These instructions are known as events, conditions, and triggers. Collectively they are referred to as ‘control logic’, and can bring so much to a scenario that it’s almost impossible not to build a solid, interesting mission without them.

Using them can be tricky, though. Control logic is not difficult to understand in itself, but it requires the user to understand clearly some concepts that may be unfamiliar. Using control logic is something like writing a short computer program and many of the skills a programmer employs are also employed when constructing control logic statements. You will find that most of the problems you encounter with using control logic stem from that lack of familiarity, and will find also that the difficulties vanish more or less entirely as your understanding of these terms becomes more complete.

Essentials of Control Logic

Steel Beasts control logic uses a pair of Boolean operators, AND and OR. These Boolean operators are part of a larger set of such, which are used to mediate Boolean logic. Boolean logic takes its name from its inventor George Boole and forms the basis for our present understanding of computer programming. We won’t go into a discussion here about Boolean logic, but if you’re curious Gary Owen has put together a dissertation explaining Boolean logic in greater detail. It’s included as a companion to this section.

Before we go any further let’s define some terms.

Condition- An element of control logic. Conditions are evaluated continuously during the playing of a mission. Conditions may assume a value of true or not true many times while the mission executes.

Event- An element of control logic. Events are evaluated until they are true, and once true cannot take a not-true value for the remainder of the mission.

Evaluate- The process of determining whether or not a condition or event assumes the value true or not true.

Logical Operator- The terms AND and OR.

Parameter- As used here a parameter will be taken as any of the statements included in a mission logic dialogue window. For example:

is a parameter.

Trigger- An element of control logic. A trigger may be used either by itself or as part of an event or a condition. A trigger does not assume a value of true or false.

..

I wanted to define these terms mostly to facilitate the discussion to follow. As you’ll see, what’s tricky about using control logic isn’t the logic itself, but the terms it uses. Not everyone is familiar with Boolean logic or the term ‘Boolean operator’ but once you understand what they’re used for you’ll find your ability to construct events and conditions flowing easily and naturally.

Constructing a condition

Conditions and events use the same dialogue window and are constructed identically.

The upper part of the window is where you’ll be selecting the Boolean operators for your condition. This is actually the most important part; the parameters you select will be acted on according to which operator(s) you select for the parameters you designate.

The lower part of the window contains the parameters themselves. All of the parameters themselves contain selectable elements that can address certain unit-types or even individual units.

Most of these will seem pretty obvious, but there are some which bear a closer look.

This parameter:

can be expressed either as shown, or as:

Note the difference. If you do some playing around with the parameter you’ll also notice that the ‘total’ can be changed (by clicking in the box) to display ‘AFV’, ‘Tank’, ‘Troops’ and so on.

This parameter:

allows you to reference conditions or events as parameters for setting up other conditions or events, and can be changed to read:

Events or conditions using this parameter must also include the name of the event or condition to be referenced. For example:

An event or condition using this parameter may not reference itself. You’ll notice that there is a timing element to go along with this parameter if it’s going to reference a condition. The element ‘is true’ can be changed to ‘is not true’ and the ‘for at least’ element can be changed to ‘for less than’.

This parameter:

can be expressed either as shown, or as:

The difference between the two is that mission time refers to that moment in the mission. In this case, the condition or event will fire at one minute into the mission, other parameters allowing. Incremental time, on the other hand, refers to a defined interval that doesn’t refer to the mission clock. A parameter with an increment of 30 minutes will fire the condition or event (again, other parameters allowing) 30 minutes from the start of the mission. The difference might seem trivial, until you consider that a mission can have a fixed time limit, and will count backward from that limit at the start of the mission. This can make timing things according to the mission clock more difficult; switching instead to incremental time frees you of that restriction by not tying you to the clock. Any increment, measured from the start of the mission, can be used without regard to whether the mission clock is counting forward or backward.

For the most part the rest of the parameters and their definable elements are straightforward and self-explanatory. Using a trigger as a parameter deserves special mention only because to use it you must first define the trigger. Defining a trigger is as simple as selecting the trigger option from the Control Logic menu, selecting a trigger, then giving it a name. You’ll want to do that before you build your control logic statement, however. You’ll probably want to give them distinctive names, that you may more accurately select the right one for the right conditions and/or events. The same goes for events that you’ll be including in your control logic statements.

Okay, let’s do a simple condition.

First, a look at the map.

Note the two regions, Brinkley and Klum. These regions are going to be used in a condition that will control scoring for the mission; so like triggers and events, and anything else that I want my condition referring to, I define them first.

My goal for this mission is two-fold. First, I want to award points to either side for control of the regions Brinkley and/or Klum. Take a moment to notice the names that I’ve assigned. Naming your regions is a good idea, it makes them immediately identifiable for when I set up my condition. It also helps me sort through what might be for any given mission a host of other regions, some of which may not be applicable to all of my conditions. Naming my regions reduces the likelihood that I’ll mis-assign regions to conditions, and makes it easier for me to spot any mistakes I might make.

So, I’ve named the regions and now I want to set up a condition that will allow me to use that region for scoring. I could leave things the way they are and assign a score according to the process given in the scoring section. I want it to be a little more complicated than that, however, and there are some details regarding ownership of the region that I want to include. For this mission Blue should not merely roll into Klum in order to score. I want to force Blue to leave at least one unit in Klum for Blue to score any points.

I’m going to set up my conditions accordingly. It’ll look like this:

That’s about as simple as a condition can get. That’s how I like them, nice and simple and easy to fix if I make a mistake.

Looking at it, though, I decide that I want Blue to work a little harder. Right now all Blue needs is to have a unit in Klum to score. I want it so that Blue also has to have more units in Klum than Red. Changing things accordingly, the parameters for the condition now look like:

This changes things dramatically for Blue, as you’ll note. Before, Blue merely had to have a unit in region Klum in order to score off that region. Now, Blue now has to either prevent enemy units from getting into Klum, or destroy those units that manage entry, and in addition Blue also has to leave at least one unit in Klum.

Adding parameters, even ones that might seem innocuous can have profound effects on how the mission will be played. Consider carefully what you add and ask yourself at every step how adding a parameter could possibly change how the mission plays.

The whole condition now looks like this:

As with regions, it’s likewise important to give your control logic statements relevant and distinctive names. You’re building something that can become quite complicated, do yourself a favor and simplify it where you can.

Looking back at the whole condition, you’ll note the Boolean operator AND between the checked boxes. This operator can be switched to OR by clicking in the white box. Changing the operators can also change how a mission might be played. In the example above, changing the AND to an OR would allow either side to score points if either parameters defined in the condition are met. Changing the OR to an AND would mean that both parameters would have to be met before points could be awarded.

Again, this is something to which you should pay careful attention. A control logic statement will not work the way you’re wanting, and may not work at all, if you don’t assign operators properly.

By now you’ll see that constructing a condition, or any other statement of control logic, isn’t difficult. With a little practice selecting the right combination of parameters and operators will become second nature. Attention to detail is what’s important, whether you’re constructing a condition or an event.

Speaking of events, that’s what we’ll talk about next.

Constructing an event

Events are very similar to conditions, and are constructed identically. The only difference between an event and a condition regards how they’re evaluated. A condition may be evaluated continuously during the playing of a mission and may change values at each evaluation. An event is evaluated until it is true, and once it is true it remains true.

Notice the difference. Whereas a condition might give you points, then take them away only to award them again, depending on how the condition changes, an event does so only once and never again.

This can be useful in a variety of circumstances. If, for example you wish to construct a circumstance whereby one side gets points for attaining a goal, (holding a piece of ground, or destroying a particular unit or group of units, for example) you might consider using an event.

An event can be thought of as a pass/fail test. Pass the test and you get points. Fail the test and you don’t. An event can also be used to test whether or not one side has met certain prescribed goals. If you were designing a mission that would have one side running all over the map trying to find a particular (perhaps hidden) zone, representing, say, an arms cache, you’d use an event to determine if that goal (finding the arms cache) has been met. Think of a rat in a maze, looking for a piece of cheese. The test is whether the rat can navigate the maze in order to get to the goal, the cheese. If it does it passes the test and gets to eat the cheese.

An event lets you do the same, the test is whether or not the side in question will meet the goal. The goal (destroy this unit, find this arms cache, whatever) is the cheese. The event determines if that side gets to eat it. An event is just that, something that happens (or not) once and only once during a mission.

To event or not to event, that is the question

So, if events and conditions are that similar, how do you know when to use which?

That’s easy; since events are evaluated until they are found to be true and remain true thereafter. Use them when you want to evaluate whether or not an objective was attained (even if it wasn’t subsequently retained) or whether or not inflicted (or took) a certain number of casualties. Events are also handy for calling reinforcements, dropping pre-plotted artillery, and so on. An event is also useful for those instances where you want the player to make a decision and want that decision to somehow impact the success of the scenario.

A condition is most useful when you want either side to have a shot at an objective for the whole of a mission. Conditions also work very well for those occasions when you want to assign complex behaviors to moving units. Conditioned routes work very well for imparting tactically relevant behavior to AI units.

On the other hand, there will be times when the choice isn’t so clear-cut. Sometimes it’s more a question of taste than of utility, whether using an event is better than a condition. Often though, you’ll know what you want to do and will be able to decide thereby whether you want to use an event or a condition.

Triggers

Triggers are a special type of control logic element. Triggers allow a player to execute multiple events and/or conditions by embedding that particular trigger in the relevant events/conditions. Provided the other parameters are met (or not) the trigger will fire the other control logic elements, all at the same time.

The utility of tying disparate conditions and/or events to one trigger are probably obvious, since-for example-with a trigger tied to the right events and/or conditions you can launch a pre-planned counter-attack involving different units doing different things, all at once.

Triggers can also be used independently of conditions and events. Calling pre-planned artillery is often done using triggers, for example. Triggers also serve as another means by which a player can control the behavior of units, thus allowing for more flexibility in the control of said units.

A final word about logic

Jayman has included with this section a presentation demonstrating how to flowchart your control logic statements. Using his presentation will help you visualize what you’re doing when you build an event or a condition. Gary Owen, as mentioned earlier, has also written a comprehensive article about Boolean logic. This will explain in a more comprehensive manner what the different Boolean operators do. Both are very useful, and both will give you a better idea of what you’re doing when using conditions, events, and triggers.