Bonjour,
J'avais envie de faire un petit retour d'expérience sur le developpement de mon jeu.
J'espere que cette contribution permettra à ceux qui aiment le developpement de jeu à se poser les bonnes questions et à poursuivre leur effort.
Après quelques premières expériences, sur des petits jeux (snake, asteroid, bomberman, shoot'hem up), je me suis tourné vers l'élaboration d'un jeu 3D.
Mon but est de reproduire un morceau du jeu Eve Online, un mmorpg bien connu. Pourquoi ce choix, d'abord, car j'aime les jeux spatiaux. Ensuite, car c'est un créneau où il y a encore de la place pour s'exprimer.
Enfin, car le nombre de modèle 3D pour produire un jeu, peut être relativement faible par rapport à un jeu med fan par exemple. Un vaisseau, 2 asteroids... et on est parti.
Mon ambition n'est pas de sortir un jeu complet, car le travail est titanesque pour une seule personne, mais c'est surtout d'apprendre, et me faire une expérience sur ce type de jeu.
Si cela abouti à un jeu, et que des joueurs peuvent venir y jouer, cela sera gratifiant évidemment.
Ayant une vie privée et un travail, cela pose quelques contraintes dans mon projet:
-- temps alloué à cette activité : faible.
-- ressource disponible : faible.
De ce constat, des décisions sont à prendre. Je ne peux pas prendre d'engagement auprès d'une équipe, et leur imposer un rythme de travail, que je ne pourrai pas suivre moi même.
Je ne peux que tenter d'intéresser des gens qui souhaitent participer à l'aventure de manière ponctuelle, apportant une pierre à la fois.
Je m'entoure surtout de personne avec qui je peux discuter de gameplay, de gamedesign, pour élaborer les 1eres pierre du jeu (but du jeu, quels sont les mécanismes principaux, les choses qu'on aimerait voir).
Tout est bon à prendre, on triera au fur et à mesure. Avoir de l'ambition.
J'essaye également d'avoir une personne technique avec qui je peux discuter des manières de faire en terme d'algo, ou d'implémentation.
Le second choix est la technologie. Ayant de bonnes compétences en Java, C++ et python, le choix est vaste. Ce qui m'intéresse est de trouver un moteur graphique répondant à mes besoins, et si possible gratuit.
Deux choix s'offrent à moi (parmi tant d'autres) : Ogre (C++) / Panda3d (python).
Comme j'apprécie le python, car la productivité en terme de coding est plus élevé (syntaxe allégé, pas de compilation), j'opte pour un moteur permettant de coder en python.
Sur ce point, après mon retour d'expérience, il est clair que d'autres critères doivent venir alimenter le choix:
-- possibilité de créer un executable joueur facilement (pour pouvoir distribuer votre jeu)
-- technologie qui puisse être hébergé facilement (pour la partie serveur) sur un serveur commercial
-- possibilité d'intégrer facilement des third party (gui, moteur physique, son, réseau,...)
-- vie du moteur (communauté active o/n, release régulière avec patch, ...)
Première étape : montée en compétence sur la partie moteur graphique.
Je passe un peu de temps à tester les fonctionnalités du moteur graphique, et de m'imprégner de ces mécanismes et de ces contraintes.
La conception est fortement marquée par les contraintes du moteur.
Rapidement, je passe à l'étape de la mise en place de la partie réseau. Il est utopique de monter un jeu, et de greffer la partie réseau par dessus.
La conception des classes, et du coding en général doit embarquer la partie réseau comme une contrainte, et donc doit être prise en compte au plus tôt.
Je commence à créer mon premier modèle de classe, avec les classes essentielles (user, character, ...). Je ne m'embête pas pour l'instant avec la persistance. Des fichiers xml me suffisent pour stocker de l'information.
Mon but est d'aller vite est de monter un premier proove of concept.
Une fois que je me sens capable d'aller plus loin, je commence à travailler les concepts du jeu, et j'utilise un wiki pour structurer les différents éléments du jeu.
Il est important de figer quelque part les idées principales, les principaux mécanismes de jeu.
Parmi ceux là, je recommande ces axes de réflexion:
-- Quels sont les buts du jeu atteignable?
-- Quels sont les mécanismes de jeu que vous voulez proposer au joueur (PvP, crafting, trading, ...)
-- Instance de jeu, ou monde global à tout le monde
-- Quelles sont les incidences d'être tué? Qu'est ce que cela implique? Pour moi la gestion de la mort est un élément clef de réflexion.
-- Quels sont les principes d'évolution (histoire, xp, personnelle) que vous souhaitez voir dans votre jeu, et comment se traduisent-ils concrétement?
Clairement, ces questions donnent une orientation forte au jeu, ainsi qu'à la conception des classes de code, et à l'interaction entre celles ci.
Il est indispensable de s'arrêter dans le code, pour répondre à ces questions, et détailler les réponses.
Ensuite, je repars sur le développement, et je commets un grand nombre d'erreurs, et tombe confronté à un grand nombre de difficultés techniques.
J'ai bien avancé sur le maniement du vaisseau et de quelques concepts de base.
Je me rends compte que certains comportements sont durs à gérer à la main, je me dis qu'il me faut intégrer un moteur physique pour gérer les collisions, rebonds, mouvements liés à la gravitation.
Je choisis donc ODE, qui est gratuit et bien connu. Ce fut ma 1ere erreur. Après avoir passé beaucoup de temps à l'appréhender et à le mettre en oeuvre, je me rends compte qu'il est extrémement lourd, mais aussi buggé.
En discutant avec une autre équipe de dev, il me préconise bullet, qui est beaucoup plus léger et plus adapté au jeu. En effet ODE, a vraiment été développé pour de la simulation physique poussée.
Mes besoins correspondent à 10% des fonctionnalités de ODE.
Je passe un temps important en refactoring, pour passer à bullet. 3 mois pour passer à ODE, 2 mois pour passer à bullet. Mauvais choix.
Concernant le gui, mes 1eres fenetres utilisent la librairie native de panda. Les fenêtres sont approximatives. Je choisis de partir sur une librairie spécialisée bien connue : CEGUI.
La prise en main de CEGUI, et la définition d'un thème (très lourd en CEGUI), et mes 1eres fenetre me prend 3 mois environ.
Je me rends compte lors d'une itération, que je ne suis pas capable de générer un executable pour les joueurs avec Cegui en dépendances.
Je tombe sur une autre libraire qui s'appelle librocket, plus légére, et surtout qui s'appuye sur des définitions html, et des classes css. 3 mois pour passer à cegui, 2 mois pour passer à librocket.
Depuis mon vaisseau qui avance dans l'espace et quelques fenêtres, j'ai passé plus de temps à réécrire du code, qu'à en écrire à proprement parler
Il est difficile de garder la motivation dans ces cas là. Mais par chance j'y arrive.
Je décide de commencer à implémenter de réels concepts de jeu (multi connexion, mini PvP,...).
En parallèle je développe un updater de jeu. Je me rends compte que le jeu peut être très lourd, et que si à chaque patch les joueurs doivent télécharger un fichier de plusieurs centaines de mo, cela ne va pas le faire.
Je crée donc un updater, avec un site hébergeant les fichiers, et leur version, pour ne télécharger que les fichiers updatés.
Je n'avais jamais vraiment été dans un jeu réseau. Premier problème technique : algo de nagle. Mes paquets s'entassent et ne sont pas envoyés au fil de l'eau mais en paquet. Du coup, le jeu rame. Beaucoup de sueur pour régler ces problèmes de performance.
Après moults itérations, j'arrivent à un jeu avec de premiers résultats, et peu de fonctionnalités. Je me propose de l'essayer avec des joueurs par Internet (alors que toujours en réseau local).
Premier constat: trouver un serveur pour héberger un jeu fait maison, autre que Php, c'est un peu l'enfer. Bon, je trouve une solution. Je lance le test. Une horreur, un lag monumental.
-- ma BP ne permet qu'un upload limité.
-- linux de base active l'algo de nagle.
-- mes paquets ne sont pas optimisés. J'envoie de longues chaines de caractères au lieu des types concernés (un float converti en string peut faire 20/30 caractères, alors qu'envoyé en tant que float fera 4 octets.
Effectivement dans un jeu réseau, l'optimisation des envois de paquet doit être très rigoureux. Le flux réseau dans un jeu en temps réel est très important, et le taux d'envoi est réglé chez moi à tous 1/4 de secondes, avec l'envoi de position de tous les joueurs et ennemis.
Cela représente un traffic très important. D'où le choix pour certains de jeu, d'instancier, afin de limiter le flux réseau à une instance, qui peut être hébergé par un serveur dédié par exemple.
Grosse itération à optimiser le traffic réseau, et à trouver un serveur avec de la BP.
A ce jour, je redémarre avec des bases saines, et pour reprendre de la motivation, je m'attarde sur des concepts joueurs.
Néanmoins, face à moi se dresse quelques grosses montagnes:
-- Gestion du réseau à grand nombre (>10 joueurs)
-- jeu sans thread, et je pense qu'il faudrait pouvoir séparer les différentes zones du jeu en terme de thread pour pouvoir assurer une continuité de réseau acceptable
-- Contenu graphique assez limité, il va falloir trouver une bonne âme pour me préparer quelques éléments de jeu (vaisseau au minimum)
-- Contenu de jeu limité (quêtes, items, zones, ...) C'est un travail énorme que de travailler sur le contenu même du jeu.
En parallèle, j'ai commencé à travailler sur un éditeur de contenu visuel, plutôt que de m'échiner à remplir la base de données à la main. C'est un travail encore supplémentaire, et le temps passé sur cet éditeur n'est pas un temps passé sur le jeu.
J'ai lu entre deux également, un bon article sur les 10 règles à suivre pour faire un jeu vidéo indie.
Il y a par exemple, beaucoup d'équipes qui se battent et passent du temps sur des choses futiles, et qui ne sont que des éléments superficiels à mon sens (nom du jeu, histoire, ...), et cela me fait rire.
Ce que je conserve comme conseils:
-- une histoire n'est pas même le commencement du jeu, mais un élément d'appui pour le joueur
-- commencer par mettre en forme les concepts du jeu (mécanismes du jeu + buts)
-- choisissez la technologie/moteur qui vous permettront d'arriver à ce but en prenant en compte les différents éléments (réseau, gui, base de données,...) même si tout n'est pas pensé parfaitement au départ, donnez vous une 1ere base qui vous lancera
-- soyez respectueux du travail des autres et des contraintes des autres. Vous êtes amateurs. Prenez en compte ce facteur (compétences, résultats, timing, ...).
-- prenez du temps à discuter avec d'autres groupes. Ils ont leur expérience, et la partageront.
-- trouvez vous de quoi maintenir la motivation. C'est le nerf de la guerre. Faites des itérations pendant lesquelles vous avez un but à atteindre qui soit tangible
-- soyez conscients des limites de votre exercice et donnez vous le bon objectif : faire un jeu consomme du temps, du talent, et beaucoup de ressources.
-- attention de ne pas tomber dans le cercle de création de librairie interne, mais rester bien dans le but de créer un jeu. Pas trop de librairie générique, cela consomme un temps fou. Estimer le gain réel.
Merci pour votre lecture