Game Master (≤64) Handbook

---

The FM outlines our core skills, policies and guides to ensure every member stands ready for the mission ahead.

Your role access is determined by your skills, experience with those skills, and the specific roles that utilize them. With over 100 roles in UNITAF, creating detailed skill breakdowns for every role is a substantial undertaking that cannot be completed overnight. 

Estimated Role Cards

To ensure the entire unit can transition to the new system immediately, some roles are tagged as **"Estimated"**. These roles use a transitional approach:

• Temporary skill blocks simulate role-specific experience
• Estimated access levels are calculated based on these placeholder blocks
• Similar to LTS functionality but with improved accuracy and fewer limitations

Current State: Estimated roles provide functional access levels that closely mirror the previous LTS system while addressing many of its shortcomings. As development progresses, estimated role cards will be upgraded to the full FTS3 standard with detailed, role-specific skill requirements.

Important Note: When roles transition from "Estimated" to "Verified" status, your access level may change (either increase or decrease) as the requirements become more precise and role-specific.

This approach allows UNITAF to:

• Maintain operations during the transition period
• Provide immediate access to the improved FTS3 system
• Ensure continuity while detailed role cards are developed
• Gradually improve role accuracy over time

The estimated system serves as a bridge, ensuring no disruption to unit operations while we build toward the comprehensive FTS3 vision.

This is a temporary skill block, the skill block is being used to accumulate SP for time spent as any Game Master role until it's role card is completed.

This is a temporary skill block, the skill block is being used to accumulate SP for time spent as Lead Game Master until it's role card is completed.

This is a temporary skill block, the skill block is being used to accumulate SP for time spent as any Roleplayer until it's role card is completed.

This is a block which allows players to gain experience at the <15 level of Lead Game Master.

This is a block which allows players to gain experience at the <32 level of Lead Game Master.

The Mission Support Team (MST) plays a critical role in the operation and those taking part in them are held to a very high standard, as set by the leadership. The role of a Lead Game Master (LGM), Game Master (GM) or Assistant Game Master (AGM) is to work with and alongside the Field Leadership to ultimately provide an enjoyable yet challenging and immersive experience.

As a Lead Game Master (LGM), Game Master (GM) or Assistant Game Master (AGM), your role is to collaborate closely with Field Leadership to deliver a challenging, immersive, and enjoyable experience for all participants. However, mission support is not limited to creating missions. There is no obligation to focus on mission creation if your interest lies in live mission support.

Whether you are managing active operations or enhancing immersion through roleplay, the MST provides an inclusive environment for all levels of involvement. Every role—be it Lead Game Master, Game Master, Assistant Game Master, or roleplayer—is equally valued and integral to the success of UNITAF operations.

Collaborative MST Operations

The practical staffing challenges are recognized, such that the ideal staffing structure may not be possible to achieve at all times, for example, one LGM and multiple GMs, AGMs per platoon operation. In this case, the LGM, GMs and AGMs will work together, with AGMs supporting operational needs dynamically.

Do not publicly disclose any behind-the-scenes or otherwise unseen events from a mission. This includes details not directly observable by units or players, as well as any information that could disrupt immersion.

Avoid publicly critiquing the actions or decisions of any units or players. Internal discussion within the Mission Support Team is permitted, and relevant feedback should be directed to the Field Leader through proper channels. See FM/BP-225 - Article 1: Code of Conduct

Recording and live streaming are generally allowed; however, some restrictions apply to protect operation integrity and participant comfort:

Mission Support Team deployments

Streaming or publishing recordings of any sort while serving as part of the Mission Support Team is strictly forbidden. This is in accordance with FM/BP-742 - What happens in zeus, stays in zeus), as the revelation of behind-the-scenes information could undermine the player's sense of immersion. Edited recordings that maintain this confidentiality may be acceptable.

Field Training Exercises (FTX)

No recording or streaming during FTX to foster a supportive atmosphere where participants can learn and make mistakes without the scrutiny of the public eye.

Mission support operations have special terms that help in clarity and effective communication. Below are commonly used terms and their definitions:

