Une petite vidéo qui retrace où j’en suis dans le développement de One Man’s.

 

 

Attention de ne pas confondre le  »state of the game » avec le Game State 🙂

(un peu niche comme blague, je le concède)

Hey,

je viens d’ajouter un nouvel onglet – autres projets – sur le site de One Man’s Land.

Vous y trouverez pour le moment une petite vidéo de présentation de ma dernière application qui sert à générer des listes d’épicerie automatiquement!

Salut!

Juste un petit mot pour vous dire que je viens d’ajouter une vidéo présentant mon ancien projet « Fraisinette » sous l’onglet du même nom.  Le repository est aussi accessible via cet onglet.

De beaux souvenirs 😉

Nah, je n’ai pas retiré le sang qui gicle pour rendre le projet  »tout public ».  Au contraire, ça va empirer!  Yeah!

Non, la démo d’aujourd’hui est à l’épreuve de mon enfant, de ma fille de dix ans, à qui je montrais fièrement l’animation de mon héros il y a deux semaines.  À l’épreuve de la petite qui, voyant ça, m’a dit:  »Y’a des bugs papa!  Quand il atterrit après le saut, ça n’a pas de sens.  Et quand il arrête de marcher, y’a aussi un bug… ».

Quoi?  Tu sais c’est quoi un bug?  Ils apprennent ça au primaire maintenant?  Et il n’y a pas de bug tu sauras ma chérie, le compilateur me dit que tout va bien.

Bon, là elle se met à sauter dans la pièce pour me montrer comment on atterrit après un saut, dans la  »vraie vie ».

 »Tu vois, je ne tombe pas accroupie, je reste presque complètement debout… »

D’accord, mais tu ne sautes pas douze pieds dans les airs dans le but d’ouvrir le crâne d’un boche à grand coup de tomahawk toi, ma petite chérie – que je me dis.

 »Oui, mais c’est un jeu vidéo, c’est normal ma belle.  Bon, il est l’heure d’aller au lit maintenant. »

 »Papa, il est 15h… »

Je couche la marmaille, je me sers un scotch, et je refais le tour de mes animations.  Bordel, c’est vrai que ça bug.  Les transitions ne sont pas très fluides, le héros saute de position dans certains cas et quand il atterri, ben, c’est pas très jolie.

Me faire challenger par une enfant de dix ans, ce ne se passera pas comme ça.  Je revisite toutes les animations.

C’est long.

Et là, c’est mieux.  Mais ne me parlé plus de petits bonhommes avant un bon bout.  Ça me donne comme un goût de vomi dans la bouche que le scotch ne parvient pas à effacer.

 

240 dessins sur le premier  »spreadsheet ».

 

90 dessins sur le deuxième  »spreadsheet ».

 

330 petits dessins juste pour faire bouger le héros.

Pas de pouvoir spécial encore, pas d’animation de mort, rien de farfelu.

Mais ça donne quelque chose de satisfaisant.

Et ma plus vieille était contente 🙂

 

 

Oh, et vous remarquez que le méchant boche disparaît vers la trentième seconde?

Quand le héros balance son tomahawk?

C’est le début d’un combat ça!

On est en 1995, on est pas bien vieux et on joue, sur notre SNES, à Donkey Kong Country.

Bon, je ne joue pas vraiment.  En 1995, je ne suis plus si jeune que ça finalement (!) et de jouer à un scroller 2D sur un Nintendo un samedi soir n’est plus trop ma tasse de thé.  Mais je regarde mon petit frère jouer, et on trouve ça visuellement capoté.

L’année d’après, le même développeur (Rare) sort Killer Instinct en se servant sensiblement de la même technologie : le Advanced Computer Modeling.  À une époque où les jeux en 3D n’existent tout simplement pas, on est jeté par terre.  Les animations sont tellement fluides tout à coup, les personnages tellement réalistes.

En 1995, faire du rendu 3D demandait des machines dédiées ultra performante.  La SNES étaient à des années lumières de pouvoir afficher autre chose que des sprites.  Les petits génies de Rare se sont alors dit :  »Faisons une animation rendue en 3D sur une machine dédiée, mais sauvegardons chacun des frames comme s’il s’agissait d’un dessin! »  Il ne restait que assembler les dessins sur un spreadsheet et s’en servir comme n’importe quel sprite de l’époque.  Simple, mais génial.

Aujourd’hui, la méthode ne revêt aucun intérêt.  Les engins de jeu moderne calculent plus de trucs en un cycle que ces anciennes machines de rendu 3D dédiées en une journée.

Mais…

Mais, si quelqu’un avait envie de sauver du temps de dessin, de parvenir à un niveau de qualité visuel plus intéressant et que, comme par hasard, l’engin de son jeu était fait pour gérer des sprites, et bien, ça pourrait devenir une avenue intéressante 🙂

Voici où nous en sommes.  Soyez indulgent, il manque encore quelques animations, tel le saut.

Oh, et ce nouveau look du héros ne cadre plus beaucoup avec l’arrière plan, au niveau esthétique on s’entend.  Il sera redessiné en temps et lieu pour redonner une homogénéité à mon ambiance, mais pas tout de suite.

 

