On this page, I explain the steps to follow when developing a project software based like a game, a software or other logistical products.

Important steps to follow when working on a project

In the computer industry logistics, there is a way that all companies follow meticulously. It is a standardized development process of publishing product for the general public when it crosses an important step of its development. Regarding the development of maps, mods, skins, etc. The authors of these works are well advised to follow this procedure so that the general public knows what to expect before using the product. Here is the description of each step and the standardized nomenclature. Take note that for my example, I use a regular Deathmatch map type for games that support it and the map title is Example :

Alpha (A)

DM-Example-A1 or DM-Example_A1 or DM-Example-Alpha1

This step is where the product takes shape & where everything is put in place. This consist of rough, rudimentary forms (layout) and the principal elements such as weapons, armors, health, powerups, etc. are introduced. At this stage, gameplay & flow are tested & has to be strong & effective before going to next step.

Beta (B)

DM-Example-B1 or DM-Example_B1 or DM-Example-Beta1

This step is to ‘dress’, ‘harmonize’ the rudimentary forms. This is where the theme is define & where decoration, music, atmosphere, effects, etc. are added. In short, everything visible & audible is there. It also identifies areas you do not want the player to go, get rid of all things that can slow down, block, stop the player movements in one way or another by adjusting collisions & putting blocking volumes to provide the player a fluid experience & the best possible gameplay by getting rid of any potential obstacle. The author also try wherever possible to eliminate all bugs & all things that can be annoying.

Release Candidate (RC)

DM-Example-RC1 or DM-Example_RC1 or DM-Example-ReleaseCandidate1

The crucial step! This step serves mainly to fix any remaining bugs, optimize the map the more as possible & to document everything of course.

Final

DM-Example

Now, it’s the most optimized, polished & the least buggy version. It’s 1.0 version. With time, perhaps there are patches to apply to this version. For any subsequent version it is recommended not to use the same file name. The common formula but not mandatory is to add a ‘v’ which means ‘version’ and the version number like 1.1, 1.01, 2.0 etc. This should in principle give DM-Examplev11, DM-Examplev101, DM-Examplev20 or symply DM-Example11, etc.

Another way of naming files is to add a number to the end of the file name. This procedure is not an industry standard, but it just works. Which for example could be DM-Example001, DM-Example002, DM-Example012 and so on. In all cases, the initial final version shouldn’t contain any number.

Map naming convention

For those who ask themselves what the acronym stands for (MapType-Example-Acronym), here are the most commonly used :

CE = Competitive Edition, Competition Edition

FE = Fixed Edition

FPS = Frame Per Second (stripped down maps to gain more FPS)

LE = League Edition, Light Edition

LG / LGE = Low Gravity Edition

NE = Night Edition

PE = Physics Edition (for maps that support AMD or NVidia generation of GPU Physics capable)

RE = Revised Edition, Revisited Edition, Rereleased Edition

SE = Second Edition, Special Edition, Spooky Edition

WE = Winter Edition

For duel focused maps, the most commonly used way is to add the prefix 1on1 before the map name (MapType-1on1-Example). For example :

CTF-1on1-Example, DM-1on1-Example.