Version 43 (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.
  • The single-word shorthand for the 403 Aurelius project shall be "Aurelius", and not "403". Thus, the steamapps sourcemods folder housing the project shall be named "aurelius".
    • Rationale: The word part of the name is more readable as a name than just the number.
  • In cases where a minimal character count is needed, the extreme minimal shorthand for the 403 Aurelius project should be "aur".
    • Rationale: This is an extension of the rule above, but further extended to the cases where we require a short set of characters to describe the project. For instance, it may serve as a short prefix for other naming conventions (like the map naming convention below).
  • All dates written in shorthand form must be of the following format: YYYY.MM.DD
    • Rationale: Due to the international nature of the team, everyone uses a different format. To ensure that there is never any confusion within the team, shorthand date numbers in this project will be written in order from largest unit to smallest unit: Year, Month, Day.
  • All written times must include BOTH a time zone, and AM/PM. The AM/PM may be omitted if the time is unambiguously in 24-hour format.
    • Rationale: Due to the international nature of the team, everyone is in a different time zone. Also, not including AM/PM is just asking for confusion, so please just do it.
  • 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 is done. Production of assets or levels must not be started until a viable development plan has been produced for the asset/level. Pre-Alpha ends when basic pre-production planning for all assets and levels has been completed, and all assets and levels have prototype versions available.
Alpha
The stage of development during which production has started in full, and prototypes of levels and assets are being iterated on. Voice acting should not be done at this point in development, although placeholder voice acting assets may be done. Gameplay changes should be tested and iterated on during this phase.
Beta
The stage of development during which general gameplay is determined to be finalized. The script should also be finalized at this point, so voice acting assets must be recorded at some point during this stage. Gameplay changes (and script changes) during this phase should not occur, and if they do occur, the changes must be extremely minor. (An exception may be made for script changes due to improv by voice actors.) 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 guideline 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.
  • If, during the course of level design, a level designer deviates from the layout and/or plans for a given level, 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:
    • aur_zXX, where "XX" is the floor number featured in the map, and "z" is the letter "a" if the map takes place during the ascension portion of the game (Act 1), or "d" if the map takes place during the descent portion of the game (Act 2). For example, the level featuring the 25th floor of the building during Act 1 shall be named aur_a25.
    • 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 during Act 2 shall be named aur_d26.
    • If a map features a single-digit floor, the number must have a leading 0. For example, the Act 1 lobby map shall be named aur_a01. This allows the maps to retain their order when sorted ASCIIbetically.
    • The prologue map featuring the garage and the apartment is an exception to this rule-- it shall be named aur_a00. (Tentative-- subject to change.)
    • The map featuring the Caecus Lair is also an exception to this rule-- it shall be named aur_lair.
    • Rationale: Naming the maps after the floors and whether they take place during Act 1 or Act 2 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 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.
  • If there is a named character NPC, that NPC's entity name should simply be the name of that character. If the character corresponds to multiple NPC entities within the same level, their entity names should still be named after their name in the script, but suffixes should be added to differentiate them.
    • Rationale: This makes it so level designers are never confused when they encounter an NPC called "GRD07_BATHROOMBREAK" and have absolutely no idea that he actually corresponds to "Otis" in the script. In the map, he should just be called "otis". In addition, this allows choreographers to not have to guess or look up the names of the actors in any choreographed scene.
  • Linearly-moving elements should use func_door textured in tools/toolsuseful, rather than using a func_tracktrain.
    • Rationale: func_tracktrain is annoying as hell and very finicky. If the movement is simply linear between two well-defined points, a func_door works perfectly fine with minimal effort.

2D Art

  • Environment textures should compliment brushwork dimensions.
    • Rationale: Odd dimensions can lead to textures aligning badly to brushwork, or forcing brushwork to go off-grid to align to the texture.
  • VTF compression formats must be carefully selected instead of chosen at random.
    • Rationale: Using the incorrect format results in bad texture quality, or unnecessarily bloated filesize.
  • For materials intended for use on brushwork surfaces, self-shadowing bump maps shall be used instead of normal maps.
    • Rationale: All normal maps can be converted to self-shadowing bump maps for greater rendering efficiency, so in the worst case, SSBumps look exactly the same as normal maps but render faster. However, SSBumps also give us the option to encode directional lighting responsiveness, which gives them the ability to look much better than normal maps in the best case.

3D Art

  • Prop dimensions should be made using powers of two.
    • Rationale: Using powers of two (or dimensions reachable by using multiples of them, such as 24) allows props to fit into brushwork seamlessly. Especially for modular props such as rails or pipes.

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.