Chroniques du Jeu vidéo

Par Morphine Blog créé le 12/07/10 Mis à jour le 16/04/11 à 14h04

Ajouter aux favoris

Catégorie : Développement

Signaler
Développement

Vous pouvez trouver l'article original sur mon site (pixelkingdom.fr) : http://pixelkingdom.fr/202-creer-un-jeu-amateur-bien-commencer

 

En tant que joueur, créer son propre jeu vidéo est un désir qui revient souvent. La création de jeux en amateur est aujourd'hui plus facile que jamais, et leur diffusion également, principalement grâce à internet où l'on trouve tutoriels, forums d'aide, et plate-formes de jeux (les portails de jeux flash ou encore les plate-formes consoles telles que XNA, etc...). Il existe également de plus en plus d'outils pour nous faciliter la vie, si bien qu'on peut arriver à un résultat décent sans savoir programmer.

Malheureusement, une grande majorité des projets de jeux amateurs finissent plus vite que prévu, la faute à un manque de motivation sur le long terme, d'organisation ou d'expérience. Sans prétendre tout connaître sur le sujet, je vais tenter de donner quelques pistes pour aller le plus loin possible dans la création d'un jeu amateur. Et puisque le point le plus important est sans doute l'organisation du projet, la préparation est une phase indispensable qu'il ne faut absolument pas négliger.

1-Ne pas voir trop grand

C'est pour moi la règle d'or. Beaucoup des créateurs de jeu amateurs ne se rendent pas compte du temps nécessaire à leur projet. Ce qui rend le temps de travail si difficile à évaluer est le fait que vous ne travaillez pas forcément de façon régulière, pas tous les jours, et surement pas 8h par jour comme si vous étiez payé pour ça. Le manque d'expérience peut jouer aussi.

La solution n'est pas bien compliquée, il faut rester simple. Vous avez trouvé un concept qui tue ? Alors mettez-le en pratique mais ne vous laissez pas emporter et définissez des limites, n'oubliez pas que vous pourrez améliorer le jeu ensuite. Si vous voyez trop grand, vous finirez par vous décourager avant d'avoir fini, alors que sortir un jeu et prendre connaissance des retours est une bonne source de motivation pour poursuivre le développement et améliorer le jeu.

N'oubliez pas que des jeux très simples ont connu un grand succès et sont très fun à jouer !

2-Faire un Game Design Document

Il est indispensable pour mener un projet d'avoir des méthodes le plus proche possible de ce qui se fait dans un contexte professionnel. Le Game Design Document, que j'abrégerai GDD, c'est un gros document qui est une sorte de cahier des charges, mais pour le jeu vidéo. Dans celui-ci on doit trouver toutes les informations concernant le jeu, avec un maximum de détails ; il ne faut pas hésiter à y passer beaucoup de temps ni avoir peur d'en ecrire trop, car encore une fois la phase de préparation est la plus importante de toutes.

Il y a diverses informations à écrire dans le GDD, même (et surtout) celles qui vous semblent évidentes ou inutiles. Évoquez le concept général du jeu (quelques lignes), le support, le(s) genre(s), le but du jeu, les contrôles, la vue (profil, de dessus, etc), le nombre de joueurs, les différentes mécaniques de jeu (en détail), l'univers du jeu, ses personnages (jouables, non-jouables, alliés, ennemis), etc. Dressez si possible des listes : objets, ennemis, armes, etc. N'oubliez pas le pitch (scénario) et faites un walkthrough qui décrit la progression du joueur du début à la fin du jeu. Accompagnez le tout d'images, schémas, etc.

La rédaction d'un tel document présente 3 avantages vitaux :

  1. Se fixer des limites : Indispensable ! Comme cela a été dit plus haut, mieux vaut rester simple. Mais il arrive souvent qu'en plein développement on ait une idée qu'on trouve géniale et qu'on veut absolument intégrer au jeu. Et avant même de l'avoir implémentée on a déjà changé d'avis trois fois sur un autre aspect du jeu. Résultat : notre projet de jeu n'est qu'un chantier permanent et est voué à ne jamais être terminé. En fait, c'est ce qui se passe dans une grande majorité des jeux amateurs. La solution est de se tenir à son GDD coûte que coûte, et de garder ses idées de coté pour de futurs jeux. C'est aussi pour ça qu'il faut prendre son temps lors de la rédaction du GDD, car tant qu'il n'est pas terminé il est toujours possible d'y ajouter des choses. Par contre une fois bouclé, pas question de revenir dessus (sauf pour des changements très mineurs, c'est à vous d'être pragmatique et d'évaluer si c'est une perte de temps ou non - en général ça l'est).
  2. Ne rien oublier : Ca peut sembler bête, mais c'est pourtant ce qui arrive lorsqu'on manque d'organisation. Ces choses qui vous semblent si évidentes aujourd'hui, dans une semaine vous les aurez complètement oubliées. Un document bien détaillé permet d'éviter ça.
  3. Travailler en équipe : Je reviendrai plus en détail sur le travail en équipe par la suite, mais si vous êtes plusieurs sur le projet le GDD est d'autant plus indispensable. Il évitera que vos partenaires viennent vous poser des questions tous les deux jours et que vous leur donniez une réponse improvisée que vous oublierez par la suite. De plus, gardez à l'esprit que c'est à vous de prendre les décisions et non les graphistes ou développeurs, diriger un projet de cette façon "je-m'en-foutiste" est la meilleure façon d'aller dans le mur.

