Design Decisions

h1. Design Decisions

{{toc}}

h2. Is ALiVE for Arma2, Operation Arrowhead or Arma 3?

It's for Arma 3. We technically could back-port most of it to Arma 2 OA, but we didn't think that supported our fresh start on a shiny new gaming platform.

h2. Why an Addon?

One of the strongest drivers moving to the next generation of MSO was an lower entry level for any mission editor. ALiVE is entirely based on Editor Modules, ensuring that no coding skills are required by default while still providing the ability to customise settings if you like to get under the hood. To do this, it needed to be an addon.

h2. Why a cloud DB?

MSO featured a local SQL database. This proved difficult to support and maintain. Much of our time was spent helping groups set up and maintain a DB. In addition a new SQL schema was needed on subsequent releases and updates. Many hosters do not allow external SQL connections or the possibility of installing MySQL on a game server. Finally, with ALiVE, the team were keen to push the boundaries around web integration and a companion web app.

The decision was made to move to a model that did not rely on a locally installed database. This would remove the need for database support or installation by groups. By using a cloud based DB with an HTTP API (Apache CloudDB), we can guarantee wider support for game servers and groups. We could centrally manage the DB and provide greater web integration by storing data on a single community DB. CouchDB was chosen due to its HTTP API and ability to scale.

The drawback to this approach is that ALiVE would require its own server infrastructure and therefore cost. The team agreed to move forward and fund the server, but with a view to use donations and ads to cover costs. In addition, the team agreed that they would look at local storage storage where it made sense (i,e. either local file or local couchdb/sqlite).

h2. Dynamic vs Static Map Analysis

In MSO, we used dynamic map analysis to place units. With ALiVE, due to the size of maps and the new strategic aspects of AI placement, we needed a deeper form of analysis. Due to the performance requirements for this, it could not be achieved in a timely manner. Dynamic map analysis also adds a performance hit that is not necessary.

The decision was made to do map analysis outside of the game and create static indexes of each map. This would allow much faster placement of AI and general analysis of the terrain when controlling AI units.

The con to this approach is that BIS change object IDs on maps during each release. This means that maps need to re-indexed on each map release. This can be a lengthy process. BIS are currently looking at ways to address this.

h2. Pre-defined placement of CQB, OPFOR etc

In MSO, we used a mix of mechanism to place AI. Both pre-defined and dynamic placement of AI was used. The impact of dynamic placement was that it required performance impacting loops or checks for player positions. Dynamic AI placement although useful for ambient enemy (CQB) could impact player immersion.

In ALiVE enemy positions are set at the beginning of any mission (or loaded from the DB). Without this, the player's sense of immersion is impacted if groups of AI appear from different locations on server restart. There is an obvious performance gain as the spawning of AI is controlled centrally by the profiles system, rather than multiple AI modules running checks for player location.

h2. Caching vs Profiles

In MSO, we experimented with a number of community caching scripts. None of them fit with everything we wanted to do, so we mixed and matched as necessary. Each had their drawbacks though.

In ALiVE, we moved to ARJay's "profile" system. The profile system is much more effective than caching in that it can continue to simulate units even when they are despawned. The system also allows for all modules to use it and benefit from a common and performant "caching" system. Profiles does not suffer from the common issues typical caching scripts have. Profiles can do virtual simulation, captures group formation and position, support for vehicles, unit or vehicle state is captured etc etc.

h2. Object Oriented SQF

MSO did not use a common approach to module design. This caused a number of issues around module integration and framework.

With ALiVE, an object based approach to modules in ALiVE would provide a common framework for developers and integration between modules and common systems (data for example). In addition there was an expectation that A3 may support Java. An OO approach would make it simpler to move to a more common programming language.

The con to this approach is that SQF does not support OO. In addition, SQF scripters may not be comfortable working with an OO approach.

The intent is to try to follow OO guidelines, although this may not be practical for all developers.