1BN S3 Department - Mission Development Procedures

From 7th Cavalry Wiki
Jump to navigation Jump to search
This is the Document Release Information
Article Number: 7CAV-DR-008
Scope: Standard Operating Procedures for Arma 3 Mission Development
Version: Version 1.0
Effective Date: 25APR20
Last Modified Date: DDMMMYYYY
Approving Authority: S3
Point of Contact: 1-7 S3 Operations Lead

THIS DOCUMENT MAY NOT BE EDITED WITHOUT S3 APPROVAL.

1-7 S3 Arma 3 Mission Development Standard Operating Procedures

These Standard Operating Procedures are designed to simply and standardize mission creation in the Arma 3 area of responsibility.

Core Functionality Configruation

Before a mission can be made, mission developers must adhere to the standardized procedures below to ensure their missions will be error-free and compatible with the 7th Cavalry Modpack and servers.

Setting up Git-Hub

GitHub is where all mission version information and history is stored in a repository. Every team member must:

  • Be assigned a GitHub repository where they will make changes and updates
  • Create a new branch with their name, and push it to "Origin", as below:
LASTFIRST-patch, LASTFIRST646, LASTFIRST-featureAddition

Creating a Branch

Every developer must pull from the develop branch, and then create a branch off of the develop branch. After the branch is created, only edit the mission file and push changes to the new branch.

Changing an Existing Script

Every developer will pull from the develop branch, and then similarly create a new branch off of develop. Once this is created, the developer will publish all changes to scripts to their new branch.

Committing a Change

Once a change has been created, a team member must send the change on their own branch. This should be the branch created previously with their name in it.

Testing Changes

All committed changes must be tested by two or more team members. If a test is deemed unsuccessful, then changes will be made and another test performed.

Submitting a Pull Request

Pull Requests are submitted after a change is tested, and verified as working correctly. Use the given template to submit a pull request, as it allows for tracking of publicly reported issues.

Merging a Pull Request into Develop

A GitHub administrator must merge a pull request once the proposed changes are reviewed and approved. Pull requests submitted by team members cannot be reviewed by the team member who submitted the request.

Resolving Issues

When an issue is reported, the following actions will occur:

  • A developer will check if a similar issue has already been reported. If it is a duplicate, it is closed, and the original issue will be linked in that post before closing it.
  • If genuine, the issue is assigned to a team member and assigned to a project and milestone.
  • When the issue is being worked on, it will be set as a "Work in Progress".
  • Once the issue has a possible fix, it will be sent for testing. The member will submit a pull request from their branch to the develop branch. This will then be set as in "Quality Control".
  • If a member discovers an issue, they may assign themselves to address it. They will move the issue to "In-Progress", and then submit a pull request once a test is conducted.

Development Cycle

The 1-7 S3 Operations Staff conduct regular updates of both public, and training/operations maps. The process is divided into 6 steps.

Step Description Actions to Take
1 Select the Map to be used The first step in mission development is to choose a suitable map for the type of operation and effect being achieved. Developers must ask whether the map is already in the modpack, if it is profiled for ALiVE, and if it has support from the Regiment to be used.
2 Asset Placement and Spawning The mission creator will setup the spawn area, slot list, and any assets that will be used in the mission, like vehicles. Additionally, any Arsenals will also be placed.
3 ALiVE Setup ALiVE is an enhancement modification to the normal Arma 3 AI. However, it must be setup for each map. If the map does not have a profile already made, it could take several weeks to generate a suitable profile. Once profiling is complete, initial setup can begin. Testing should occur to ensure the profile is performing properly before continuing.
4 Scripting and Feature Addition After ALiVE is configured, scripts will be added. This could include the traditional 7th Cavalry CScripts pre-made system, to custom scripts for different types of missions.
5 Final Play Testing Once all scripts are in place, and ALiVE is configured, play testing can begin on the 7th Calvary Development Server, or Dev Server. Developers will assess factors such as AI responsiveness, amount of AI present, and test any specific systems integrated. These could include the loyalty system, vehicle permissions, and garbage cleanup scripts. Any final changes are done at this step.
6 Mission Release Once testing is successful, and all changes are made, the mission is released for public or Regimental use.
Retrieved from "https://wiki.7cav.us/index.php?title=1BN_S3_Department_-_Mission_Development_Procedures&oldid=5381"