Vous l'aurez compris, le GDD c'est extrêmement important. Cherchez un peu sur le net et vous devriez en trouver quelques exemples (c'est pas facile, mais je mettrai à jour si j'en retrouve).

3-Choisir avec qui travailler

Une erreur fréquente est de vouloir s'entourer d'une énorme équipe. Instinctivement, on se dit que plus la team est grande, plus le jeu ira vite, et plus les gens seront spécialisés et bons dans leur domaine. Malheureusement c'est là que le développement indépendant devient radicalement opposé à ce qui se fait professionnellement. Du travail bénévole sur votre temps libre et pas de rétribution : bien souvent même l'initiateur du projet quitte le navire avant la fin. Il est très difficile de motiver une telle équipe, d'autant qu'on se dit que bon, après tout, ils sont déjà bien gentils d'aider. Ce qu'il faut faire, c'est obliger ses partenaires à s'engager, même si c'est bénévole, et ainsi ne pas hésitez à les pousser un peu si nécessaire. Cependant, ce sera toujours difficile à gérer et la plupart des gens, même les plus motivés au départ (surtout eux !) finiront par quitter le projet, bien souvent sans même avertir qui que ce soit.

En réalité, mieux vaut avoir le moins de personnes possible sur le projet. Et se préparer à mettre la main à la pâte. Un bon créateur indépendant sait tout faire : game design, programmation, graphisme. Ca fait beaucoup, mais au moins le jeu a une chance de sortir un jour, et tant pis si vous ne dessinez pas très bien (il y a toujours des solutions alternatives), ou si vous ne savez pas coder (des outils existent).

Ce qui m'amène au dernier point : le "recrutement". En fait, personne ne voudra aider un inconnu qui débarque de nulle part, c'est un fait. Car vous pourriez très bien ne pas être sérieux du tout, hé oui ça arrive... souvent. Alors paradoxalement pour trouver de l'aide il faut un jeu bien avancé donc généralement, le produit de votre travail, dans tous les domaines. Le GDD peut servir à ce moment là pour montrer votre sérieux et trouver des partenaires sans avoir de prototype du jeu. Mais je pense que c'est encore plus à eux de prouver leur motivation, parce qu'il est encore plus dur de s'impliquer dans le projet d'un autre.

En conclusion, ne comptez pas trop sur les autres et investissez-vous même sur des domaines où vous n'êtes pas à l'aise, en plus vous apprendrez des tas de trucs intéressants. Je pense qu'une équipe ne doit pas excéder 4 ou 5 personnes.

4-Choisir ses outils

Ne faites surtout pas un jeu adapté au seul outil que vous connaissez. N'adaptez pas non plus cet outil pour votre jeu : c'est du bricolage. Créez votre concept et cherchez la façon la plus adaptée de le mettre en oeuvre. N'hésitez pas à vous lancer dans quelque chose que vous ne connaissez pas encore, vous ne le regretterez pas. Restez tout de même terre à terre et ne vous lancez pas dans un jeu codé de A à Z en C++ si vous n'avez jamais touché une ligne de code. Prenez du recul et choisissez, en ayant en tête les diverses solutions qui existent. En voici quelques unes :

  • Game Maker
  • Multimedia Fusion
  • TGEA (Torque)
  • UDK (Unreal development Kit)
  • Unity 3D
  • Et la plupart des langages de programmation : C, C#, C++, Java, Actionscript (flash), Ruby, ...

Cet article n'ayant pas pour but d'en faire une liste, je vous renvoie à cette page de PixelProspector qui contient des tonnes d'informations notamment sur les différents moteurs de jeu et éditeurs, avec des liens : http://www.pixelprospector.com/2010/08/the-big-list-of-game-development-resources/

Il est très utile d'avoir une vue d'ensemble de ses différentes solutions afin de faire le bon choix.

5-Travailler avec des délais

