Cette première partie va faire une analyse des erreurs commises lors de la première version, de comment les corriger, et va développer des réflexions sur la meilleur façon de faire pour arrivé à développer la V2.

Pour commencer, une petite présentation:
Sombre Destin est un jeu de Gestion et de Stratégie. Un « civilization » like. On dirige un peuple de l’âge de pierre jusqu’à un âge avancé (mais toujours orienté fantasy même si cela peut tourner vers la science-fantasy)
Le joueur commence avec un colon qui fondera sa première ville. Il devra bien gérer son peuple pour pouvoir faire évoluer son peuple mais également prospérer et fonder de nouvelles villes dans le monde.
Sombre Destin était un véritable « civilization » dans le sens qu’il y a une carte du monde (allant jusqu’à 750*750 cases), que les joueurs commençaient sur une position aléatoire dessus. Ils pouvaient fonder leurs villes où bon leur semblaient. L’environnement alentour était très important, il permettait à la ville de se développer. La mer pour les unités maritimes, les montagnes pour avoir diverses ressources comme le fer ou la pierre. Les plaines pour la nourriture, les forêts pour le bois.
Le joueur pouvait modifier cet environnement et construire diverses infrastructures, comme des routes, pour l’aider.

Pourquoi une version 2?
La V1 date de 2002, a été créée au début avec php3.
Les techniques ayant évolué, ainsi que mon expérience dans la conception de ce genre de jeu, le jeu est devenu aujourd’hui obsolète. Actuellement, le code est très vieux et demanderait beaucoup de temps pour être remis à niveau. De plus, le temps faisant son œuvre, il m’est apparu de nouvelles techniques pour le gérer plus facilement et plus efficacement.
Les modifications qui permettraient de rendre la première version, vraiment finie, demanderaient plus de temps que d’en recommencer une nouvelle à partir de zéro. J’ai donc décidé de tout reprendre à au début et de faire passer sombre destin en version 2.

Modifications entre les versions
Je ne voulais pas non plus reprendre exactement ce que j’ai fait pour la V1. N’étant pas satisfait du résultat de la V1 et ayant de nombreuses idées qui ne cadraient pas avec cette ancienne version, beaucoup de choses vont changer.
– Le jeu ne sera plus massivement multi joueur mais uniquement multijoueur. Au lieux d’avoir une carte avec 1000 joueurs, le jeu sera divisé en parties ou plus ou moins 200 joueurs pourront jouer ensembles. Des réflexions sur ce système ont été faites, comme par exemple enrayer la désertion d’une partie par le départ des joueurs en autorisant de nouveaux joueurs à intégrer une partie déjà commencée.
– Le jeu sera toujours tour par tour. Mais les tours dans la V1 étaient lancés par un Cron, dans la V2, ce seront les joueurs qui lanceront les tours. Les tours pourront être paramétrés par les joueurs pour des parties plus rapides ou plus lentes, au choix.
– LA V2 se rapprochera plus de la saga civilization. Car dans la V1, le jeu gérait numériquement les ressources, un peu, comme un mélange avec les jeux heroes of might and magic. La gestion des villes, des unités et des bâtiments sera également plus proche des civilizations.

Objectifs
Les objectifs à court terme sont de faire un moteur graphique en 3D isométrique en plein écran et un moteur de jeu modulaire qui me permettrait de pouvoir ajouter tout élément du jeu (bâtiment, unité, nouvelle action pour les unités, etc…) sans rentrer une seule ligne de code.
Le moteur de jeu sera très proche de ce que permet le jeu « civilization 4 » en terme de game play.
Le jeu sera un jeu qui se jouera par partie. Chaque serveur contiendra un nombre fini de parties. Il est donc prévu de faire en sorte que le moteur de jeu soit muti serveur pour pouvoir permettre un nombre illimité de parties. Ce système devra être modulaire également, que l’on ne doive pas rentrer dans le code pour créer, modifier ou effacer des parties ou des serveurs de jeux.
Le dernier objectif est de permettre aux joueurs de créer leurs maps. Mais également d’avoir des parties « maîtrisées » par d’autres joueurs. Ceci afin de ne pas avoir que des partie où l’intérêt est de tuer tous les autres joueurs. Il y aura aussi des parties à thème automatisées qui donneront des objectif divers et variés aux joueurs.

