Chapter Two: Fundamental Unit Statistics

Reference: Stargraft [sections]

Yay! We're finally here. :) ... Unfortunately, the entirety of Stargraft and its full capabilities will probably not become apparent to you until you not only finish this section, but also read through the next two chapters. We're starting to get into the real center of the game's workings now, and that inevitably means that things are going to get more complex since things become much more interconnected. On the outset, simple, easy changes can still be made easily with SG, but the truth is that to understand "buttons," how they work, and how to diagnose your problems with them, you also have to understand the basics of animation routines for sprites and AI and orders (behavioral properties).

Let's start with a basic overview. Essentially, Stargraft (at its present stages) edits "buttons," or those control panels that you use to control units in the game. The EXE contains "sets" of these buttons (ordered groups to fill up the 3 by 3 panel in the game) and then designates one to each unit (in units.dat). Also editable by Stargraft are "requirements." Requirements are kinds of restrictions on buttons; they determine under what conditions certain buttons are allowed to appear (probably to prevent cheating and/or transition glitches in the game like the old lurker morph bug). For example, the default requirements for the "train Terran Marine" button are (1) the currently selected unit is a Terran Barracks, (2) the currently selected building is not in transit, and (3) the currently selected building is not constructing an add-on. Thus, assigning the "train Terran Marine" button to any old unit wouldn't work because "any old unit" is not a Terran Barracks. You have to change the requirements first. There are also requirements for spell buttons, upgrade/technology buttons, etc.

For the computer AI, the requirements are exactly the same. The AI doesn't have any real "knowledge" about where each unit is supposed to be built from, each spell is cast, etc.; instead it uses the button set specifications to determine where it can build a unit from and then proceeds to build it there. (Spells and tactical AI, I imagine have some hard-coded properties though) When training units and researching spells, think of the computer "virtually" pressing the buttons just as if a real person were (the requirements are exactly the same).

Let's assume the button in the group assigned to our particular unit meets the requirements for showing up. Then the button appears and you can press it in the game. Now what? When you press a button, the unit/game carries out an "order" (designated by orders.dat). Sometimes you don't even have to press a button and the unit will carry out an order (right-click action, idle actions, pathing, computer AI, etc.); the principle is the same, its just the former is executed manually with a button and the later is automatic. Orders.dat is a list of these orders (move, attack, cast a certain spell, drop a nuke, build, etc.), but each one also as a reference or pointer to the EXE (which contains the code to carry out the order). Also in this EXE pointer is more restrictions for the order (some of which are editable by Stargraft). These are essentially the same as the button requirements (current unit must be a peon to mine, must be a critter to "critter wander", etc.). So before the order is carried out, the game must check that these requirements are met by the current unit attempting to carry out the order. If they are not met, then it can't do it and nothing happens ("fatal").

Now, let's assume the button requirements were met, you pressed the button (and possibly gave the unit appropriate targeting information for orders such as attack or move) and the order requirements were also met by the unit. Now what? Well, in short, the unit carries out the order. Usually, this entails performing an animation inter-linked with some hard coded actions. Thus, the game must look up the current unit's sprite, and then look up that sprite's individual animations, pick the right one associated with the order to perform, and then perform it. (If it finds no such animation, guess what? CRASH! :) Then, usually the animation script has a "marker" at some point where it either loops (carries out the animation process again) or tells the game to perform yet another order (in which case the process repeats itself starting from the second stage).

And then, finally, the unit will move to its destination, attack its target, train a Marine, drop a nuke, or whatever you tried to make it do. :) Here's a brief recap before we actually start to get into the SG reference:

1. You select the unit.
2. Looks up the button set to use for the unit.
3. Checks to see if the requirements are met for each button in that set.
4. Displays the buttons that have their requirements met.
5. You press a button. (and possibly give it targeting information)
6. Looks up the order in orders.dat associated with the button.
7. Checks to see if the requirements of that order in the EXE are met.
8. If they are met, then the unit carries out that order -- usually this entails running an animation.
9. Looks up the sprite the unit uses in units.dat.
10. Goes through flingy.dat => sprites.dat => images.dat => iscript.bin to find the units animation routines. (see the next chapter for more information :)
11. Finds the correct animation routine and then plays it. (If it doesn't find it, the game crashes)
12. Loops, or initiates another order, in which cases starts over at step 6.

Not too complicated is it? :)