Encore un bon moyen de combattre la procrastination ! On n'est pas là pour se mettre la pression, mais se fixer des objectifs dans le temps est un excellent facteur de motivation, et vous évite de toujours remettre au lendemain. Ces objectifs peuvent être très concrets (une démo à sortir un jour précis) ou simplement des étapes d'un planning établit à l'avance. Et c'est bien pour ça que j'en parle, même si c'est un conseil à appliquer du début à la fin du projet, avoir un planning précis et daté est l'idéal. Et bien sûr, il faut s'y tenir.

 

 

Je pense que j'ai fait le tour, mais n'hésitez pas à commenter si vous avez des suggestions ou des questions. Je ferai peut-être d'autres articles dans ce style dans l'avenir, sur le développement de jeu en amateur (des idées d'articles ?).

Ajouter à mes favoris Commenter (0)

Signaler
Développement

 

 

...Et pas n'importe lequel ! Déjà, c'est un jeu que j'ai conçu et que je développe seul, et c'est d'abord pour cela que j'en parle. Mais Lux c'est aussi et surtout mon premier vrai jeu utilisant Flixel, une librairie Actionscript destinée au jeu vidéo. Un jeu "expérimental" donc, ce dont j'ai profité : c'est relativement simple, quelque peu psychédélique et casual dans l'âme. Mais quand même avec ce coté old school inhérent au genre : le shoot'em up. Un shoot en flash, donc à priori quelque chose de très banal, et pourtant le jeu se base sur un concept qui pourrait vous surprendre.

Le jeu se présente sous la forme d'un shoot vertical classique, auquel le joueur peut apporter sa propre musique. Cette fonctionnalité n'est pas anodine puisque c'est selon la musique que seront générés les ennemis qu'il faudra esquiver et abattre. Plus la musique est lourde, rapide, chaotique, et plus les ennemis sont nombreux par exemple. Et même si le jeu propose sept modes de difficulté, il s'avère bien plus facile de survivre sur une piste de Norah Jones que sur du Rammstein (non je ne suis pas payé pour citer des artistes).

Bien sur l'idée n'est pas totalement nouvelle, Beat Hazard par exemple reprend le même principe (ce n'est pas du plagiat, je ne connaissais d'ailleurs pas ce jeu au moment de lancer ce projet). La correspondance entre la musique et le résultat à l'écran n'y était d'ailleurs pas flagrante, un défaut que j'ai beaucoup de mal à contourner avec Lux (on y reviendra). Il y a aussi eu Audiosurf qui lui, en revanche, est assez bluffant à ce niveau-là.


Revenons à nos moutons. Le jeu ne se déroule pas dans un univers défini, il n'y a pas de scénario, j'ai juste voulu éviter le vaisseau et les laser (cf. les screenshots)... Lux est une expérience, pour moi-même en tant que concepteur mais aussi pour le joueur, plutôt qu'un jeu c'est une autre façon d'écouter sa musique. Ce n'est pas un jeu difficile ou stressant (on ne meurt pas), le seul challenge est le score. Quant au gameplay lui-même, c'est très simple : on se dirige à la souris, on tire en cliquant, et avec la barre d'espace on utilise une traditionnelle bombe.

On pourrait se dire qu'utiliser une librairie externe telle que Flixel n'était pas nécessaire : pas besoin de moteur physique, même simple, et ce n'est évidemment pas elle qui gère le spawn des ennemis (puisque c'est un bon vieux computeSpectrum, que j'ai déjà expérimenté pour un lecteur de musique). C'est ce que je me suis dit en commençant, mais je souhaitait surtout apprivoiser cette librairie très prometteuse ; j'ai donc continué et effectivement j'en ai eu bien besoin. Menus, sprites, bitmaps, boucle de jeu, particules... tout ça est géré par Flixel et relativement optimisé, et même si je n'ai pas utilisé certaines classes comme la générations de maps à partir de tiles, ou celles dédiées aux jeux de plate-forme, il y en a beaucoup d'autres qui m'ont évité d'avoir à réinventer la roue...

Le seul reproche que je fais à Flixel, c'est sa doc trop peu détaillée, même si elle a le mérite d'exister, et en règle générale le peu d'aide qu'on peut trouver à son propos sur le net concernant les dernières versions (apparemment beaucoup de choses ont changé et les tutoriels et snippets valables pour les versions 2.x ne le sont plus).


Pour finir, voici quelques point que j'aimerais améliorer d'ici la fin du développement du jeu, et d'autres qui soulèvent des interrogations encore non résolues.

La concordance entre la musique et le jeu :

Il y a plusieurs raisons qui font que le jeu ne semble pas forcément toujours en accord avec la musique. J'essaierai de ne pas rentrer dans des détails trop techniques ici, car certaines de ces raisons sont extrêmement simples. Imaginez-vous le jeu : le personnage joueur est en bas de l'écran, les ennemis arrivent par le haut. Il sont donc générés hors de l'écran avant de descendre vers le joueur. Et c'est là le problème : les ennemis ont beau apparaître en rythme, on ne les voit pas apparaître. On les voit seulement pénétrer dans la zone de jeu, d'une manière "progressive" (leur déplacement). On pourrait imaginer prévoir la musique à l'avance pour palier à ce problème (mais il y a des chances que le résultat paraisse encore plus aléatoire...), mais cela suggère de devoir créer à l'instar d'un Stepmania par exemple, un fichier contenant la musique et tous les ennemis qu'elle générera. Bref, une solution beaucoup moins agréable que le simple copié-collé de fichiers mp3 dans un répertoire désigné (qui devront tout de même être listés dans un fichier - txt ou xml, à moins d'avoir recours à la technologie Air par exemple). Quant à faire faire au programme la même chose qu'actuellement, mais à l'avance, je ne sais pas si c'est possible, puisqu'avec la méthode que j'utilise, flash capture simplement l'onde sonore "en direct", autrement dit à une frame donnée on n'a pas accès à la suite de la musique (ni à ce qu'il y avait avant...)

