Adding new "Mobile Mission Objects" to a mission

[bbosen]

At the time of this update in July of 2020, all seven of our sample missions are enhanced with additional mission resources beyond those made familiar in our three "classic" missions. For example, each of the teams now has at least two defended, strategic airfields instead of just one. The island missions are also enhanced with a pair of aircraft carriers (one for each team), and the inland mission is similarly enhanced with two opposing artillery batteries. The mission-ending conditions require destruction of more than just one opposing airfield before either team is declared the victor.

New Mission Designers might want to add still more items. For example, Island missions could be enhanced with additional aircraft carriers or with some combination of battleships or destroyers. Even in the inland missions, strategic ships could navigate the large lakes, and mission-ending conditions could be modified to require their destruction.

Digging into all of this requires definition of some terminology. I will use the phrase "Mobile Mission Object" to represent various different things like battleships, aircraft carriers, naval destroyers, artillery batteries, or additional, heavily defended airfields of strategic importance to new missions.

Most such objects are likely to move around as the mission progresses, but (as in the case of an airfield) that is not necessarily true. Even objects that DO move around are allowed to remain stationary for long periods of time; all of this is up to the mission designer. For our purposes in this discussion, we will assume that Mobile MIssion Objects are all capable of moving around and that most of them truly WILL do so. Furthermore, for our purposes in this discussion, we will assume that any motion of any Mobile Mission Object will be driven by the simple advancement of one or more "timers" in the mission. Accordingly, Mobile Mission Objects do not move about at random. They are not "driven" by Sentient players. Anybody that knows the design parameters of a mission can always calculate the position of any of these objects at any point in time as a mission progresses through its various states. The patterns of motion can be so complex as to be bewildering to human players, but they are always predictable to mission design logic.

The obvious means of creating, tracking, manipulating, managing, and destroying Mobile Mission Objects is to follow the existing pattern that we have been using for aircraft carriers, HQ airfields, RADAR antennas, bunker buildings, and battleships. I recommend that new mission designers follow that pattern as they add new Mobile Mission Objects, since LAC's underlying infrastructure of tools will help you with a lot of tasks when you follow those existing patterns, and may cause you grief otherwise. We will call that pattern the "Legacy" pattern, and our general term for all such mission objects, whether new or not, will be "Legacy Mobile Mission Objects". The best-known, simple example of such a "Legacy Mobile Mission Object" is the rotating radar antenna that is visible at undamaged HQ airfields. It rotates around and around with the advancement of time. Adjustments to its rotation are made every 100 milliseconds (10x/second). For a more complex example, examine the source code referencing "MissionObjectCarrierRed1" in "MissionNetworkBattle07.cpp".

Under that Legacy pattern, LAC missions use powerful tools to track a maximum of 32 objects in a large, 32-element data structure named "ThreeDObjects[]". Among those 32 mission objects, object "0" always represents the human player that is active on the computer using this copy of LAC. Of the remainder, ten mission aircraft use up objects "1" through "10". Those ten mission objects are rather special because they move so fast, and because when any of them shoots or otherwise damages any other object under that Legacy pattern, underlying network logic informs all of the other players of the damage, and the victim suffers quickly. Beyond those first elements of the "ThreeDObjects[]" data structure, objects 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, and 29 are available for general-purpose use in missions. Each can represent an airfield, RADAR antenna, bunker building, battleship, aircraft carrier, naval destroyer, or any of several other items.

Each of the 32 available Legacy Objects is associated with a complex set of "attributes" like its "X" position, its "Y" position, its "Z" position, its "Gamma" or climb angle, its "Phi" or compass heading angle, its "Theta" or roll angle, its velocity, its durability, etc. Under the Legacy Pattern, all of those attributes can be accessed through the aforementioned variable named "ThreeDObjects[], via one of its 32 primary elements corresponding with the 32 available Legacy Objects in a mission.

For example, among the 32 available Legacy Objects, our Legacy Pattern has often been using Object number 29 to represent the RedTeam HQ airfield. Accordingly, to access attributes of that airfield, mission developers could commence a statement with:

ThreeDObjects[29]->

Alternatively, if the Mission Designer creates an unsigned char variable with a convenient name like "MissionObjectCarrierRed1" and assigns it a value of "29", then the above statement could be coded like this:

ThreeDObjects[MissionObjectCarrierRed1]->

After that commencement, the name of the desired attribute is appended. For example, to get and retain the current "Durability" of the RedTeam airfield in a convenient place, a mission designer could create a local floating-point variable named "RedTeamHqAirfieldDurability" and retrieve its current value with a line of code like this:

float RedTeamHqAirfieldDurability = ThreeDObjects[29]->Durability;

For something a little more advanced, consider this line of code:

float RedTeamHqAirfieldXposition = ThreeDObjects[29]->tl->x;

That line of code allocates enough memory to hold a floating-point number, names it "RedTeamHqAirfieldXposition", and retrieves the "translate", "x" attribute of object number 29 (in this example representing the RedTeam HQ airfield), corresponding with its "X" position in "XYZ" space.

To help Mission Developers manage all of this, all of our sample missions define a conceptual tool known as a "Mission Object Map" along these lines:

MissionObjectBunkerBlue1 = 11;
MissionObjectBunkerRed1 = 12;
MissionObjectRadarRed1 = 13;
MissionObjectRadarBlue1 = 14;
MissionObjectHqBlue = 15;
MissionObjectHqRed = 16;
MissionObjectAirfieldBlue2 = 17;
MissionObjectAirfieldRed2 = 18;
MissionObjectCarrierBlue1 = 19;
MissionObjectCarrierRed1 = 20;
MissionObjectBatteryBlue1 = 21;
MissionObjectBatteryRed1 = 22;
MissionObjectBattleshipBlue1 = 23;
MissionObjectBattleshipRed1 = 24;
MissionObjectDestroyerBlue1 = 25;
MissionObjectDestroyerRed1 = 26;

Mission designers can adjust the assignment of any combination of convenient symbolic names like those shown above among any of 32 elements of our "ThreeDObjects[]" data structure from object number "11" up to and including object number 29. Even numbers are always used for BlueTeam objects and odd numbers are always used for RedTeam objects. (Objects 30 and 31 are not available for general-purpose use.)

As you can also see, the example listed above has left three of the 32 available elements of that "ThreeDObjects[]" structure unassigned. You ought to be able to use any of these elements for new Legacy Mobile Mission Objects in your new mission:

27, 28, and 29.

Take a deep look at the published source code for one or two of our sample missions. (If you search for comments containing "Mission Object Map" you'll easily discover related areas.) Follow that pattern to create new Legacy Mission Mobile Objects, assigning each to one of the available "slots" in the "ThreeDObjects[]" structure by simply duplicating and adjusting the pattern you see for existing objects like aircraft carriers. You can create descriptive names of your own choosing to hold and/or manipulate the associated attributes. All of the sample missions already have examples of this in place, and you can adjust that existing code to your liking according to your own inspiration as you create new missions. You can move those new attributes around in XYZ space with new code like this:

   float MissionObjectBattleshipBlue1XPosition = 22.700;
   ThreeDObjects[MissionObjectBattleshipBlue1]->tl->x = MissionObjectBattleshipBlue1XPosition;

The first of those two lines will allocate enough memory for a new floating-point variable named "MissionObjectBattleshipBlue1XPosition", storing "22.700" within it. Then, the second line moves Legacy Mission Mobile Object 23 to that new "X" coordinate (since the sample Mission Map shown above had previously equated "MissionObjectBattleshipBlue1" with the numeric value "23").

In a case like this, where the mission designer has named someting related to that MobileMissionObject with a name commencing with "MissionObjectBattleshipBlue1", the mission designer should arrange manipulation of its other attributes using similar names commencing with "MissionObjectBattleshipBlue1", since that approach will result in the best clarity within the source code.

Most of our new missions feature moving aircraft carriers. In each of those missions, the aircraft carrier objects are handled according to this pattern, and you can use the associated "Mission Object Map" logic as a pattern for other objects. Throughout those missions, the compass heading and XZ position of aircraft carriers is modified ten times per second, and the rudder position is adjusted every ten seconds as mission timers advance through 201 distinct "states" governed by a master variable named "MissionStateNetworkBattle". You can find those code areas by searching for a comment containing "Move naval ships. " and by searching for use of "MissionStateNetworkBattle".

Using these principles and combining them with management of mission "timers" like those that you can see in our published mission examples (especially the aircraft carriers), you can create, name, move, and query or adjust any of the important attributes of a wide variety of new Legacy Pattern MissionMobile objects.

Furthermore, the positions, orientations, velocities, and durabilities of sets of those mission objects can all be synchronized across the network, to other mission players, using other software tools that are documented elsewhere in this forum. Those tools are already available in the underlying logic of LAC, and they are ready for your experimentation at the time of this writing in July of 2020. All of the sample missions with moving aircraft carriers already have all of these features in place, and if your new Mobile Mission Objects follow those existing patterns, their positions and related behavior will also be synchronized among all participating players.