Une autre façon de travailler:
Une erreur que j’ai commise dans la V1, a été d’autoriser dés le début de la conception, les joueurs à s’inscrire. Cela a beaucoup ralenti le projet. Car je devais m’occuper des joueurs et du jeu. Le jeu n’étant pas fini, les déséquilibres qu’entraînaient certaines options non implémentées posaient constamment problèmes pour les joueurs. Les résoudre et s’occuper de la communauté prenaient énormément de temps, du temps qui aurait pu être utilisé pour la conception.
J’ai fait un choix différent pour la conception de cette V2.

– En premier, de ne pas donner l’accès au jeu, tant que le noyau dur du jeu ne sera pas suffisant pour jouer correctement et suffisamment. Mon objectif , c’est de ne pas accepter d’inscription tant que les joueurs ne pourront pas jouer une partie (limitée) complète. Bref, commencer une partie et la finir avec des conditions de victoires simples.
J’ai donc divisé les étapes de conceptions par rapport à des besoins en joueur.
L’Alpha 1: Pour tester le noyaux dur, maximum 10 personnes.
L’Alpha 2: Quand le noyau dur à été éprouvé et débugué, autoriser une cinquantaine de personnes pour tester le jeu ainsi que le site qui gère les parties. On continue la conception pour que toutes les fonctionnalités standards soit implémentées.
La béta fermée: Accepter des pré-inscriptions suivant les besoins. A ce stade, le jeu est déjà fini au niveau programmation. Il ne reste qu’à ajouter les paramètres supplémentaires du jeu (bâtiments, unités, etc…) tester et équilibrer le jeu.
La béta ouverte: Là on ouvre le robinet, tout le monde peut s’inscrire mais il y a encore des travaux. Dernière ligne droite, dernières retouches avant le lancement officiel du jeu en version 1.0

– Deuxièmement, au niveau de la programmation, une certaine façon de travailler s’imposait également. Dans la V1, je programmais sur l’envie que j’avais de voir une fonctionnalité ou bien c’était les joueurs qui me demandaient une nouvelle fonctionnalité. Cette façon chaotique ne donne pas de bons résultats.
A présent, je me suis donné une méthodologie stricte inspirée du monde du logiciel libre.
Je programme par version. Chaque version stable sera paire (0,02 ; 0,04; 0,06;etc…). Ces versions ont des objectif clairs et déjà prédéfinis à l’avance. J’ai mis par exemple que les religions devraient être programmées pour la version 0,04. Cette version comptera également la montée de niveau des unités. Que la version 0,06 devrait voir la magie, etc…
Entre les versions stables, il y a les versions instables, de préparation, les version impaires (0,01; 0,03; etc…). Ces versions seront accessibles que par une minorité de testeurs et contiendront les nouveautés en construction des versions supérieures. La version 0,03 devra voir le jour des religions, des tests effectués sur les scripts et de l’équilibre de celle ci.
Pour qu’une version soit définie comme stable, il faut que la version instable possède tous les pré requis définis dans la version paire supérieure, mais également qu’elle soit entièrement débuguée. Aucun bug ne doit subsister pour une version stable.
Bien sûr c’est utopique, il y aura toujours des bugs qui resurgiront d’une version antérieur. Mais en s’imposant cette façon de travailler, j’espère réduire au maximum les risques.

En résumer voici comment cela va se passer:
– Programmation de la version impaire (instable) suivant les objectifs.
– Test pendant un temps de la version instable avec toutes les fonctionnalités.
– Débuguage
– Quand plus aucun bug n’est répertorié, passage de la version instable en version stable.
– Commencement de la version instable suivante.

