Units, Events and Triggers
Entry posted by Flexman ·
2,114 views
I'm putting together specifications on the mission side of the game. To me, the bit that you 'play' is every bit as important as the simulation side, and while it's taken a back seat for now, things are getting to the point where it's time to get on and make it all work. Going through some of my older material on this, it needs to play like Longbow 2, have the crew management elements from Gunship 2000 and strategy elements from tactical board games on guerilla warfare and a bit of a story element that wouldn't be out of place in a Chris Roberts game.
So where do we start? Units, missions, events and triggers.
Units perform missions, missions contain waypoints, events and triggers. So lets start at the top and work our way down.
Missioneering
Not many will remember the last iteration of my mission planning tool and generator, Missioneer Delta pictured below, circa 2000, seems like almost 10 years ago :/
The plan is to put in something similar onto the command tent terminal you can operate to change waypoints and assign untasked airCREW to helos to carry out listed missions. In some ways this is not unlike Enemy Engaged. Missions are not necessarily assigned to aircraft (they can be), but we'll assign them to the player, AI pilot or crew. Like the arming system, it will be possible for a player to take the role of a commander and assign missions to aircraft that pilots execute.
You can walk around and choose an aircraft that's not already assigned (see it's info plate when on foot for status). In future we hope to have a selection of helicopters/vehicles (CH-47) but we're focused on the Apache.
When the player boards the aircraft, this is like loading a data cartridge with your mission detailed into the aircraft's avionics. The TSD will be updated with waypoints, times and mission page populated accordingly. First man in sets the mission.
The mission ID# key is set in the vehicle entity. This is reset on one of two conditions, the player has exited the aircraft for 5 minutes or the master zeroise guarded switch in the cockpit is operated. In the case of the latter, a new mission profile can not be loaded until all crewmembers have exited the aircraft.
Mission ID# is just a key reference to the hosts list of active missions which can be viewed on the command tent terminal (connected to the projector).
But we're getting ahead of ourselves. Missions and units need a detailed specification which is the point of this blog entry and my current task.
Running under the surface of the simulation will be the all important campaign engine which iterates through units. We'll take the term UNIT to mean a collection of vehicles, a "group entity". Lets look at an old user editable unit form, take from Missioneer. Nothing really remarkable about it, just happens to be handy.
So we can see some of the basic parameters of a unit. There's a list of entities than make up the unit, a 'formation' which is a list of relative positions that each member of the group will attempt to follow (we'll have some behavioural exceptions to this). An orientation, direction to face when at rest. A name, something fancy and military. Skill level, agression and some factional information.
There are also some timers, our game runs in a real-time 24 hour clock cycle (with time advancement). So unit timers might be relative to an absolute time (world time) or mission time (from dust-off). Timers have an enabled/active status too in case they need to be activated by triggers.
For example, if we want a group of insurgents for player assigned patrol mission to spawn when a player has taken off, the mission engine will assign a MT (mission time) of "00:00:00mt Active", but we might want them 5 minutes into the mission, or not spawn at all except by some trigger, such as a player entering the engagement area.
Or we can set the unit destruction time (just means the de-spawn time). For example, a rescue against the clock, get to them before they are discovered by encroaching insurgent forces. Once depawned, that would trigger a unit removal message which another event trigger can listen for, signalling a mission fail.
So timers are simple unit level events that require no special handling by an event system. But for our game to handle recognition of a "win" or a "fail" situation we'll need to add a basic "cause and effect", a "cause" being destruction of unit "x" with the "effect" being "mission complete".
Mission Events
- SpawnUnit (unitID)
- DestroyUnit (unitID)
- SetUnitWaypoint (unitID, waypointID)
- SetUnitFlag (unitID, active|weapons_free|godlike|formation|state, param)
- SetUnitFaction
- SetMissionResult
- SetWorldFaction( factionID, delta)
- SpawnObject (objectID, parameters)
- CreateWaypoint (unitID, waypointID, location, speed, altitude)
- Play Audioscript (script or audio filename)
Mission Triggers (in any active combination)
- MissionRating (percent, win|loose|draw)
- MissionTime (+ - secs, MT|LT)
- UnitDistanceFrom (unitID, targetUnitID, distance_meters)
- UnitDamage (unitID, damage_percent)
- UnitWaypoint (unitID,at|before|after, waypointID)
- UnitStatus (not_in_combat|combat|flee|panic|landing|takeoff)
- UnitInZone (unitID, zoneID)
- FactionDelta (factionID1, factionID2, + -value)
- DiceRoll (percent)
These are enough for the campaign and mission system to generate pretty much most situations.
Now the tricky part is to build the logic to generate seemingly intelligent behavior and entertain missions using this small command set. And here is where we can have a lot of fun.
We could extend the complexity of the logic further by adding a LUA Get/Set interface for the event system. Then user made missions can apply some complex logic. Even creating whole missions from a LUA script. This is not something we want to do at this time. But for the future, it could be done.
2 Comments
Recommended Comments