Devblog

Viewing posts from the Devblog category

Est est sorti ! Sa première mise à jour aussi !

Blog-850x480-Screening
Ca y est ! Egz est disponible depuis le 28 avril, sur iOS et Android ! Cela signifique que j’ai enfin accompli mon rêve d’enfance : j’ai fait mon propre jeu vidéo ! Cela fait deux semaines maintenant, et j’aimerais remercier toutes les personnes qui m’ont aidé, de loin, ou de près. Et bien évidemment, merci à VOUS si vous jouez à Egz, j’espère sincèrement que le jeu vous plaît.

Et maintenant ?
Et bien, si vous avez joué au jeu, vous savez déjà qu’il y a des bugs. Et malheureusement, il y en a un petit paquet. La bonne nouvelle, c’est que depuis aujourd’hui, une mise à jour est disponible. Voici le patchlog :

  • « Egz » nécessite dorénavant iOS 8.1 au lieu de iOS 9.0
  • Améliorations diverses sur l’interface afin de supprimer certains crashs.
  • Un crash causé par l’Egz mourant pendant le 1er boss a été corrigé.
  • Un crash causé par une bulle dans le niveau 4-7 a été corrigé.
  • Des changements mineurs ont été appliqués au niveau 2-8, empêchant le jeu de crasher.
  • Un bouton « Rejouer » a été ajouté.
  • Un écran « Notez le jeu » a été ajouté.
  • Dans certains cas, la pagination n’était pas masquée comme prévu.
  • Se connecter à Facebook via le menu d’options fonctionne comme prévu.
  • Le nombre d’étoiles indiquées dans le 1er monde a été corrigé.
  • De nouveaux noms ont été ajoutés aux Egz.
  • Les fichiers de sauvegardes sont versionnés.
  • Améliorations diverses de traduction (anglais).
Plusieurs joueurs m’ont affirmé que le jeu crashait A CHAQUE FOIS que l’Egz mourrait. J’ai pu reproduire ce bug, mais uniquement dans 2 niveaux spécifiques : pendant les niveaux des 2 premiers boss (niveaux 1-10 et 2-10). Si votre jeu se plante dans un autre niveau, s’il vous plaît, S’IL VOUS PLAÎT, FAITES-LE MOI SAVOIR ! Envoyez un email à email !

Et… ensuite ?
C’est une bonne question que je me pose depuis un petit moment. Egz n’est pas encore totalement terminé. Cette mise à jour n’étant que la première, d’autres vont suivre. Tous les bugs et crashs seront, je l’espère, supprimés. Et si tout se passe comme prévu, du nouveau contenu devrait être ajouté : de nouveaux niveaux, de nouveaux modes de jeu et, avec un peu de chance, de nouveaux Egz.

Mon aventure avec Egz n’est donc définitivement pas terminée.

1136x640-4
Et bien évidemment, je continuerai de poster ici et vous raconterai de vous raconter comment mon tout premier jeu, Egz, a pris vie. Il reste encore pas mal de sujets qui n’ont pas été abordés et j’ai plutôt hâte.

Egz Devblog – Partie 7 – Génération de niveaux

Blog-850x480-Default

La première version du jeu fonctionnait pas mal, mis à part une tonne de bugs bien entendu. Mais cela allait être réglé plus tard. En attendant, il allait falloir se pencher sur la génération des niveaux. Actuellement, dans le prototype existant, les niveaux étaient posés en “dur”. Une grosse image correspondait au sol, tandis que différentes zones physiques avaient été placées à la main. Une par une. Bref, c’était un peu long, mais cela restait simple.

Par contre, sur le long terme, ce n’était absolument pas viable. D’autant qu’il était prévu d’avoir au minimum 80 niveaux. Il me fallait donc avoir un éditeur de niveaux. Cela allait me prendre du temps à réaliser, mais sur le long terme j’étais sûr et certain que cela serait rentable.