• IO (Intelligence Officer): The person responsible for overseeing the Mission Support Team (MST) during a mission. Normally, this is the Game Master or Mission Support Observer.
• FL (Field Leader): The leader in charge of the overall deployment, managing player forces and coordinating with the MST for mission objectives.
• SA (Server Administrator): Person responsible for server performance, troubleshooting, and guaranteeing smooth operation during deployments.
• RP (Role-players or Role-play): People who increase immersion by role-playing characters, civilians, or other non-combatant roles within the mission environment.
• RC (Remote Control): The practice of direct control over AI units, vehicles, and other elements in order to simulate realistic behaviour or to adjust mission dynamics.
• MST (Mission Support Team): The general term for all members that take part in mission support, including Lead Game Master (LGM), Game Masters (GMs), Assistant Game Masters (AGMs), Mission Support Observers (MSO), role-players (RPs), and OPFOR role-players (OPFOR RP).

The Mission Support Observer is a passive, supportive role on the Mission Support Team and is filled by experienced instructors with extensive expertise in Mission Support. These observers evaluate the team’s performance to ensure missions are conducted in full compliance with the Field Manual.

The decision to include a Mission Support Observer on a particular mission should be made by the Field Leader and the Mission Support Instructor Team. The following factors are general considerations:

• Request for ratings
• Game Master seniority
• Previous instances of non-adherence to the Field Manual
• Poor performance ratings in past deployments

The Mission Support Observer does not perform any game master duties and is not part of the GM team.

Work strictly within guidelines and constraints set by the LGM, no matter how large or small. This includes:

• Follow the guidelines and constraints set by the LGM.
• Avoid actions that could disrupt the mission or its objectives.
• Seek clarification from the LGM when the parameters are unclear.

Keep the LGM informed about critical developments that happen during missions, including:

• Player force progress: Provide timely updates on any advancements, setbacks, or major achievements by the player force.
• Enemy spawning: Inform the LGM of spawned enemy forces and their locations, and for what purpose to maintain cohesive missions.
• MASCAS events: Report mass casualty incidents quickly, including the extent and location of the event.
• Technical issues: Communicate to them any technical issues impeding the operation, such as server performance or player connectivity problems.

The general approach to responding to player pings is as follows:

• Multiple pings: Respond to the ping for players who are pinging two or more times in quick succession; that is, three pings, or a series within 30–60 seconds, which usually means the player likely needs attention or assistance.
• Single pings: Generally ignore single pings because these are usually accidental and require no action.

Note that wherever possible, player requests should be pushed through the chain of command rather than relying on pings. This provides better flow and does not create unnecessary interruption to the Lead Game Master or Mission Support Team. Only directly respond to pings if it's clear immediate action is required or the request cannot be serviced through the traditional command structure.

Follow these steps to import PLANOPS data into your Arma 3 mission:

1. Export PLANOPS data:
   • Navigate to the PLANOPS map website.
   • Click the “Share” button, then select “Export to Arma3”.
   • Choose the layers you wish to export (select all if unsure).
   • Specify the channel to be used:
     • "Vehicle" if the shared map is off
     • "Global" if the shared map is on
2.  Run in-game:
   • Open the Zeus interface.
   • Locate and place the "Execute Code" module.
   • Paste the copied PLANOPS code into the module.
   • Set execution to "LOCAL" and click "EXECUTE".
3. Verify import:
   • Close out the Zeus interface.
   • Open your map in-game to make sure that the markings have come in correctly and are visible.

Follow these steps to remote control a vehicle with a turret in Arma effectively: 

1. Enter remote control by using either the Remote Control module or the context menu to take control of the vehicle.
2. Change to a gunner seat for accessing turret controls.
3. Use ACE Self-Interact > Group Management > Become Leader to take leadership of the group.
4. After becoming the group leader, you can steer the vehicle using normal steering controls while simultaneously operate the turret as the gunner.

Note that this works for most cases, but not all. If the above does not work, coordinate with other members of the MST, or use the AI driver.

Be fair when remote controlling against a player:

• Give the player a chance to detect and neutralize the threat of the controlled unit.
• Avoid placing the player in situations that make it impossible to have any realistic chances for survival or response, unless doing so is part of the narrative and specifically instructed by the LGM

The following rules apply when remote controlling against players:

• Specific players should not be exclusively targeted. Targeting by role (medics or squad leaders, for example) is allowed if it makes sense for the portrayed unit's tactics and objectives.
• Do not intentionally cause injuries beyond what can reasonably be treated by available medical personnel.
• Do not abuse game bugs to gain an advantage

When spawning units or objects:

• Place them out of sight of players.
• Ensure they appear in believable locations. Avoid areas that have already been cleared or locations they could not realistically occupy or reach.
• Allow time for Headless Client (HC) transfer before issuing orders. Place units, then wait for the HC transfer to complete to avoid needing to re-issue commands.

When using remote units, follow these basic principles to enhance immersion and realism:

• Adapt to the role, including any applicable behaviours, tactics, and limitations of the enemy force you are portraying.
• Engage with a level of accuracy that reflects the training and equipment of the unit.
• Ensure actions are consistent with the unit's knowledge and situation:
  • Do not take actions based on knowledge unavailable to the enemy unit.
  • Avoid tactics or manoeuvres that are beyond what the represented unit could realistically do.

Command the enemy force in a way that is plausible for the given faction and time frame, by:

• Using authentic tactics/movement
• Using appropriate and believable numbers of assets
• Having the enemy force make mistakes, as (unlike the MST) they do not have perfect situational awareness

LAMBS is an AI Enhancement mod in our core modset which helps GMs quickly command large groups of Enemy AI. Note that it should be used instead of standard Vanilla ARMA movement orders for infantry if possible. The following section details how to use the specific Modules present in the mod and their use cases.

AI awareness

In Arma, AI awareness is handled on the group level. Each AI group acts like a hivemind, with perfect knowledge of the positions of its group members and the targets they detect.

Hit detection

When an AI unit is hit, it and its group instantly gain knowledge of the position of the attacker. This generally leads to:

• Immediate engagement by the hit unit and its group if the attacker is in range and not already engaged.
• Quick reaction times make the AI groups formidable in combat.

Visual spotting

The ability of the AI units to visually detect a target depends on a host of factors, including:

• Proximity: The closer the target, the quicker the AI will notice it.
• AI skill level: Higher-skilled AI are more adept at detecting targets.
• Environment: Light, fog, and other environmental conditions impact visibility. NVGs or lights will assist the AI units.
• Target Stance: Standing targets are easier for AI to detect than prone ones.
• Weapon Scope: AI units with scoped weapons are able to spot targets from greater distances.

Certain elements do not affect AI spotting capabilities, including:

• Laser pointers or lights on weapons.
• Uniforms or vests, including ghillie suits.
• Tracers from fired rounds.

In Arma, all objects have a locality, which refers to the client in possession. It can be the server, a headless client (HC), or a player client. Locality will determine where calculations for that particular object run, including:

• Hit registration: Whether shots land and do their damage.
• Physics: How vehicles steer, collide, and interact with the physical world.
• AI Behaviour: Handles movement, spotting and decision-making.

Why locality matters

Non-local objects (except for "local only" objects) have to be synchronised across all clients to exist. Synchronisation involves sending information to the server and redistributing it to other clients. Delays in doing so may lead to:

• Bad Hit Registration: Shots not registering or registering wrong.
• Teleportation: Objects or units seemingly jump around.

Some scripts also need to be executed only where appropriate, that is:

• Global Execution: Runs on every client at the same time.
• Local Execution: Runs only on the client which owns the object.
• Server Execution: Runs only on the server.

Headless clients reduce the load on the server CPU by offloading AI calculations to the client, allowing the server to focus solely on game logic. AI calculations are offloaded to the client which owns the AI object.

In UNITAF we are using Zulu Headless Client (ZHC) mod, that allows the Game Masters to be better informed about the performance impact their mission has. ZHC uses multiple ways of communicating the performance hit.

On the bottom right of the in-game map every player has an information about the number of active HC, and the server performance:

• The information contains the name of the Headless Clients, its performance graded in frames per second (fps), and how many local units have been transferred to it.
• The information is colour coded:
  • Green text indicates that the HC is performing well, and above 30 fps.
  • Yellow text indicates that the HC is struggling, and its performance is between 20 fps and 30 fps.
  • Orange text indicates that the HC is performing unwell, and its performance is between 10 fps and 20 fps.
  • Red text indicates that the HC is performing very bad, and its performance is below 10 fps.

Additionally the Game Masters have an access to the per AI group information displayed above the AI groups if the Debug Mode is activated:

• To Toggle Debug Mode you have to press a key combination. By default it's “Ctrl+]”
• The information is colour coded. The colours correspond with what the unit is offloaded to:
  • Yellow icon indicates a group that hasn't been transferred yet.
  • Red icon indicates a group that is transferred to the server.
  • Green icon indicates a group that is transferred to the Headless Client.
  • Pink icon indicates a group that is local.

