Skip to content

Latest commit

 

History

History
120 lines (76 loc) · 4.11 KB

CONTRIBUTING.md

File metadata and controls

120 lines (76 loc) · 4.11 KB

Contributing to Digital Extinction

Suggesting Changes

  1. Start an informal discussions.
  2. Open a formal issue.

Making Changes

  1. First, discuss any non-trivial or potentially controversial changes in our Discussions.

    You can skip this step if you are basing you changes on an already concluded discussion or an issue.

  2. Implement the changes. Do not forget to include appropriate unit tests and, when possible, thoroughly test you changes manually.

  3. Open a pull request (PR).

  4. @Indy2222 and the community review the PR. During the review process, the PR might be accepted right away, changes might be requested or it might be rejected.

Development Process

  • main branch is considered stable. In theory, it should be possible to release a new version from the branch at any time.

  • The development process is incremental. There are no final or big versions.

  • Release train: after version 0.1 is released, a new version is released every 6 weeks.

Coding Style

  • We are limiting the amount of unsafe code to the very minimum. The same principle applies to complex architecture or code patterns.

    A lot of the ergonomy and performance gains unlocked by unsafe or complex code are already delivered by Bevy and its API.

Getting Oriented

The game is split into multiple crates, each implementing part of the game logic. This repository contains a Cargo workspace which consists of all the sub-crates.

The intention is:

  • each crate is small, simple and self contained,
  • the public API of each crate is small or empty,
  • most of the crates expose a Bevy PluginGroup – inter-crate interaction is handled via Bevy's ECS & events,
  • the crate inter-dependencies form an orderly DAG.

Topologically sorted crates:

  • de_uom – type safe units of measurements.

  • core – various simple core utilities, structs, and so on. These are used across many different crates.

  • map – map (de)serialization, validation and representation functionalities.

  • terrain – functionality related to game terrain.

  • objects – caching of object on the game map.

  • index – spatial index of all solid entities in the game.

  • signs – various world space UI signs in Digital Extinction. For example health bars, arrows, and so on.

  • spawner – object spawning, drafting and construction.

  • camera

  • loader – map loading logic.

  • pathing – global path finding and path (re)scheduling.

  • movement – entity movement, local dynamic obstacle avoidance, kinematics and similar.

  • behaviour – unit level behaviour and AI.

  • combat – attacking, projectile & laser simulation and similar.

  • ui – 2D in game UI.

  • controller – handling of user input.

Bevy Schedule Stages

See de_core::stages::GameStage.

Coordinate Systems

3D XYZ world coordinates are right handed. Mean sea level (MSL) plane lies on XZ axes. Y axis points upwards.

2D map coordinates X (longitude) Y (latitude) map to 3D world coordinates X and -Z respectively. Always use module de_core::projection for projection onto MSL plane or conversion between 3D world coordinates and 2D map coordinates.

Geometry & Linear Algebra

Glam is used as the primary linear algebra crate.

Parry is used for collision detection and geometry. Parry is using Nalgebra for linear algebra, thus Nalgebra is used in various places where usage of Glam would lead to frequent back and forth conversions.