Mission Development


  • The development of new missions and tools, techniques and procedures for making missions.
  • The scheduling of missions and overall responsibility for the Zulu-Alpha Calendar
  • Accept and process missions submitted by people not in this office.
  • The maintenance of the mission catalogue(s) and missions loaded on the server(s)



  • Phoenix (head)
  • Kilroy
  • Raven
  • Twak
  • Nic
  • Trip
  • AngryMan
  • Gecko



Scheduling a mission for play
  • Members of this office may schedule events on any date, except for mandatory general events, which must be scheduled only on Sundays, unless 1 week notice is given.
  • If a member from outside this office would like to suggest scheduling mission from the catalogue, then that member must make a post into a new thread in the mission selection suggestion forum making the request/suggestion, and selecting a mission from a catalogue.
  • If that suggestion is popular among other members, or no one objects to it, then a member of this office will schedule it.
  • A new post will be made in the Scheduled missions forum, for a discussion and planning on the execution of the mission, preferably one week before the mission start.
Technical requirements
  • All missions are tested on the server, or a test server prior to being played
  • Faulty missions can be removed from the server at will by a member of the mission development office
  • Missions must conform to the following naming convention: <Mission Type>@##_<Name>_V##_<Special requirement>
    • <Mission Type>: CO for cooperative, or ADV for adversarial.
    • First ##: The number of players the mission is designed to support (Greater than or equal to the number of slots available)
    • <Name>: Your mission name
    • V##: Your mission version number
    • <Special requirement> (optional): If the mission has special requirements such as HC for headless client, or GM for a game master needing to be present.
  • New versions of a mission must have their version number incremented in it’s file name and mission name.
  • If applicable, the mission must have its briefing laid out in the form of a warning order at least in the mission catalogue.
  • All missions must have the medical system to be used specified at least in the mission catalogue.
  • The mission must have reasonable client/server performance
  • All normal mission must conform to the style of play specified below
Mission Style
  • Missions must have a coherent style of play
  • Missions should not be unreasonable to complete given the numbers of players. (between 8 and 16). Having an opposing force of 30 men with gunships and Armour is unreasonable for a force of 12 men to take on. Think about whether mission planners would ever plan to carry out a mission that is ‘against the odds’. Usually, a mission needs to have some chance of success for it to be carried out.
  • Missions should not include too many vehicles (tanks and planes) given the number of players that will need to man these vehicles.
  • Try not to limit the CO to a single course of action. Its nice, as a CO, to be presented with a problem, and then find a solution given the tools available. Setting way points and timings for the CO is impinging on his right to make his own plan.
  • Scenarios should be  ‘open’, where the narrative doesn’t necessarily follow a linear course. So in other words, build your opposing force to simulate how an enemy commander might place his troops and base the technology available to them on what might be likely in real life.
  • A fair selection of weaponry should be available available to the participants given the scenario. Keep in mind that if the players represent a well equipped army, they should have a fair selection of gear at their disposal. If the players start behind enemy lines, they’re have very little choice of weaponry.
  • Bear in mind that this is a Mil-Sim environment. Missions don’t have to be ‘balanced’ one way or the other, but bear in mind that an impossible mission, will also not go down well. Rather err on the easier side.
Submission process
  • Any member of this office can include a mission in a missions catalogue and/or get a mission scheduled and onto a server themselves. The following submission process is for members outside of this office.
  • Make sure your mission adheres to the above requirements, and that it is tested on your own machine.
  • Post your mission into a new thread in the appropriate missions catalogue request forum (Arma 2 or Arma 3) in the Missions Forum, or the Mission Selection Suggestions forum for one-off play following the mission catalogue template and using a warning order for the briefing.
  • A member of this office will then review the submission, and either deny it or clear it for testing with a post in that mission’s thread.
  • Once it is clear to be tested, a member of the office will ask for the mission to be sent to him/her and the mission will be uploaded to a server for testing (Preferably a test server).
  • If the mission works correctly and conforms to the requirements outlined above, the mission will be moved into its relevant missions catalogue forum (if it is intended to be replayed) and uploaded onto the play server(s).
  • It can then be scheduled or requested for play, as outlined in “Scheduling a mission for play” above.



  • Dropbox Account
  • Dropbox folder
  • Site files (synchronized with dropbox)
  • FTP Access to the windows Game Server
  • Administrator access to the test server(s)
Forums and discussion