Ma volonté d’avoir un univers arrondi allait me compliquer énormément la tache. Je m’en doutais un peu, mais à l’époque, je ne pensais pas tout faire seul. J’entrais dans une nouvelle ère cauchemardesque. Celle où j’allais replonger dans mes années les plus traumatisantes, lorsque ma peau commençait à se recouvrir de boutons et où l’idée même d’être dans une salle occupée de filles me terrorisait. J’allais devoir retourner en classe de troisième, refaire connaissance avec Pythagore et Thalès. Pit, Thalou, je vous hais, cordialement.

Voici donc ce à quoi ressemblaient les niveaux au commencement, sur papier.

VisuelA

Il était nécessaire de schématiser les niveaux afin de déterminer les “formules géométriques” nécessaires à leur génération. Cela ressemblait donc à des cercles, entrecroisés de droites, dessinant des angles, accompagnés de fractions, souvent raturées parce que fausses. Je n’avais pas une seule seconde imaginé à quel point cela allait être difficile pour moi. Corona SDK n’était pas optimisé pour produire des formes vectorielles (utiliser des courbes de bézier aurait été parfait…) et poussait surtout à l’utilisation d’images. Il allait falloir ruser pour obtenir cet amas tant convoité de boules fusionnées entre elles. Et bien entendu, user de théorèmes de Pythagore et de Thalès.

Je n’ai clairement jamais eu de fibre mathématique. Au collège, jusqu’au lycée, j’ai toujours été obligé de suivre des cours particuliers pour finir laborieusement à me rapprocher de la moyenne en fin d’année. Au baccalauréat, j’ai réussi à m’en sortir avec un joli 6,5/20 en mathématiques. Spécialité S. Oui, tout à fait.

Mais je tenais à tout prix à avoir un jeu tout en courbes. Pour des raisons esthétiques, mais aussi parce que c’était, pour moi, un véritable moyen de me différencier de ce que l’on avait l’habitude de voir. Alors, j’ai persévéré. Je définis un format dans lequel les informations relatives à chaque niveau allait être stockées. Le but étant ensuite de relire ce fichier et que le moteur du jeu génère correctement toutes les courbures. Après un long moment, des fichiers XMLs pouvaient être ainsi chargés et la génération des niveaux se passant plus ou moins comme cela:

Blog-850x480-Gif A ce stade-là, il manquait encore quelque chose. Ces fichiers XML nécessitaient pour le moment être remplis à la main, ce qui allait être extrêmement compliqués. Pour éviter cela, j’allais devoir créer mon propre éditeur de niveau, de zéro. Car à l’époque (et c’est toujours plus ou moins le cas aujourd’hui), Corona SDK n’offrait rien d’autre qu’une fenêtre qui interprète du code, ainsi qu’une autre fenêtre de debuggage. Et c’est tout. Il n’existait aucune interface permettant de positionner visuellement les objets nécessaires à la création d’un jeu.

Après un bon mois à travailler sous Flash, la première version de mon éditeur de niveau était fonctionnelle. En quelques minutes, j’étais ainsi capable de créer un niveau de toutes pièces pour ensuite le tester immédiatement et jouer avec.



Réalisé sous Flash, en ActionScript 1.5 (comprendre : ce n’était pas de l’ActionScript 2, ni de l’ActionScript 1, mais un mélange bâtard assez immonde, même pour moi), cet éditeur de niveau, basique, me permettait de produire des niveaux rapidement sans jamais toucher au code du jeu, de manière “What You See Is What You Get”. En réalité, c’était plutôt “What You See Is Almost What You Get”. Et les niveaux allaient enfin être arrondis, tels que je le souhaitais.

Rapidement, j’étais alors capable de produire des niveaux, les tester, voir ce qu’il allait falloir affiner. En réalité, le gain de temps sur le long terme fut immédiat. L’ajout d’éléments de gameplay était aussi rapide, bien qu’il fallait impérativement repasser par du code.

Le jeu n’allait pas tarder à être fini. Pas vrai ?

Egz Devblog – Partie 6 – Création du prototype