C’est, je pense, la meilleur façon de procéder au niveau de l’organisation, mais également de la gestion des bugs. Cela empêchera de voir traîner des bugs de version en version. Un autre avantage, les objectifs étant publiques, les joueurs savent ou on en est dans la version ce qui arrive dans les versions futures et quand cela pourra arriver. Ca permet d’éviter les demandes des joueurs pour savoir quand tel chose sera faite.

Une autre façon de voir les choses:
Une chose qui alourdi la programmation d’un jeu comme SD, c’est qu’ajouter de nouvelles fonctionnalités est très lourd, trop lourd. En effet, chaque unité(travailleur, soldat, ou colon par exemple) peut faire diverses actions. Il fallait pas mal de choses:

1: Il y avait une page, pour tester, voir si l’unité peut faire une action. Exemple, tester si il y a une ville en dessous d’elle pour pouvoir l’attaquer ou voir si il y a un terrain forêt pour pouvoir la couper. Tous les tests de toute les actions se trouvaient dedans. 2: Il y avait la page d’ « include » qui contenait la direction de toute les pages de script des actions. 3: Le script php qui se trouvait bien classé dans un dossier.
A chaque fois que l’on voulait ajouter une fonctionnalité, il fallait modifier la page d’action (1) en rajoutant de la lourdeur en mettant des tests supplémentaires (et en faisant bien attention car un problème pouvait facilement faire des bugs). Puis, modifier le fichier d’include(2) pour donner la direction de la page de l’action. Puis enfin, créer le fichier de l’action(3) contenant tout ce que l’action doit faire concrètement.
Cette façon de faire est classique je pense, mais trop lourde à mon goût. J’ai eu l’idée de programmer ce genre de chose par « modules ».

Comment cela fonctionne?
La direction des pages n’est plus stockée dans un fichier d’inclusion, mais dans une base de données. L’ID de l’action est enregistrée ainsi que la direction de la page php. Le lancement de la page se fera grâce à la technologie Ajax. Ce qui est stocké dans une table, ce sont également les conditions d’acceptation d’une action.
Il y a toujours la page d’action, mais celle ci contient tous les tests possibles et imaginables. Le script va chercher les actions possibles pour l’unité, les tester sous toutes les conditions, et si c’est le cas, aller chercher la direction de la page dans la table correspondante et seulement après cela, lancer la page.
Pour cette façon de faire, l’ajout de fonctionnalités est beaucoup plus simple et rapide. On ajoute l’action et la direction de la page dans la table. On ajoute les conditions dans l’autre table (tout cela fonctionne via une interface admin qui permet ce genre d’ajouts ou de modifications en moins de 2 minutes). Puis on crée le fichier php qui va faire l’action.
Cette méthode demande une page en moins (celle qui inclus les directions des pages). Pour l’ajout de chaque action, aucune manipulation du code du jeu n’est requis. En plus de tout cela, le temps d’exécution d’une action est largement diminué.

En pensant par modules pour tout (que ça soit les unités, mais j’ai reproduit le même schéma sur tout le reste comme les bâtiments par exemple), je facilite tout ajout futur dans le jeu. Dés la conception de la version 0,02 qui consistera à la création du noyau, c’est à dire le code de base qui gérera les modules, le jeu ne requerra plus aucune modification dans le code du noyau mais uniquement dans une succession d’ajout de fichiers et d’enregistrements dans la base de données.

Conclusion:
En résumé :
– Avoir des objectifs clair et précis, réalisables. Et surtout, le tout à court terme.
– Avoir une façon de travailler séquentielle, ne pas s’éparpiller dans le travail.
– Une programmation modulaire pour ne plus devoir revenir sans arrêt dans le code pour n’importe quelle modification.

Après avoir fixé les objectifs, avoir donné une ligne de conduite au projet, la première étape : L’éditeur de carte.

… A suivre…