Skip to content
friznit edited this page May 11, 2016 · 3 revisions

Background

ALiVE is the successor to ArmA2's Multi Session Operations (MSO). The aim is to create a dynamic, living environment in which the player can take part in persistent missions across multiple game sessions including server restarts (equivalent to MP save games). It provides the flexibility to deploy on operations in various tactical situations with the minimum of input by the mission maker. It also caters for different game types including TvT, Coop, small teams with AI or large milsim groups whilst also delivering the support assets required for long term ops, such as Offensive Support, Logistics and website data for Situation Reports and After Action Reviews.

Whilst we learnt a hell of a lot creating MSO, it grew into an unmanageable beast with lots of little offshoot projects that were never properly integrated. We spent as much time regression testing as we did developing new content - the infamous 'code soup'. ALiVE is a completely fresh start with clearly defined goals, strict coding standards, enforced discipline to stick to the agreed roadmap and ensure everything we deliver is properly integrated and as efficient as we can make it. In short, it is a professionally managed development project.

Our mission is to create a system that brings ArmA3 to life with the minimum of effort by the mission maker. Key concepts are an intuitive, easy to use, modular system, seamless integration and massive flexibility.

Objectives

  • Accessible, intuitive and flexible modular mission making framework
  • Credibly realistic design reflecting real world military constructs
  • Players must be able to impact every aspect of the battlespace - no magic spawning!

Design Decisions

Key design decisions made early in the project to maintain a manageable scope both during dev and later support

  • Use a centralised DB to facilitate end user support and a collective web based service (but leave open the option for local DB in future)
  • Flexible and scalable virtual profile system vs traditional group caching
  • Pre-defined map indicies vs Dynamic Objectives Creation (enforced by "The Altis Issue" which crashed ArmA)
  • Object Oriented SQF

Rules of Engagement

  • We pride ourselves on being helpful, polite and prompt in our support channels.
  • Code/work committed needs to fit with existing plumbing and respect the work of others.
  • All elements of ALiVE must be designed with a real world military construct in mind (e.g. don't simply spawn in a CAS aircraft - it must come from an airbase and have appropriate logistics to keep it operational)
  • We have a vast amount of combined experience but no single one of us knows it all.
  • Wherever possible, all code submitted to the ALiVE codebase will be considered wholly part of ALiVE and subject to the same licence

Forks, Branches, Pull Requests and Merges

  • We aim for a 4 week release window. It's not an exact science.
  • Forks may be released publicly under the same licence but must clearly state they are not an official version of ALiVE. We don't want to confuse things.
  • Branch and Pull Requests to Master will be reviewed by the Core Dev team and merged at their discretion.
  • Release branch will be used for staging prior to official public releases of ALIVE.