-
Derniers articles
Lectures conseillées
-
Derniers commentaires
-
Créer son jeu en ligne de A à Z : le cahier des charges
Voici un document indispensable avant de commencer à programmer votre site internet : le cahier des charges !
Dans ce document, vous devrez détailler tout votre jeu, toutes les fonctionnalités, la manière dont elles fonctionnent et ce que cela implique. Cela vous permettra ensuite de faire un algorithme de chacune des pages.
Par exemple :
• Module de connexion : il contient deux champs : un champ texte pour le pseudo (limité à 30 caractères) et un champ password pour le mot de passe (le mot de passe peut contenir des chiffres, des lettres majuscules et des lettres minuscules). Lorsque le joueur, après avoir rempli ce court formulaire, clique sur le bouton « Se connecter », on vérifie que le membre existe bien et que le mot de passe correspond au pseudo.
Si oui, on connecte le membre et on le redirige sur la page d’accueil du membre.
Si non, on affiche le message d’erreur suivant « Les identifiants sont incorrects », et on le redirige à nouveau sur le formulaire.
Faites de même pour tous les modules de votre jeu. Cela peut paraitre rébarbatif et vous aurez peut-être l’impression de perdre votre temps, mais sachez que cela vous fera gagner vraiment énormément de temps par la suite puisque vous saurez exactement ce que vous devrez programmer et dans quel ordre.
De plus, si vous travaillez en équipe, cela permet à chacun d’avoir une vision très complète du jeu et de pouvoir reprendre le développement à n’importe quelle étape du jeu.
Vous pouvez également y glisser des zonings, c’est-à-dire des maquettes très simplifiées de votre design afin que toute l’équipe connaissent bien l’arborescence du jeu et ainsi d’obtenir un résultat uniforme et ergonomique.
Sans cahier des charges, vous risquez de vous perdre dans la programmation du jeu, de devoir recoder des pages car elles ne seront pas adaptées au reste du jeu, mais aussi d’oublier certaines fonctionnalités et d’engendrer des bugs ou des failles car vous n’aurez pas pensé à tous les cas.
Donc pensez à prendre bien le temps de faire cette étape avant d’aller plus loin dans votre projet. Et puis, si vous n’arrivez pas à le terminer, cela peut traduire un manque de rigueur et de motivation. Or si vous manquez de rigueur et de motivation sur le long terme, votre jeu n’a que peu de chances d’ouvrir.
Allez, à vos traitements de texte et bon courage !
Le CdC ne doit pas être vu comme « ch**t » à réaliser: il peut également s’agir de notes, genre brouillon, de schémas, et de diagrammes.
Un CdC quantitatif n’est pas forcément utile (« champ texte limité à 30 caractères » n’est parfois pas plus utile que « un champ texte pour le pseudo »). En revanche, il faut effectivement indiquer qu’il y aura un champ texte, dont, d’ailleurs, il faudra souvent vérifier le contenu (pour éviter qu’un pseudo mal formé, avec des caractères particuliers, ne plante la requète d’insertion dans la base de données).
En effet, lorsque l’on travaille seul sur le projet, le CDC n’a pas besoin d’être formel. Par exemple moi je fusionne systématiquement le CDC Fonctionnel du CDC Technique (ça me fait penser qu’il faudrait que j’édite cet article pour en parler).
En revanche, lorsqu’on travaille en équipe il est important d’avoir un document unique (ou deux, par exemple moi j’en fais un pour le code et un pour le graphisme) et bien rédigé afin que tout le monde comprenne facilement ce qu’il y a à faire et n’ait pas besoin de fouiller parmi de multiples dossiers pour trouver l’information qu’il cherche.
Concernant mon exemple du « champ texte limité à 30 caractères », si j’ai précisé cela c’est pour me faire penser qu’un pseudo ne doit PAS contenir plus de 30 caractères et qu’il faut que je pense à vérifier cela lors de la validation du formulaire.
En revanche, lorsqu’il n’y a pas de maximum (ou qu’on a beaucoup de marge), cela ne sert bien sûr à rien de l’indiquer ^^ Tout dépend de ce que l’on veut obtenir !
Félicitation pour cette information super intéressante. J’aime passer sur votre blog.