Blog-850x480-Default
Prototype ! Teste ! Recommence ! Re-prototype ! Re-teste ! Re-recommence…”. C’est à peu près ce que j’ai pu lire le plus souvent ou ce que l’on a pu me dire le plus régulièrement. Réaliser un prototype permet de s’assurer que le gameplay fonctionne. Si besoin, cela donne la possibilité de modifier, par exemple, les déplacements du personnage ou de tout recommencer à zéro.

A force que l’on me le répète, j’aurais pu en retenir quelque chose. J’aurais dû.

Mais non. Au mieux, j’ai, par la suite, affiné, modifié certaines choses, mais à aucun moment je n’ai remis en cause les grands principes de gameplay. J’étais trop occupé à m’ahurir devant la simplicité et la vitesse à laquelle mon Egz prenait vie, grâce à la magie de Corona SDK. En quelques jours, voilà à quoi ressemblait mon tout premier prototype.


Le fait est que ce prototype me suffisait. Je trouvais ça déjà rigolo. Surtout, il me permettait déjà de voir tout ce qui n’allait pas fonctionner par rapport à ce que j’avais déjà imaginé dans le document de gamedesign. Par exemple, j’avais imaginé pouvoir donner la possibilité au joueur de se déplacer autrement qu’en sautant. Cela aurait pu fonctionner, cela pourrait même aujourd’hui fonctionner. Mais cela impliquait de prendre en compte beaucoup trop de choses (apprendre de nouvelles mécaniques de jeu au joueur, penser les niveaux de plusieurs façons, multiplier la quantité de code). Or, ce que j’avais à l’époque m’amusait déjà suffisamment. Cela me permettait aussi de me projeter et de me dire que le jeu pouvait fonctionner. Mon but n’était pas non plus de révolutionner le monde du jeu vidéo. Juste de construire un jeu qui fonctionnait. Ce qui était déjà un sacré gros challenge pour moi.

J’allais donc continuer sur cette lancée: les déplacements de l’Egz fonctionnaient, mais ses rebonds et les propriétés du monde physique devaient encore être affinées. Peut-être allais-je un peu vite en besogne, mais je commençais aussi à intégrer quelques visuels, des animations, une interface. Finalement, un nouveau prototype, ou plutôt ce qui ressemblait déjà à une alpha prenait forme.


Tout allait pour le mieux. Presque. Car j’avais probablement avancé un peu trop vite. L’interface fonctionnait, mais il manquait encore beaucoup d’options tandis que d’autres ajouts allaient être faits plus tard. Je ne le savais pas encore, mais l’interface allait être remise en question plusieurs fois durant toute la durée du projet ce qui allait me faire perdre pas mal de temps…

Egz : Devblog – Partie 5 – Je suis un Lonely Woof

Blog-850x480-Default
Je me retrouvais seul. Non pas que j’eus été à un moment donné accompagné de qui que ce soit, mais pour la première fois, l’idée de réaliser ce jeu qui me tenait tant à coeur seul se matérialisait, malgré moi.

Nous sommes au printemps 2013. Je commençais sérieusement à m’ennuyer dans mon travail, tandis que mon projet de jeu stagnait depuis un moment, malgré une vidéo “target-render” qui m’avait un temps motivé.

A l’époque, j’avais donc de gros doutes professionnellement. Au cours d’un déjeuner avec l’un de mes boss, j’avais exprimé mon envie de passer à autre chose et d’essayer de me réorienter dans le jeu vidéo, par exemple. Ce à quoi on m’avait répondu (en substance) que c’était compréhensible. Au détour d’un portrait qui m’était dressé par mon interlocuteur, j’avais été qualifié de “loup solitaire”.

… Dans le cadre du travail, surtout en temps normal, je ne suis absolument pas un loup solitaire. Je suis parfaitement capable de m’intégrer dans une équipe, et j’aime ça. Mais il est vrai qu’à l’époque, j’étais réellement déprimé par mon travail. J’avais opté pour une attitude d’outsider. L’ambiance était morose et c’était alors mon seul moyen de tenir le coup. Et bonne nouvelle pour moi : je me considère comme étant autonome. Je travaillais souvent sur des projets seul ou qui ne demandaient pas de réellement travailler en équipe et finalement, tout le monde était content.

