Jésus lave plus blanc (livre)

Sous ce titre pour le moins original se cache en réalité un livre sur le marketing. L’idée de ce livre est venue à l’auteur quand un évêque italien a répondu dans une interview que c’était l’Eglise qui avait inventé le marketing il y a deux mille ans. L’objectif est donc d’expliquer des techniques de marketing actuelles en observant leurs débuts dans la religion, et comment ces techniques ont permis à un charpentier de créer l’organisme multinational le plus puissant au monde avec un maximum de « clients ».

Sauf que… si l’idée du livre m’avait amusé… sa lecture a été moins sympathique. Je sais pas si cela vient de moi ou pas, mais j’ai trouvé le style d’écriture tellement lourd que j’ai abandonné la lecture au bout d’un tiers du livre. Je lis pourtant beaucoup de livres sur pas mal de sujets, dont une bonne partie en anglais, mais là rien à faire…
La lecture de ce livre nécessite de relire plusieurs fois les mêmes phrases, ça endort, ça ne donne pas du tout envie de lire la suite et rien de ce que je lis ne me reste en tête… bref, l’auteur aurait mieux fait de mettre en application les principes de bases du marketing pour éviter de sortir un bouquin aussi indigeste.

Promis, le prochain bouquin chroniqué sera bon pour changer 🙂

Erreur classique n°3: faire un jeu nécessitant trop de contenu

Outre la complexité d’un jeu vidéo, l’autre élément principal conduisant souvent à un abandon est la somme des « Ã©léments » (ou « contenu ») à produire pour ce jeu (et j’en fais les frais en ce moment sur un de mes projets, si quelqu’un connaît un graphiste… faire offre 🙂 ).
Par élément, j’entends tout ce qui est graphisme, interface, modèles, textures, niveaux, quêtes, dialogues, scénario, etc…

Ce n’est pas spécialement complexe à réaliser une fois que l’on a appris à le faire, mais cela prend du temps.

Prenons un exemple simple: faire un mod solo pour un quake like n’est pas vraiment compliqué une fois que l’on a appris à se servir de l’éditeur de niveaux. Cela n’empêche pas le fait que la majorité des mods solos échouent tout comme les projets de mmorpg. La raison est simple, faire du contenu à la chaîne est vite ennuyeux et 10 amateurs faisant cela dans leur temps libre auront toujours plus tendance à abandonner qu’une équipe pro étant rémunérée pour faire cela à temps plein.

Autre exemple: faire un rpg 3d. Passé l’euphorie d’avoir mis en place Ogre 3D et d’avoir un prototype fonctionnel, vient le moment où il faut créer tout les décors, les personnages, les musiques, les quêtes, les combats, etc… Ce n’est pas impossible, mais c’est très long, pour un résultat qui restera amateur au final pour la plupart des cas.
Pendant le temps que vous passerez sur ce projet, vous auriez pu développer au moins 5 fois un jeu comme Defcon, qui s’est vendu et qui a eu du succès.

Solutions possibles:
– choisir un jeu n’ayant pas besoin de beaucoup de contenu (Tetris, Sudoku…)
– jouer sur le style graphique pour avoir moins de contenu à produire. Ex: Defcon et Darwinia, Geometry Wars.
Рprivil̩gier le multijoueurs pour rentabiliser au maximum le contenu produit (Bomberman)
Рfournir le minimum de contenu et laisser la communaut̩ produire le reste (Mugen)
– mettre en place un système de création procédurale qui génère le contenu tout seul mais augmente la complexité du jeu (Niveaux de Diablo, Elite) Voir cette news chez AntiPattern à ce sujet.

Voici en résumé (bon, j’ai évalué au pif… c’est juste pour avoir une idée, passez pas votre temps à vous plaindre que tel truc est pas placé comme il faut), une représentation de la complexité et de la somme de contenu à produire pour un jeu.
En gros, plus votre style de jeu est proche de l’origine, plus il ira vite à faire. Plus il est en haut à droite, plus il sera compliqué.

Le paradoxe est donc que beaucoup de débutants tentent directement le mmorpg ou le rpg 3d, ce qui représente les projets les plus compliqués et longs à faire.
De l’autre côté, les petites équipes qui réussissent ne font pas de mmo ou de grands jeux 3D. On a par exemple Popcap qui est l’un des ténors des jeux pour casual gamers avec Bejeweled (= Diamants dans MSN) et Zuma ou Introversion qui a son propre style (Darwinia, Defcon).

En tant qu’amateur ou indie, il vaut mieux donc choisir un projet qui soit bon tout en minimisant tant que possible la complexité et la somme des contenus à produire.

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.

News

– VgCats explique comment s’y prendre pour avoir un rendu « next gen » (anglais)

РArticle des d̩buts du jeu vid̩o sur le blog de Fred (fran̤ais)

РAm̩liorer un jeu en virant en premier les trucs nazes.Rampant coyote explique une technique amusante pour corriger un jeu en demandant aux beta testeurs de lister en priorit̩ tout ce qui craint et qui est susceptible de leur faire quitter le jeu (et non simplement lister les bugs). (anglais)

– GDMag de janvier gratuit online (en retard je sais…) (anglais)

– Ajout de plusieurs liens vers des blogs

РLe Joystick de F̩vrier est sorti avec 6 pages sur les jeux indies dont 2 sur le jeu de Jeremy Chatelaine avec son interview.