Mission Development Cycle - 7Cav/7Cav-Alive GitHub Wiki
The development Cycle for the Arma 3 Development Team is straightforward and easy to understand. The process outlined in this section is consistent across every platform, including training missions and the public server.
The first step to developing a mission is selecting a map that we want to actually work on. To do this, we need to carefully consider which maps are appropriate. For starters, here are some questions to answer before we begin developing a map:
- Is the map in our modpack/is it a map that is supported by the Cav?
- Is the map profiled? (more on that later)
- Is it a map that people want to see added?
The mission creator will carefully setup the spawn, slots, and any assets we will use in the mission such as tanks and planes. Additionally, player slots and the arsenals will also be placed in this step. This is, in many ways, a very complicated part of the development process.
If the map we choose isn’t supported by ALiVE, we need to profile the map which can take a considerable amount of time (a week is a good estimate). When we are profiling the map, initial setup can begin. In the first few days we will begin laying the groundwork for the mission which consists of configuring ALiVE and performing initial function tests.
After ALiVE is configured, we need to add the scripts and functions that add that fine 7th Cav polish that players have come to expect and appreciate. This may take a considerable amount of time depending on the base layout and ALiVE profile (are we versing insurgents or a conventional military?).
When the scripts are added and ALiVE is configured, we may now begin play testing on the DEV server. During these play tests, we are looking for enemy force concentration, AI difficulty, AI responsiveness, and the amount of AI that spawns. We are also testing various features, such as the Loyalty Points System, Vehicle Permissions, and base cleanup. In this step, we perform last minute adjustments, such as fixing minor scripting errors or adjusting for mod updates.
The individual testing flow should be as follows. First changes are made on your local machine, then said changes are tested on your local machine, then if fixes are required they are made and tested again until things are working as you want them to. Only once your changes are in a final state, should you then upload them to dev branch on the github. Once enough changes for a release are collected, they are tested all at once in a multiplayer environment on the dev2 server before finally being sent up to S6 for a release.
Local changes<------>Local testing---(Final)--->Dev Branch------>Final Testing(dev2)------>Release
After testing and alterations are made where needed, the mission is uploaded for public testing.