Loup solitaire ?” avais-je répondu d’abord étonné. Puis, l’étiquette m’avait fait sourire, pour finalement me travailler jusqu’au soir. Parce que c’était sûrement vrai, dans le fond. Je ne m’en rendais peut être pas compte. Et ce nom a déclenché quelque chose. L’envie d’y donner du sens. Tant qu’à être qualifié de quelque chose, autant que ce soit totalement justifié, non ? Cela allait passer par mon jeu : j’allais réaliser mon jeu seul, la nuit, simplement éclairé par la lumière de la lune. Ou plutôt par celle de mon écran LCD 24 pouces. Donc voilà : Pierre D., c’est grâce à toi que j’ai choisi ce nom.

Blog-380x280-LW C’est ainsi que ce nom, “Lonely Woof” resta. Légèrement modifié, parce qu’il ne faut pas déconner, “Lonely Woof” c’est un peu trop déprimant et premier degré.

J’allais alors devoir coder. Moi, graphiste de mon état. Salarié de nombreuses entreprises de communication, habitué à dessiner, gribouiller, ou colorier. Dont le niveau en mathématiques se limitait à additionner, voire à soustraire, des nombres sur la calculatrice de mon téléphone.

J’exagère un peu : après tout, j’avais des bases d’Actionscript. Alors je me suis dit que c’était jouable. J’étais alors parti en quête d’un environnement de travail qui allait subvenir à mes besoins : un langage facile, un moteur permettant de jouer avec des règles physiques élémentaires et surtout, supportant iOS et Android.

N’importe qui aurait choisi Unity. D’autant plus qu’un nombre incroyable de jeu ont été développés via ce moteur.

D’autres jeux réalisés avec Unity (Monument Valley, Hitman GO, Format.8) : Unity
Le moteur par excellence des développeurs indépendants : pour sa communauté grandissante, ses librairies et autres modules disponibles, son palmarès impressionnant de jeux déjà publiés (récemment les sublimes “Hitman GO” ou “Monument Valley”). Et bien que dédié à la 3D, il était tout à fait possible de produire un jeu vidéo en 2D (bien avant que cela ne soit officialisé plus tard par l’ajout de Unity 2D).

Mais j’ai choisi de partir sur Corona SDK. Une vidéo tuto postée sur YouTube me poussa à faire ce choix : en moins de dix minutes chrono, un développeur montrait comment réaliser un simple jeu mobile, à l’aide de quelques lignes de code ressemblant étrangement à l’ActionScript. A la fin de cette vidéo, il montrait le résultat fonctionner sur un smarphone, prêt à être joué, à sortir sur l’Apple Store. Magique.

Des jeux réalisés avec Corona SDK (« Gravity Maze », « Dumb Ways To Die 2 », « Out There ») : CoronaSDK

Blog-380x280-Defaut Une commande passée sur Amazon, et “Corona SDK Mobile Game Development” (NB: ce livre est aujourd’hui en partie obsolète, Corona SDK ayant depuis évolué, mais les bases restent les mêmes) arrivait chez moi. Un livre accessible, pédagogique, rempli d’exercices permettant de “créer et monétiser des jeux pour iOS et Android pour un minimum de coût et de code” (sic).

D’ici un maximum de quelques semaines, j’allais enfin réaliser mon fantasme et développer mon jeu, à moi, tout seul. D’ailleurs, en quelques jours, j’avais déjà un prototype jouable.

Egz Devblog – Partie 4 – Création d’une vidéo target render

Blog-850x480-Cover
Le document de gamedesign s’étoffait, l’univers grossissait, la personnalité de l’Egz se définissait. Il ne manquait plus qu’une chose avant d’attaquer la fameuse vidéo : savoir quoi montrer. Et pour cela, il allait falloir entamer les bases du level-design.

L’objectif était ainsi de montrer à quoi une partie “normale” d’Egz pouvait ressembler. Et donc montrer ce que le joueur pouvait faire, ce qui pouvait potentiellement l’empêcher d’y arriver et comment il allait finalement pouvoir y arriver. Faire un niveau donc. Et forcement, ça passe comme toujours par un crayon et un papier.