Les ennemis :

Des formes géométriques, je pense que ça peut être améliorer. Non pas que ce soit une mauvais chose en soit, même si détruire des carrés et des hexagones est moins palpitant qu'exploser des aliens ; ce type d'ennemi fonctionne bien avec l'ambiance voulue mais il doit y avoir moyen de faire mieux, plus esthétique.

Online ou Offline :

Le problème vient des musiques : si le jeu se joue en ligne, l'import de musiques par le joueur se fait par un upload qui en plus d'ajouter un délai supplémentaire (surtout qu'il faut ensuite re-télécharger dans l'autre sens la musique pendant le jeu...) nécessite forcément un serveur et le script PHP qui va bien. Exit donc les portails tels que Newgrounds ou Kongregate, le seul avantage c'est que le script PHP peut également ajouter le mp3 au fichier txt/xml que j'évoquais plus haut et qui s'avère nécessaire pour lister les musiques du joueur. L'autre solution est donc de proposer le jeu en téléchargement, ce qui arrange tout le monde... les seuls problèmes ici sont la perte des avantages de flash en terme d'accessibilité, et le manque d'habitude des joueurs de jouer à du flash ailleurs que dans leur navigateur web. Le mieux serait je pense de faire deux versions du jeu, l'une destinée aux grands portails et jouable via navigateur et contenant une liste prédéfinie de musiques (libres), et la seconde à télécharger.


Je pense que ça suffira pour Lux, j'en reparlerai une fois le jeu plus avancé. Pour information, le jeu est actuellement jouable dans tous les modes de difficultés, je suis en train de m'occuper du menu principal, ensuite viendront les chargements de musique. Il faudra aussi implémenter le mode de jeu "Survie".

 

 

Ajouter à mes favoris Commenter (2)

Signaler
Développement

Pour ceux qui ne connaissent pas, Flixel est une librairie ActionScript 3 (le langage de Flash) permettant de faire des jeux, en flash donc.

 J'ai donc téléchargé le tout, j'en ai profité pour aussi télécharger et me mettre à FlashDevelop (à la place de Flash CS, le logiciel "officiel", d'Adobe), et j'ai suivi un tuto pour débutant, celui-ci plus précisément.

Bon, j'ai fait mes propres sprites évidemment (on notera quand-même un certain manque d'inspiration sur ce coup-là), et ajouté quelques features inutiles pour faire mumuse avec tout ce que j'avais appris.

J'ai aussi essayé de faire un truc ultra-nerveux avec les moyens du bord, en attendant que j'en apprenne plus (là, c'est vraiment la base), c'est pas si mal. Le seul problème c'est que ça rame méchamment au bout d'un moment, sans doute à cause des effets de particules (pourtant simples). Mais j'avoue ne pas avoir le courage de chercher la cause du problème plus en détails, le fait d'utiliser un moteur que je ne connais pas encore très bien fait que forcément, c'est plus dur à déceler.

Bref, je vous invite à l'essayer, c'est ici que ça se passe : http://www.newgrounds.com/dump/item/4ce3e717a099eebc76528fe9be2687d3

Au passage dites-moi vos scores.

 

Et moi maintenant, j'ai plus qu'à trouver d'autres tutos pour poursuivre mon apprentissage (j'ai un peu de mal à en trouver...), car il y a encore énormément de choses que je ne sais pas faire (sprites animés - via un spritesheet?, tiles, en fait tout ce qui n'est pas nécessaire pour un shoot...). Si vous en connaissez, faites-moi signe :D

 

Ah, et merci à Guillaume de Swing Swing Submarine d'avoir partagé son savoir avec moi, et de m'avoir appris l'existence de Flixel !

Ajouter à mes favoris Commenter (8)

Archives

Favoris