Notice — Under Development: This is still under development and is open to the members for review. Please do not edit anything without contacting Okami, Caboose, or Eagletrooper before it's ready to go live.
Skip to main content

Campaign Mission Operations

These policies were created with the intention to eliminate confusion or misinterpretation surrounding the expectations of a Campaign Maker. Final interpretations lie solely with command in efforts to ensure community engagement and enjoyment.
  • Campaigns can only be created by individuals who have been established as Senior Mission makers and have proven competency in making Mini / Flex Operations 
  • The Campaign Maker’s Role and Responsibility
  • The Campaign Maker/Mission Maker is responsible for delivering a long-form campaign consisting of a story with multiple objectives spanning multiple missions. The goal is to provide fun and engaging missions for 50+ community members. It is encouraged for Campaign Makers to seek input from the community, ideally in a public format so other Mission Makers can understand the community’s desires and pain-points.
All Campaign Operations must follow the (All Missions/Campaign/Operations) polices as well as the following:
  • Mods needed by mission makers for upcoming campaigns need to have official requisitions no later than the command meeting prior to the start of their campaign.
  • Mission creation and parameters
    • Zeus Slots
      • Admin logged is for back end, debug, and general server assistance.
      • Mission maker is for quick fixes due to Arma breaking and general monitoring of the mission.
        • Special caveat: sometimes we get more ppl than anticipated and the mission maker does have to Zeus to add some filler to the mission
        • Mission maker must notify the BCO know he is going to have to use Zeus
      • Using Zeus and the omnipotence it provides to punish the unit is unacceptable, and could be considered a violation of the community guidelines
    • Mission File / Guts
      • These files exist to create a standardized mission and server performance experience.
      • There is no compromise on this. These files host a number of customized settings and features used by the community. If the mission is built without these files, the mission will be canceled and a backup mission put in place.
    • The mission will be created for PVE with the only exception being:
      • There are times when a specialized OPFOR may enhance the gameplay with trusted community members roleplay as the enemy. Under no circumstances will this be an excuse for those members to abuse the position by acting outside of expected tactics to disrupt the community’s mission. Egregious violations could result in disciplinary actions.
    • The mission must be uploaded to the server and tested no later than 24 hours before the designated Saturday at 7PM CST.
      • If the mission is not on the server by then, it will be canceled, and a backup mission will be put in place.
      • Testing the mission MUST happen on the unit server. Spending an hour of a few individual’s time can prevent wasting 50+ collective hours of a mission reset. (If there are exigent circumstances preventing this, mission maker must reach out to BCO BEFORE this deadline to determine a path forward.)
  • Campaign/Mission Design
    • Campaigns will consist of 6 to 10 missions
      • There should be some level of story or context to the Campaign.
    • All campaigns must contain at least one airborne operation.
    • Mission design will typically focus on Alpha, with consideration for other units however, all units should have involvement with the operation.
    • Certain missions can have a stronger focus on other units, but all major units should be taken into consideration in some form.
    • Specific design for support elements in every mission is not necessary, but the scope of the Campaign should have operational allowances to designate objectives for those units.
    • Objectives should vary, to keep things fresh and exciting.
    • Mission maker will not dictate how a mission is to be planned or how it should proceed, (By doing so, the operational command capacity is stripped from the BCO)
    • Objectives are to be laid out and can be indicated they should be done in an order.
    • The scope of missions should include the ability to task out various units without impinging or going ‘outside the lines’.
    • Asset allowances/designations
      • An inventory of assets can be included to simulate battle readiness of the unit.
        • Mission makers will not dictate what assets can and can not be used.
      • There are times when a general idea of a mission asset usage (airdrop, boats) would be conducive to the mission design, but this should be handled via communication and cooperation with extant leadership
  • Mission Briefing
    • All missions should be predicated with a Warno Following Template Provided
      • WARNOs should be released by the Tuesday preceding the Saturday Operation.
      • There is no restriction on how early the WARNO is released but should be no later than Wednesday before Operation.
      • The template provides the overall headings and necessary information.
      • Detail should include all pertinent information for BCO to create a OPORD or FRAGO. If there are specific intentions, i.e. naval or airborne maneuvers, they should be stated within the WARNO as a recommendation. The BCO cannot be compelled to comply.
    • Campaign Lore/Opord/Warno
  • BCO may request alterations to the plan, such as particular assets or time changes. These alterations should be given in advance of the Friday Upload deadline.
Back to top