J’en suis a terminer les animations manquantes et à faire celle pour le méchant.

Ensuite, c’est une course pour qu’on puisse enfin donner un coup de tomahawk au boche!!  Je commence vraiment à avoir hâte de pouvoir minimalement jouer au truc….

 

Pour relancer mon automne, et changer le mal de place, j’ai composé un petit thème musical pour le jeu.  Quoi?  Le jeu est presque terminé et on en est à ajouter la musique? Déjà?

Ben non.

L’engin est pas mal dans le même état que lors de notre dernière discussion.  Par contre, le visuel est en, hum disons, transition.  Comme vous le constatez avec le nouvel entête du site, ainsi qu’à l’image accompagnant mon petit indicatif musical, je change un peu l’esthétique du jeu.

Je vous en reparle très prochainement, avec vidéo à l’appui, promis!

Mais d’abord, place à la musique!

 

Dans le but d’accélérer le travail de dessin qui m’attend dans les prochaines semaines, j’ai pris le temps d’écrire une petite application qui permet de tester mes animations simplement, sans avoir à les tester  »in-game ».

Je peux changer certains paramètres, comme quelle  »strip » utiliser sur une feuille, et la vitesse d’animation.

Il s’agit probablement d’un premier module d’un level editor qui pourrait exister un jour.

Ça donne ceci:

 

Grâce aux conseils de mon prof de programmation, j’ai aussi changer d’approche concernant la détection de collision.

Le nouveau code est beaucoup plus simple à gérer, et me permet d’ajouter simplement de nouveaux objets dans la liste de trucs qui ont à être vérifier.  Ma classe Player a aussi été améliorer pour permettre l’ajout de nouvelles fonctionnalités de façon agréable.

Le métier entre tranquillement 🙂

Bon, tout ça ne donne pas un jeu, mais ça avance malgré tout!

Je garde le cap sur mon objectif qui est d’être capable de donner un coup de tomahawk dans la gueule du boche avant le mois d’avril!

 

 

 

 

 

 

 

Ce fut un gros mois!

Mais qui n’a pas donné beaucoup de résultats visuels.  Je suis passé à travers la phase 1 du  »refactoring » de mon engin, passage obligé si je veux ajouter des fonctionnalités au jeu (genre, heu, se battre contre les méchants, et finir le niveau!).

La nouveauté du dernier mois se retrouve dans l’ajout d’une classe qui sert à contenir les informations pertinentes des objets du jeu pour leur permettre d’interagir entre eux.  Le défi n’était pas tant d’écrire cette classe, qui est somme toute bien simple, mais de détricoter les liens étranges qui unissaient mes différents objets.

Exemple : dans l’ancienne méthode bricolée, une balle de fusil devait donner sa position à l’ennemi qui devait passer l’info à la classe  »level », qui devait ensuite remettre cette donnée à l’objet  »player » pour enfin vérifier s’il y avait une collision entre les deux.  Et je ne parle pas ensuite de réagir à cette collision.

En fait, c’est exactement ce cas qui m’a convaincu qu’il y avait du travail de code à faire avant de poursuivre l’ajout de nouvelles fonctionnalités.

Maintenant, le héros n’a qu’à demandé à la  »classe qui sait tout » ou se trouve la balle de fusil, et le tour est joué!  Une fois tout ça démêlé, j’ai pu avancer pas mal plus rapidement.

Voici donc ce que ça donne.

Notez que la collision entre la balle et le joueur fonctionne réellement maintenant.  Et le comble, le bouclier, des mois plus tard, sert enfin à quelque chose!!

Et oui, il y a effectivement un début de barre d’énergie, mais c’est très  »work in progress ».  Elle n’est pas lié aux dommages reçus par le joueur pour le moment, mais ça ne saurait tarder!

 

Je passe maintenant à la phase 2 du  »refactoring ».  Je m’apprête à ajouter un tas de comportement à mon joueur et à son nemesis.    Ces deux classes devront être d’une propreté exemplaire si je veux m’y retrouver.  Les projectiles, c’est une chose, le combat à mains nus, c’est un autre niveau de complexité!

Qui sait, peut-être, lorsque nous nous reverrons, le boche sera-t-il en mesure de bouger ses pieds 🙂

Bonne nuit à tous

 

 

Juste une petite vidéo pour vous montrer ou nous en sommes avec les balles de fusils promises.

Me semble que le potentiel de jouabilité est déjà démultiplié!

Mathieu = content 🙂

 

 

Un petit vidéo pour montrer la balle trop grosse qui suit enfin une trajectoire qui a du sens!

La variable  »angle » de la balle ne sert plus à rien.

Il fallait plutôt normaliser le vecteur donné par la différence entre la position du joueur, et la position du méchant.  J’avais travaillé sur une approche du genre la semaine dernière, mais sans le bout  »normalisé ».  La balle partait de tous les côtés!

Merci à Google de m’avoir :

a) expliqué que ça existait  »normalisé » un vecteur (!)

b) expliqué comment le calculé 🙂

Ah, vive les maths…

 

Hé, vous avez même droit à un screenshot final d’un bout de code.

En passant, GeForce Experience, c’est totalement génial pour capturer du vidéo!  Merci pour le cue Guillaume.