Multiplayer Game Programming (Livre)

Enfin une critique de livre sur la création de jeux vidéo sur ce blog… Bon, ne vous réjouissez pas trop vite, je commence par un mauvais 🙂

Multiplayer Game Programming est sorti en 2001 et est l’un des premiers livres sur la création de jeux vidéo que j’ai acheté.
Il fait presque 800 pages et se consacre à la création de jeux multijoueurs en C/C++.

Si je l’avais relativement apprécié à l’époque, je le déconseillerais à l’heure actuelle pour différentes raisons que vous allez comprendre en voyant comment est constitué le bouquin:

– 100 pages d’introduction sur le réseau et les jeux multijoueurs
– 100 pages sur les sockets (Winsock) avec juste les bases (connexion, envoi d’un message, réception, déconnexion), rien de vraiment utilisable pour les jeux
– 80 pages sur un tutoriel à la programmation de Windows (présentation des bases en Win32)
– 140 pages sur Directplay, l’api de réseau de DirectX que personne n’a vraiment utilisé (même Microsoft suggère d’utiliser autre chose aujourd’hui)
– 220 pages sur DirectX qui n’ont rien à voir avec le réseau (Graphismes, Input et son)
– 90 pages sur la création d’un MMO avec Directplay, qui est plutôt un tutoriel minimaliste de jeu en réseau

Bref:

Рle livre est clairement destin̩ aux d̩butants
– si vous voulez apprendre les sockets, un livre sur la programmation réseau « classique » ou des documents online seront beaucoup plus utiles
Рsi vous voulez apprendre Directplay, laissez tomber cette techno d̩pass̩e et utilisez plut̫t quelquechose comme Raknet
– si vous voulez apprendre Directx, il y a d’autres livres mieux faits et plus à jour
– si vous voulez apprendre à faire un MMO, ce livre ne vous sera pas d’une grande aide car il est vraiment trop basique

News

Des news plus ou moins récentes.

Une question pour les lecteurs, est-ce que ce genre de post récapitulatif vous intéresse ou est-ce que vous préférez plus d’articles à la place ?

• Les raisons du plantage de Ritual (Sin Episodes) par un développeur. Intéressant de voir ce qui peut faire tomber un studio pour savoir les pièges à éviter. (anglais)
• Vista fait planter les jeux. Les jeux indies ne sont généralement pas programmés pour tourner avec un compte limité, ce qui est le cas par défaut dans Windows Vista. (anglais)
• Des jeux indies sur la Wii ? (anglais)
• Une présentation technique du moteur next gen de Capcom pour Lost Planet. (anglais)
• Un site online arrête de vendre des jeux vidéo et explique pourquoi le marché « retail » est naze (anglais)
• L’avis de Rampant Coyote (dev indie) sur les jeux téléchargeables en 2007 (anglais)
• Vu chez AntiPattern (français), un jeu de cartes sur la création de jeux vidéo (anglais), amusant.
• Comment avoir un CV de la mort, par Jeremy Chatelaine (français). Pas de relation directe avec le jv, mais l’article est très bien fait et est particulièrement utile pour ceux souhaitant de faire embaucher par un studio.
• Vu chez GameProducer.net (anglais), une conférence sur les MMO indies aux USA en avril (anglais)
• Toujours chez Rampant Coyote, un article sur quelques éléments de game design pour les rpg (anglais)
• Un test pour savoir si son jeu a du potentiel de vente ou pas chez Gamasutra (anglais) avec une version française chez Nofrag (français). C’est plutôt adapté pour les jeux retails que pour les jeux online.

Erreur classique n°2: faire un jeu trop complexe

Disclaimer: article principalement destiné aux débutants.

Vouloir faire un jeu trop complexe est l’erreur la plus fréquente et la plus visible que l’on peut lire sur les forums de développeurs de jeux vidéo.

Cela concerne principalement les débutants inexpérimentés qui veulent refaire dans leur coin le hit du moment « mais en mieux ». Le phénomène n’est pas nouveau: en 2000 tout le monde voulait refaire Quake 3, maintenant c’est plutôt refaire World of Warcraft.

Le mythe du « je suis motivé et j’ai le temps »

C’est la réponse que l’on obtient généralement quand on tente de décourager quelqu’un d’inexpérimenté de se lancer dans un tel projet en faveur de quelque chose de plus simple.
Sauf que généralement, vu que le projet se révèle au final infaisable (oui, aussi bizarre que cela puisse paraître, peu d’ados de 14 ans réussissent à faire un MMORPG en 3D de A à Z), la motivation s’envole au fil du temps et le projet coule.

De toute façon, même si la motivation restait et que l’équipe débutante travaillait sans s’arrêter sur le projet (ce qui reste improbable), la qualité du travail fourni serait soit trop mauvaise, soit trop hétérogène entre un stade avancé et le début du projet (tout codeur jetant un oeil sur ses premiers projets comprendra, pareil pour les graphistes…) et il faudrait recommencer plusieurs fois les mêmes choses pour avoir un ensemble homogène. Bref, une perte de temps.

La création de jeu vidéo, ce domaine magique…

…où les débutants veulent faire mieux que les pros.
C’est en effet le seul domaine où l’on voit des débutants complets essayer de surpasser des professionnels ayant des années d’expérience sans que cela ne leur semble bizarre.
Pourtant, un débutant en Tennis n’aura jamais l’idée de s’inscrire au tournoi de Roland Garros, un enfant apprenant à écrire n’aura pas l’idée de commencer un livre pour le prix Goncourt.

