Dev. information (Fr)

Sur cette page, j’explique les étapes à respecter lors d’un developpement d’un projet logistique qu’il s’agisse d’un jeux, un logiciel ou tout autre produit.

Étapes importantes lors de développement d’un projet

Dans l’industrie informatique de logistique, il existe une façon de procéder que toutes les entreprises suit méticuleusement. Il s’agit d’une procédure de développement standardisée qui consiste à publier un produit au grand public lorsque celui-ci franchit une étape importante de son développement. Pour un jeu, en ce qui concerne le développement de maps, mods, skins, etc les auteurs de ces oeuvres ont tout intérêt à suivre cette façon de procéder afin que le grand public sache à quoi s’attendre avant même d’utiliser le produit. Voici donc la description de chacune des étapes ainsi que la nomenclature standardisée. Prendre note que pour mon exemple, il s’agit d’une carte de type Deathmatch valable pour nimporte lequel jeux supportant ce type de jouabilité :

Alpha (A)

DM-Exemple-A1 ou DM-Exemple_A1 ou DM-Exemple-Alpha1

Cette étape est celle ou le produit prend forme. C’est là ou tout est mis en place. C’est une version ‘légère’, ‘abrégée’ voir ‘rudimentaire’ où seulement les formes (layout) puis les principaux éléments comme les armes, armures, les points de vie, etc sont mis en place. C’est à cette étape ou la jouabilité, la fluidité est mis à l’épreuve & se doit d’être efficace & solide avant de paser à létape suivante.

Beta (B)

DM-Exemple-B1 ou DM-Exemple_B1 ou DM-Exemple-Beta1

Cette étape consiste à ‘habiller’, ‘armoniser’ voir ‘concrétiser’ les formes rudimentaires. C’est là ou on définit le theme, on ajoute la décoration, la musique, les effets d’ambiance, etc. Bref, tout ce qui est visible & audible. On définit aussi des zones ou on ne veut pas que le joueur puisse accéder ainsi que tout ce qui peut frêner, ralentir, bloquer le mouvement du joueur d’une façon ou d’une autre en ajustant les collisions & en mettant en place des volumes de blocage qui vont fournir au joueur une expérience fluide en enrayant tout obstacle potentiel fournissant la meilleur jouabilité possible. On essaie autant que possible d’éliminer tous bogues & tout ce qui peut être nuisible à l’expérience.

Release Candidate (RC)

DM-Exemple-RC1 ou DM-Exemple_RC1 ou DM-Exemple-ReleaseCandidate1

L’étape cruciale ! Cette étape sert principalement à corriger tout derniers bogues, optimiser la carte le plus possible & bien entendu documenter le tout.

Final

DM-Exemple

C’est maintenant la version du produit la plus optimisée, poli & la moins boguée. Elle est donc la version 1.0. Il se peut qu’il y ait des correctifs à appliquer à cette version. Pour tout autre version subséquente il est recommandée de ne pas utiliser le même nom de fichier. La formule commune mais non oobligatoire est d’ajoûter un ‘v’ qui signifie ‘version’ puis le numéro de version comme 1.1, 1.01, 2.0 etc. Ce qui devrait donner en principe DM-Exemplev11, DM-Exemplev101, DM-Exemplev20 ou simplement DM-Exemple11, etc.

Convention de nom de carte

Pour ceux qui se demandent à quoi serve les acronymes (MapType-MapNom-Acronyme), voici ceux les plus communément utilisés :

CE = Competitive Edition, Competition Edition

FE = Fixed Edition

LE = League Edition, Light Edition

NE = Night Edition

PE = Physics Edition (pour les cartes vidéo NVidia supportant les instructions ‘Physics’)

RE = Revised Edition, Revisited Edition, Rereleased Edition

SE = Second Edition, Special Edition, Spooky Edition

WE = Winter Edition