Version 4 (modified by dky, 8 years ago) (diff)

--

403 Aurelius Internal Development Standards

This page lists all relevant standards pertaining to development of the 403 Aurelius project. All developers working on this project MUST adhere to these standards.

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119.

General

  • All work done on this project MUST NOT suck.
    • Rationale: In order to ensure that the project does not suck, it is REQUIRED that all constituent work MUST also not suck.
  • The project MUST be referred to as "403 Aurelius", and not "403 Aurelius Street".
    • Rationale: "403 Aurelius" is a marginally cooler title. Also, this differentiates the project from the actual physical building.
  • Within this wiki, the building itself SHOULD be referred to as "403 Aurelius Street" or alternatively, "The HBC Building".
    • Rationale: This reduces ambiguity between "403 Aurelius" (the project) and "403 Aurelius Street" (the building) within this wiki.
  • All work on the project SHOULD be streamed live to the public.
    • Rationale: This is an open-dev project. It is ideal that all people can see exactly what is being worked on, and when. This helps put our work in context with the rest of the world as it occurs.
  • All work on the project MUST be recorded and posted in a publicly-accessible location.
    • Rationale: As an open-dev project, we would be violating the core philosophy behind the experiment by not posting all work to the public.
  • Development SHOULD occur in four stages, described as follows:
Pre-Alpha
The stage of development during which planning, but not actual production of assets or levels, is done. Production of assets or levels MUST NOT be done during this stage, until a development plan has been produced.
Alpha
The stage of development during which production has started, and prototypes of levels and assets are in progress. Voice acting SHOULD NOT be done at this point in development, although placeholder voice acting assets MAY be done.
Beta
The stage of development during which general gameplay is determined to be finalized. Voice acting assets MUST be recorded at some point during this stage. Gameplay changes during this phase SHOULD NOT occur, and if they do occur, the changes MUST be extremely minor. During this stage, most development will probably be focused on aesthetic refinement.
Release Candidate
The stage of development during which the project is in a state that is potentially releasable to the general public. Any Release Candidate build MAY be released to the public at any given point, if deemed to have no game-breaking issues (although only ONE build SHALL be marked as a "gold final" and released). If a game-breaking issue is found in any Release Candidate build, that build MUST be disqualified for release. Developers MUST NOT make any changes to the build that are not bug fixes.

Level Design

  • There SHOULD be one map per each floor in the 403 Aurelius Street building. (Tentative-- subject to change.)
    • Rationale: It seems neater this way. Any violations of this rule MUST be discussed among the team of level designers beforehand.
  • Each level MUST have its own wiki page, to act as a design document for that level.
    • Rationale: The wiki provides a nice space to put development plans down. Don't waste it.
  • Level designers MUST NOT start work designing a level until a layout and plan for that level is complete.
    • Rationale: It's far easier to change major elements on paper than it is to tear down and change work that has already been done.
  • If, during the course of level design, a part of the layout and plan is changed, the change MUST be reflected in the layout and plan, i.e. the corresponding design document page on the wiki.
    • Rationale: The design document page MUST never lie about what is actually in the level. Changes MUST, therefore, be documented.
  • All maps MUST follow the following naming convention:
    • aurelius_XX, where XX is the floor number featured in the map. For example, the level featuring the 25th floor of the building SHALL be named aurelius_25.
    • If a floor is featured multiple times in different maps, the map should be suffixed with a letter of the alphabet indicating which version is the version that occurs later, chronologically. For example, if the 31st floor is featured twice, the two maps SHALL be named aurelius_31a and aurelius_31b.
    • If a map features multiple levels, the map SHALL be named after the lowest level featured. For example, a map featuring floors 26 and 27 SHALL be named aurelius_26.
    • If a map features a single-digit floor, the number MUST have a leading 0. For example, the lobby map SHALL be named aurelius_01. This allows the maps to retain their order when sorted ASCIIbetically.
    • The prologue map featuring the garage and the apartment is the exception to this rule-- it SHALL be named aurelius_00. (Tentative-- subject to change.)
    • Rationale: Naming the maps after the floors allows us to tell at a glance what the hell the map is about.
  • Level designers SHOULD NOT use a grid size that is smaller than is necessary to actually manipulate geometry or entities. In particular, geometry SHOULD have dimensions that are multiples of powers of 2. Detail geometry and entities are an exception to this guideline.
    • Rationale: The larger the grid, the easier it is to edit. Using as large a grid size as possible, whenever possible, maximizes this advantage.
  • Level designers SHOULD use a default lightmap scale of 32.
    • Rationale: It makes it a LOT easier to optimize lightmaps later on, since the vast majority of lightmap surfaces simply do not require a lightmap scale of 16.
  • Level designers SHOULD use lightmap scales below 16 sparingly.
    • Rationale: Lightmap memory footprints increase roughly quadratically for each unit decrease in scale. This means decreasing lightmap scale by 1 level when the scale is already small results in an absolutely enormous increase in memory size for that surface. We don't want the map file sizes to be huge.
  • Level designers SHOULD NOT shift-clone or copy-paste cubemaps.
    • Rationale: Accident avoidance-- If a cubemap has a high resolution, shift-cloning or copy-pasting that cubemap could mean accidentally causing the new resulting cubemaps to also have high resolution. This can balloon file size dramatically, and is a pain to fix after the fact.

2D Art

3D Art

Lore

  • Caecus members SHOULD refer to the Caecus organization as /kaɪkus/. Non-Caecus members SHOULD refer to the organization as /kaɪkəs/ or /keɪkəs/.
    • Rationale: This is a subtle way to hint (but not necessarily prove) that a particular character may be affiliated with the organization.