Skip to content

Home

Jump to bottom
friznit edited this page Jul 3, 2015 · 2 revisions

Terms of Reference

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, a 'professionally' managed development project.

Our mission remains 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

  • Deliver a good quality mod that is easy to use, with regular updates and regular tangible improvements.
  • Agreed Release Schedules to help focus our limited resource on delivering finished modules at production quality.

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 using CouchDB (possible options for local DB in future)
  • Profile System vs traditional group caching
  • Pre-defined map indicies vs Dynamic Objectives Creation (enforced by "The Altis Issue")
  • Object Oriented SQF

Rules of Engagement

  • Direction is determined by team consensus and we stick to the priorities agreed.
  • There is a healthy respect for length of service and actual work done that determines weight of "vote".
  • We are a laid back bunch and we work very hard to avoid dramas. If we disagree, we park it until someone else can mediate.
  • We all have commitments and that is respected. There's no pressure around deadlines.
  • We are not in it for the money, competition or BIF fame. We prefer to help other community mods however similar they may seem are to ours.
  • We pride ourselves on being helpful, polite and prompt in our support channels. Everyone mucks in (but tagging is a legitimate support methodology!)
  • Code/work committed needs to fit with existing plumbing and respect the work of others.
  • We have a vast amount of combined experience but no single one of us knows it all.

Contributors and New Team Candidates

Various levels of participation. Only full team members have a vote in the overall direction of ALiVE. Core team hold project management roles.

  • Consultants & Closed Testers - Non-code contributing folks that may do a number of things for the mod (testing, art, military advice, models etc)
  • Associate Code Contributors - Typically new developers or developers that simply want to donate code to the cause.
  • Associate ALiVE Module Developer - Developer that has agreed to contribute and continue to work a specific module
  • Full Team Member - Developer or other role working on the mod longer than 3 months
  • Core Team Member - Developer or other role working on the mod longer than 6 months and with a specific responsibility.

Important concepts that prospective contributors and team members must understand:

  • Any code submitted to the ALiVE codebase will be considered wholly part of ALiVE, subject to the same license and owned by the ALiVE mod team.
  • Understandably everyone has their own pet project but we will stick to the current roadmap and inject fresh ideas at the appropriate time.
  • All ALiVE code must be maintained in the official ALiVE code repo and no separate public code repos created, so we can maintain governance and control the maint & support of our codebase during development.
  • This license and repo policy may change after we have finished development and achieved GA Release 1.0
Clone this wiki locally