Tradeoffs of Using HCs

While HCs offer better performance, they introduce some additional synchronization latency. The sync path now goes through HC ↔ server ↔ player, which may cause delays. To alleviate this HCs should be run on the same physical machine as the server to reduce network latency.

The single most important aspect of your role as a Zeus is to ensure both a playable experience for the players and exceptional server performance. Achieving this requires careful resource management, particularly regarding objects and AI. The simplest way to maintain good performance is to minimise objects and AI that are not visible or within the effective range of players. Here's how and why:

Kill the player be editing properties and setting the health bar to 0%.

Do not use the “toggle unconscious” module, as it will prevent them from using the map afterwards.

Heal players only if they were injured by an unforeseeable bug/glitch or Mission Support Team mistakes.

Some examples that specifically do not count as unforeseeable bugs/glitches:

• Injuries resulting from high-risk usage of enhanced movement (rock climbing, rooftop walking, jumping between buildings,…)
• Vehicle crashes not caused by de-sync
• Back-blast/overpressure

• The server admin will have to perform an emergency offload of AI from HC.
• If an emergency offload has been completed, all placed down AI will have to be replaced.
• There are chances that the server might have to be restarted if the problem persists.

In most cases, when the AI stops responding entirely—making it impossible to issue orders or transfer to High Command—there’s no standard in-game fix, and the mission must be halted with a full server restart. However, a HC DUMP procedure can potentially resolve this if an admin is online and familiar with the process, thereby avoiding a complete restart.

Perform a hard reset via the “Task Reset” module, wait for AI to transfer, then re-issue the order.

Run script: 

0 setFog 0;

serverexecute

Using the “toggle unconscious” module on them  may fix the problem.

Assign the correct side via the “change side” module, make sure you ONLY do so on the affected player.

Using “toggle unconscious” module on them has a chance to fix this problem.

Being 'ARMAd' refers to situations where a player or vehicle is adversely affected due to game glitches or unintended mechanics. This could be anything from being stuck in terrain or on an object or being pushed into them. 

• Players:
  • If stuck or under terrain/rubble: use the teleport module on the affected player to a safe position nearby, usually a few meters, afterwards apply a full Heal module on them.
  • If the player was knocked unconscious but is not stuck: apply a full heal module on them.
  • If the player has been injured by an object: apply a full heal module on them.
• Vehicles:
  • Flipped vehicle; by dragging it in the Zeus interface, gently unflip the vehicle a safe distance away from the players, then place it nearby.
  • Damaged vehicle due to terrain clipping: repair the affected vehicle with its settings.

• Apply the toggle unconscious module on the affected player. Make sure that the animation has fully played out before you apply the module again, to toggle them conscious. 
• Note that if the player is severely wounded, you will not be able to toggle them conscious again, and as such, will have to use the heal module on them to fix the problem. So, before you apply the toggle unconscious module again, make sure that the player is relatively healthy, unless the bug prevents them from being seen by a medic.

Be fair when remote controlling against a player:

• Give the player a chance to detect and neutralize the threat of the controlled unit.
• Avoid placing the player in situations that make it impossible to have any realistic chances for survival or response, unless doing so is part of the narrative and specifically instructed by the LGM

When using remote units, follow these basic principles to enhance immersion and realism:

• Adapt to the role, including any applicable behaviours, tactics, and limitations of the enemy force you are portraying.
• Engage with a level of accuracy that reflects the training and equipment of the unit.
• Ensure actions are consistent with the unit's knowledge and situation:
  • Do not take actions based on knowledge unavailable to the enemy unit.
  • Avoid tactics or manoeuvres that are beyond what the represented unit could realistically do.

When roleplaying, it is essential to consistently stay in character (IC) to preserve immersion and authenticity. Adhere to the following guidelines:

• Consistent character behaviour: Ensure that your actions, speech, and decisions align with your character's established personality, background, and motivations.
• Out-of-character (OOC) disruption: Do not bring personal or real-life information into the roleplay space. If necessary, OOC should be confined to specified channels or clearly distinguished from any in-character interaction.
• Respect in-character/Out-of-character boundaries: Do not allow out-of-character knowledge to affect in-character actions; similarly, using in-character actions to resolve an out-of-character issue is not acceptable.