Lead Game Master (≤15) 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.

UNITAF operations follow a strict framework which is outlined in this section. Ultimately the goal of standardisation in UNITAF is to ensure in our system of dynamic ORBATs that standardisation is maintained across all operations so players know what to expect when joining, preparing, planning, gearing out and executing UNITAF operations. This standardisation encompasses but is not limited to;

• What factions can be played
• Duration of missions
• SOP standardised ORBAT organisation
• ORBAT restrictions
• Equipment restrictions
• Database integration
• Limited arsenals

All UNITAF operations use a database framework which ultimately issues standard loadouts to players based on database driven loadouts directory. The framework can be obtained from Operations Command (OC) or Operations Staff (J3) a template is provided and can be copied to your desired maps.

For a mission to be approved, it must follow the framework, in order to follow the framework it must be in line with the following;

• Full arsenals are not to be used under any circumstances, this means;
  • Arsenal content is dictated by the Framework and restricted per the content provided to it by Loadouts Staff (J5) in accordance with FM/C110 - Loadouts and Factions
  • Arsenals with unrestricted content, or not utilising the Framework are not permitted.
• Loadouts should be attainable through the framework ORBAT injection system and must be approved by Loadouts Staff (J5)
• All mods must be on the UNITAF approved mods list
• The faction players are deploying as must be an approved faction
  • Approved factions have limited arsenals prepared already according to that factions equipment
  • Approved factions have default loadouts created for all combat positions that can be ORBAT deployed
  • If a faction is not on the approved factions list, then the faction must be created before the mission can be approved
• The mission file with integrated framework should be ready and tested, prior to the ORBAT being released.

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.

Conduct a pre-deployment briefing for the Mission Support Team, ensuring all members are well-prepared for their roles. The briefing shall include:

• General overview: Summarize the overall mission plan and objectives.
• Pacing expectations: Communicate the expected flow and tempo of the mission to align team efforts.
• Task assignments: Clarify the responsibilities and expected contributions of Game Masters (GMs), Assistant Game Masters (AGMs) and roleplayers.
• Faction details: Provide the names of:
  • Friendly faction(s) units and role within the mission, 
  • Opposing faction(s) units and the allowed units and vehicles they are to employ.
  • Neutral faction(s) units including any approved units and vehicles for their representation.
• Civilian considerations: Identify whether civilians will be present, how they could affect the game, and the general approach expected when interacting with them.

Delegate by assigning tasks to Game Masters and Assistant Game Masters in line with mission needs and their capabilities. Tasks can range from:

• Broad scope: Assign broad responsibilities, such as the management of a certain objective, overseeing a sector, or coordination of a pack of assets.
• Narrow scope could also involve delegation of tasks such as driving a vehicle, operating a single unit, or executing certain in-game interactions.

What is server performance?

An Arma server is an instance of a game without rendering, hence it can perform better in comparison to game clients even on the same hardware. Much like the client, a server's performance is evaluated through means of frames per second (FPS), though on a server "a frame" would typically mean the amount of "game world updates per second.", A concept similar to "tickrate" used in some other games. 

Why care about server performance?

In modern versions of Arma, server FPS no longer directly affects client FPS. However, server performance remains critical to maintaining a smooth and enjoyable gameplay experience. Poor server performance can lead to:

• Bad hit registration: Impacts the accuracy and reliability of weapon fire.
• AI/Vehicle teleportation: Causes erratic movement of units and vehicles.
• Connection stability issues: Results in lag and disconnects for players.

What affects server performance?

Various factors can affect server performance significantly. The following factors reduce the number or frequency of server-intensive processes, leading to better server stability and gameplay experience:

• Entities spawned: Frequent and/or large-scale spawning of units or objects.
• AI units: Great numbers of AI-controlled characters.
• Vehicles: Especially when moving or active.
• Static objects: Too many decorations or functional objects.
• Exploding munitions/submunitions: Explosions or ammunition that have fragmentation or secondary effects.
• Scripted audio: Particularly dynamic/moving audio scripts.

Monitor performance on the server during the mission, performing proactive actions to keep the game flow smooth. This involves:

• Monitor server FPS to spot any potential performance degradation issues.
• Look for causes that contribute to performance degradation due to excessive AI, vehicle usage, or unnecessary static objects.
• Take appropriate action to reduce spawned entities, clean up superfluous assets, and adjust mission parameters.
• Collaborate with other members of the Mission Support Team to implement solutions that prevent performance issues from impacting player enjoyment.

A mission should be planned with some downtime in mind, be it resupply or simply just transit from point A to B. This time allows players to recollect themselves and regroup, and provide a breather in potentially stressful situations. During any downtime, element leaders will be gathering ACE checks and drawing up any battle plan amendments or additions to better prepare for the next engagement.

It’s important to allow time for these brief pauses even if from your perspective nothing is happening often as a MST member the mission can feel slow or boring as a result of your knowledge of the whole battlefield, however, the feeling can be much different from the players’ perspective.

Manage the count of the enemy force to maintain a balance between the following parameters:

• Challenge: The enemy force should be fairly challenging for the player's force and ensure teamwork and strategic thinking from them.
• Player enjoyment: Avoid overwhelming the player force to maintain a positive and enjoyable experience.
• Mission pacing: Time the deployment of enemy forces in concert with the Field Leader's agreed pacing to maintain a consistent flow of action and downtime.
• Server performance: Limit the number of active enemy forces to prevent undue strain on the server, maintaining smooth gameplay.

Distribution of equipment is strictly forbidden except in the following situations, and only with the explicit permission of the Intelligence Officer or the Lead Game Master:

• Missing loadout items:
  • Issuing an item that was accidentally forgotten from the standard loadout.
  • Items intentionally left out of the loadout may not be issued ( FM/BP-711 - Required equipment discretion).
• Communication devices:
  • Issuing of a radio or CTab as outlined in the campaign briefing, so long as the relevant loadout policy is followed.
• Mission-specific equipment:
  • Issuing mission-critical items, provided they comply with existing loadout policies and are essential for mission completion.

Reinsertion procedures must be pre-determined and accepted between the Lead Game Master and the Field Leader well in advance of the commencement of the mission. The Reinsertion method shall consist of one of the following:

• Player transport:
  •  Transportation of the player from the spawn point to the Area of Operations (AO) with an appropriate vehicle or aircraft.
• Teleportation:
  • Teleport the player to their relevant unit, provided the unit is not actively engaged in combat.

Mid-mission adjustments:

If the Field Leader wants to change reinsertion procedures during the deployment, amendments can be made upon consensus with the Lead Game Master.

Technical issues:

Any person who needs reinsertion due to a technical problem has to be returned as fast as possible to his or her unit to minimize disturbance in gameplay.

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.

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:

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.

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.

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.

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

After FM/BS-764 - Send the mission file to the server, work with the Server Admin assigned to your deployment, to test the mission PBO on the server. This must be done at least a few hours before deployment so that the mission file can be ensured to work properly and any issues can be fixed.

Submit the mission file at least 24 hours before the scheduled start of the deployment to the UTFDEDI on Discord.