Cet article récapitule les différents points qu'il est important de prendre en compte avant de se lancer dans un projet. Ce n'est pas un guide de référence mais plutôt quelques pistes et conseils qui vous aideront à ne pas vous lancer tête baissée dans votre nouveau projet.
Ca y est, vous avez eu une nouvelle idée. Elle est claire dans votre esprit, et vous avez déjà des tas d'idées : vous allez commencer le développement. Mais êtes-vous réellement prêt ?
Dans ce paragraphe, je récapitule certaines étapes par lesquels vous devriez passer avant de commencer la programmation. Plus votre projet est ambitieux, plus ces points deviennent indispensable et plus vous devrez faire preuve de rigueur, sans quoi votre projet tombera à l'eau très vite, comme 95% des projets amateurs.
Tout d'abord, sachez que si tout vous parait clair dans votre tête, cela ne suffit pas pour vous lancer. Vous aurez sans doute besoin de recruter d'autres personnes, et même si ce n'est pas le cas il est important d'avoir par écrit toutes les spécifications de votre projet. Vous n'avez pas pensé à tout, profitez donc de vos idées pour rédiger le cahier des charges. Inutile d'être trop précis, néanmoins vous ne devez cacher aucune information utile, aucun menu ou principe du jeu ne doit paraître obscur à celui qui lira ce document. Ce doit être une référence pour le développement, sans être forcément figé : vous pourrez très bien y apporter des modifications plus tard, en accord avec le reste de l'équipe.
On voit souvent des personnes cacher des informations pourtant cruciales du gameplay de peur de “spoiler” en racontant des éléments sensés rester secrets de l'histoire. Ceci est une mauvaise idée, tout d'abord parce que toute l'équipe devra être au courant, et aussi parce qu'un cahier des charges incomplet n'a aucun intérêt pour les personnes examinant votre projet en vue de poster une candidature.
De préférence, utilisez un document texte, par exemple avec OpenOffice.org ou en HTML, mais pas un site web complexe qui nuirait à la clarté de ce qui doit rester un simple document.
Cette étape est importante aussi : il s'agit éventuellement de répartir les tâches, mais aussi de réaliser les diagrammes UML qui deviendront vite indispensables aux programmeurs. Avoir une organisation claire est précise de votre projet vous fera gagner beaucoup de temps, que ce soit lors de l'ajout de nouvelles fonctionnalités ou en cas de debug.
Vous pouvez utiliser pour cela des logiciels comme ArgoUML ou BOUML.
Si vous envisager de travailler à plusieurs, ce qui est très souvent le cas, vous aurez besoin de pouvoir travailler conjointement sur les sources du projet. Pour cela, un système de contrôle de version comme Subversion (qui remplace CVS) vous sera très utile. Cela vous permettra de rendre (ou non) la dernière version (et toutes les autres) accessibles à tout le monde, de travailler à plusieurs sur le code, et de garder un historique de toutes les modifications apportées au projet.
Si vous avez besoin d'un repository SVN, n'hésitez pas à nous contacter, notamment via IRC. Les règles à respecter pour l'utilisation du serveur Subversion sont disponibles ici : règles du serveur subversion.
Vous pouvez évidement utiliser ce wiki pour y présenter vos projets, il est fait pour ça ; ajoutez-le à la page projets et créer des nouvelles pages si vous voulez, par exemple mon_projet:sources, mon_projet:documentation, …
Afin de permettre à tout le monde de compiler votre projet, le cas échéant, vous pouvez utiliser les célèbres autotools, ou simplement un ou plusieurs Makefiles.
En documentant vos sources, vous permettez à n'importe qui de pouvoir accéder rapidement à toutes les informations voulues sur un fichier, une classe, un fonction, etc. Cela est très utile, même pour vous, quand votre code commencera à prendre de l'ampleur. Pour cela, vous pouvez utiliser Doxygen qui peut générer une documentation très complète à partir de vos sources.
En partant de documents clairs et précis, en utilisant des outils pour gérer le travail à plusieurs, en générant de la documentation à partir de vos sources, vous augmentez énormément votre efficacité et diminuez de manière très significative vos chances d'échouer. Un projet propre est un projet qui ne peut pas tomber à l'eau, même si certaines parties du code doivent être refaites, même si l'équipe change, car vous vous serez donné les moyens de réussir.