Pourquoi cela serait différent pour la création de jeux vidéo ?
Un projet n’est généralement pas irréalisable en lui même, il faut juste de « l’entraînement » et de l’expérience. Essayer de griller les étapes en voulant atteindre le sommet de ce domaine immédiatement ne sert à rien.

Visez grand …
… commencez petit !

Cela ne veut pas dire qu’il faut abandonner ses rêves, juste qu’il faut y aller progressivement. Il est impossible de lancer un mmorpg commercial réalisé par des débutants. Par contre, il est possible de s’entraîner, de créer des jeux indépendants, de créer une société, de la faire grandir, de devenir un vrai studio de développement et alors il est possible de réaliser le jeu de ses rêves.

Le premier conseil qui est donné à quelqu’un voulant se lancer dans le développement de jeu vidéo (d’un point de vue programmation) est: « Fais un morpion ! ». La plupart de ceux qui ne suivent pas ce conseil vont généralement dans le mur car ils ne comprennent pas l’intérêt de l’apprentissage et veulent juste faire « leur » jeu et « maintenant ».
Faire un morpion n’est pas une fin en soi, c’est juste que si on est pas capable de faire un morpion, on ne sera pas capable de faire le super mmorpg-next gen.
Et comme la première fois que l’on fait un morpion ce n’est pas si évident que ça en avait l’air, cela montre que c’est un apprentissage utile. L’idée est donc par la suite d’augmenter progressivement selon son niveau de départ, de passer à un tétris, un mario, un bomberman, un mario kart, un jeu 3D, etc…
Il faut d’abord obtenir les compétences et l’expérience nécessaires avant de faire des projets plus importants.

Pour les non-programmeurs, c’est une situation différente mais un apprentissage progressif est également nécessaire. Vous ne trouverez pas de programmeurs expérimentés et sérieux pour votre projet si vous n’êtes pas non plus expérimenté dans votre domaine.

Erreur classique n°1: essayer de faire comme les pros

Cela va sembler évident pour la plupart des lecteurs, mais il arrive régulièrement de voir certains amateurs essayer de faire un jeu « comme des pros » après avoir vu ou lu comment se fabrique un jeu dans un studio professionnel.

Si certains aspects sont intéressants, cela reste quand même une erreur d’essayer de copier leurs méthodes car ce n’est pas du tout le même monde.
Bien entendu, la situation varie selon si on est un débutant complet ou un indépendant semi-pro.

Pour commencer, il faut avoir en tête qu’être amateur implique des contraintes supplémentaires:

– le travail se fait pendant le temps libre. Les pros sont à temps complet.
Рon est g̩n̩ralement inexp̩riment̩ et la cr̩ation n̩cessite un apprentissage. Les pros sont exp̩riment̩s.
– les équipes d’amateurs voient énormément de changements parmi leurs membres, il est difficile de compter réellement sur quelqu’un sur la durée. Les studios sont plus stables de ce côté là grâce aux salaires (entre autres).
Рun projet amateur signifie surtout t̩l̩travail, et donc motivation et initiative. Les pros travaillent en studio et sont manag̩s.
Рpas ou peu de ressources, ce qui implique des difficult̩s pour sous-traiter, louer des serveurs et acheter du mat̩riel et des logiciels
– dans le cas des indies vendant sur Internet, il faut faire également le marketing, la communication, la gestion des ventes, etc… alors que pour un jeu vendu en boîte c’est l’éditeur qui s’en charge.

Mais cela à aussi des avantages:

– pas besoin de communiquer à tout va car vous n’avez pas un éditeur aux fesses, pas besoin donc de commencer à faire de la pub ou des sites internet de présentation. Concentrez vous sur le fait de faire le jeu.
– plus grande liberté pour le jeu, on ne peut pas brider votre créativité. Si vous avez le niveau, vous pouvez vous permettre d’innover. Si vous êtes vraiment débutant, il vaut mieux commencer par cloner des grands classiques (pong, bomberman…) histoire de se faire la main
– pas de milestones obligatoires (et le projet n’est pas annulé s’il est en retard)
– pas trop de risques financiers (sauf indie qui prend des risques « raisonnables »)

Prenons un exemple d’une technique à ne pas reproduire :

La gestion de projet dans un projet pro est très important. Il faut savoir gérer l’emploi du temps des membres de l’équipe et s’assurer que chacun avance correctement car un trop grand retard peut mener à l’annulation du projet. Certains projets amateurs essaient de s’en inspirer et mettent même en place des diagrammes de Gantt et autres joyeusetés.
Sauf que, tout cela ne sert à rien généralement… pour la simple raison qu’un projet amateur est réalisé pendant le temps libre d’une personne, et que ce temps est généralement très variable (pouvez vous en vouloir à quelqu’un de ne pas travailler au projet parce qu’il a des examens ou des problèmes familliaux ?). De plus, rien n’empêche un membre de l’équipe de partir sans qu’il puisse être remplacé, et dans ce cas votre joli diagramme devient inutile.

En conclusion

Si j’ai mis cette erreur en premier c’est parce que beaucoup d’autres en dépendent.

La solution consiste simplement à admettre qu’on ne peut faire faire un jeu comme le font les pros pour la simple et bonne raison que les conditions ne sont pas les mêmes. Il faut agir en fonction et choisir un projet et une méthodologie qui permettent de réduire ces inconvénients supplémentaires et d’augmenter les effets des avantages.