Blog-850x480-Default
Mon inexpérience en level design

Mes seules expériences dans ce domaine dataient respectivement de 1996 et de 2003. En 1998, j’étais encore au collège et “Duke Nukem 3D” venait de sortir. Ma mère (oh mon dieu, si elle avait vraiment su ce qu’il y avait dans ce jeu…) avait accepté de m’offrir ce guide pour créer des niveaux avec le moteur “Build”. C’était fantastique : j’avais modélisé mon quartier, tel que le moteur de “Duke Nukem 3D » pouvait l’afficher. C’est à dire avec des cubes texturés et c’est tout. Je pouvais tirer des roquettes sur des des aliens trainant dans ma rue, ou bien glisser des billets verts dans les strings des strip-teaseuses qui avaient élu domicile dans ma chambre virtuelle. C’était chouette. Mais le jeu en lui même était déjà fait. Et à l’époque, peu m’importait ce que je pouvais faire : ça restait fun.

Blog-848x251-Book
Puis en 2003, je travaillais dans une petite agence dans laquelle on avait l’habitude de se faire quelques parties en réseau le midi, voire le soir. Rien de tel que le démembrement d’un collègue à l’Ak-47 à “Soldier Of Fortune II” après une dure journée de labeur. Ou peut être … faire tout ça, dans un niveau modélisé d’après les locaux de ladite agence ! Et cette fois, il ne s’agissait pas que de reproduire le plus fidèlement un lieu, mais il fallait aussi que ce soit rigolo pour tous les joueurs. Je me souviens alors avoir fait le choix de “défigurer” la rue, d’y intégrer des échafaudages pour que l’on puisse se tirer dessus depuis l’immeuble d’en face. Une grue avait été ajoutée, permettant de passer d’un immeuble à l’autre… Je crois bien que c’était la première fois que je comprenais certaines notions de “gameplay”, de “leveldesign”.
blog_quoteinJe ne sais pas ce que je fais,
mais je vais le faire quand même!blog_quoteout
Mais tout ça, c’était il y a longtemps. Et ce n’était pas du tout le même contexte. Là, j’étais supposé établir un véritable gameplay et produire un niveau. Les deux choses étant clairement liées. Et c’est ce que j’étais supposé faire. Sans trop savoir comment réellement faire. Même si c’était le déjà le cas depuis longtemps et que je ne m’en étais pas rendu compte, j’allais avancer avec ce leitmotiv en tête : “Je ne sais pas ce que je fais, mais je vais le faire quand même!”.

Voici le tout premier niveau crée, avec 2 chemins différents:

MiniC

Et voilà le Target Render (non terminé) :


Voilà, c’était ce à quoi allait ressembler “Egz”. Un jeu de plate-forme, où l’on déplace un Egz en le faisant faire des sauts en cloche. Il faut viser, être précis, anticiper les chocs, éviter les obstacles présents ou bien savoir tirer profit du décor (les lianes par exemple) pour arriver à destination. Cela allait me permettre de voir ce qui allait marcher, ou pas.

Le jeu a bien entendu pas mal évolué depuis, mais globalement, avec le recul, je réalise que j’ai réussi à conserver cette “vision initiale”, ce dont je suis plutôt fier.

Cette vidéo terminée, j’allais pouvoir contacter des potes afin que l’on puisse se lancer, ensemble, dans cette merveilleuse aventure qu’est “le développement indie de jeu vidéo”.

Spoiler alert : personne n’était chaud. Sans même avoir vu la vidéo. Les raisons ? « Manque de temps« , « pas l’envie« , « c’est beaucoup de travail pour pas grand chose« . Et je suis totalement d’accord. Réaliser un jeu demande énormément d’investissement personnel. Clairement, j’étais le seul dans mon entourage à être prêt à le faire. Très certainement parce que c’était mon fantasme, à moi. Ou peut-être aurait il fallu attaquer le projet à plusieurs, en amont. Mais peut-être ne suis-je réellement qu’un “loup solitaire”.