Enfin!

Je vous l’avoue humblement, je viens de me sortir d’un de mes plus difficiles tests de programmation jusqu’à maintenant!

250 petites lignes de codes qui sont passées proches me rendre fou, je vous le dis.

Comme quoi des fois ce n’est pas la grosseur qui compte… 😉

Dans les précédentes démonstrations  »in game », mon héros est toujours localisé en plein centre de l’écran, ce qui cause un problème de jouabilité à mon avis.  Le joueur voit autant en arrière qu’en avant du personnage, alors que, par définition, le gros de l’action se déroule à l’avant du héros.  Dans ce cas, me direz-vous, on a qu’à déplacer le centre un peu vers la gauche pour laisser plus de champs libre à la droite du héros.  Comme ça on voir les ennemis venir et c’est tant mieux.

Ok, mais si mon héros se déplace tout à coup vers la gauche dans le monde en 2D dans lequel il est contraint?  Là, on ne voit plus rien…

Je voulais donc modifier ma class Camera (qui n’est pas une caméra du tout en fait, mais plutôt une matrice qui calcul la position relative du héros par rapport au monde du jeu, mais bon) pour la transformer en CameraDynamic.  Une caméra qui se placerait au bon endroit en fonction de la direction que le héros emprunterait.

L’idée n’est pas nouvelle.  Les Marios et autres platerformers modernes ont pour la plupart implémenté différentes solutions à ce problème.  Voici ce que mon approches donne:

 

En bonus, si on ne touche à rien, la caméra se recentre tranquillement sur le héros!

Nice, non?

Cadeau de Noël

Joyeux Noël à tous!

Comme cadeau cette année, je m’offre à moi même la première partie du premier niveau de One Man’s!

Avec arrière-plan à effect parallaxe et atmoshpère enfumé (parce que le champs de bataille en France en 1914 était enfumé, non?)

 

Prochaine étape, caméra dynamique et ensuite, un ennemi!!

J’avoue avoir hâte de m’attaquer à l’AI d’un ennemi (mais moins de passer 60 heures à dessiner l’animation du dit ennemi 😉

Blanche Neige

En 1937, les studios Disney réalisaient Banche-Neige et les 7 nains.  À l’aide d’une caméra, les artistes photographiaient 24 dessins, un après l’autre, pour former une seconde d’animation.  Les personnages, ainsi que les objets qui devaient bouger dans la scène étaient dessinés sur des  »cels » (du papier transparent) alors que le décor, plus statique, trônait en arrière plan, opaque.
Un jeu vidéo en 2D utilise exactement la même technique!
Le héros et les ennemis sont dessinés en utilisant un arrière-plan transparent appelé Alpha Channel et le décor empli le fond de l’écran.  La caméra de Disney est remplacer par le cadre donné par les limites du moniteur ou de l’écran de télévision.
Dans le cas de One Man’s Land, j’utilise une technique éprouvé depuis l’aube des jeux vidéos pour animer mon héros.  Le spreadsheet.
Un peu comme la méthode des  »TileMaps » abordée plus tôt, le spreadsheet servait originalement à sauver de l’espace mémoire en condensant en une seul ficher des dizaines de dessins nécessaires aux différentes animations d’un jeu.
Mais contrairement aux  »TileMaps », le spreadsheet ne constraignait en rien ma démarche technique et artistique pour se nouveau projet.
On voit, dans l’exemple suivant, les différentes poses de mon héros.  L’engin du jeu passe chacune des images à tour de rôle à une vitesse prédéterminée pour donner l’illusion du mouvement.
PlayerSpreadSheet
Et comme je suis un dessinateur très ordinaire, le temps qui m’est nécessaire pour pour faire toutes ces poses est tristement démesuré.  Pour preuve, on voit qu’il manque encore certains dessins pour compléter toutes les animations.  La position accroupie ne possède qu’une seule image, alors qu’il en faudrait au moins 5 ou 6 pour créer une illusion de mouvement.
Ça viendra!

Pour ne pas passer au travers du plancher Partie 2

Ma première tentative de détection de collision avec le sol utilisait une méthode de vérification pixel par pixel.  Donc, lorsqu’un élément de dessin de mon héros se superposait à un élément du dessin du sol, il y avait détection de collision et j’empêchais ainsi le joueur de passer au travers du plancher.
Génial!
De cette façon je pouvais dessiner l’arrière plan de n’importe quelle façon et mon personnage réagirait toujours de la bonne manière!
Je me suis rapidement rendu compte, malheureusement, qu’il y avait deux inconvénients majeurs à cette solution.  Tout d’abord, vérifier toutes les pixels à chaque cycle du jeu (donc 60 fois par secondes!), ça coûte cher en capacité de calcul.  En fait, vérifier l’intégrité de mon personnage à chaque cycle gelait carrément mon pc.  Même en réduisant l’espace de vérification, le processus ralentissait de façon notable.  Mes premiers tests, fait avec une petite image (une balle, 8 X 8) ne causait pas de problème, mais là, ça ne fonctionnait plus.
De plus, un pixel, c’est petit.
Je me trouvais dans des situations où mon personnage se tenait par le bout des orteils sur des corniches escarpées sans sourciller (à la Super Mario Bros).

J’ai donc dû jeter aux rebuts 1 mois de code et me lancer dans une nouvelle direction.

Le nouvel engin de détection, celui qui est toujours en vigueur en ce moment, est beaucoup plus léger, mais demande du data provenant du niveau.  Chaque niveau doit contenir une suite de coordonnées qui forme une ligne brisée, une sorte de rail, sur lequel le héros à la permission de se mouvoir.  Il peut être plus haut que cette ligne (sauter, tomber d’une falaise, grimper, etc.), mais il ne peut jamais être plus bas.
Pour ceux qui me connaisse, j’avoue avoir travaillé fort pour retrouver les mathématiques nécessaires à cette implémentation (la pente, l’intersection de l’axe des ordonnées)!
Outre le fait de devoir fournir un liste de coordonnées à l’engin pour chaque niveau, cette solution semble tenir la route pour le moment.
Prochaine fois, on parle de spreadsheets et d’animation 2D!!

Pour ne pas passer au travers du plancher Partie 1

Lorsque je me suis mis au travail sur One Man’s Land, je venais à peine de terminer mon projet précédent.  Il s’agissait d’un  »plateformer » assez classique ayant pour thème une émission de télévision que mes filles suivaient beaucoup lorsqu’elles étaient plus jeunes.

Les niveaux étaient construits en utilisant un  »tile map », technique utilisée sur de plus vieux titres à l’époque où la mémoire était extrêmement limitée.  L’idée est de dessiner une seule tuile (tile) et de demander à l’ordinateur de la reproduire aux endroits désirer dans le niveau de jeu.  Il y aura ainsi des tuiles représentant le sol, d’autres représentant des plateformes, ou des briques de maison, ou toutes surfaces que le joueur pourrait rencontrer.   Outre l’économie de mémoire, l’avantage de ce système est qu’on a pas besoin d’être un très grand artiste pour dessiner une tuile potable, et, en plus, la détection de collision est assez simple à implémenter.

Dans l’exemple suivant, tirer de mon  »plateformer » déjà mentionné (ceux qui ont de jeunes filles reconnaitront Fraisinette), on voit que tout, à l’exception du héros, est composé de ces tuiles.  Même les feuilles au sol.

Le tout fonctionne assez bien, le joueur ne passe pas au travers du plancher et peut sauter sur les plateformes, et en plus il passe au travers des tuiles en arrière plan (qui constituent l’espèce de décors en montagnes).

Très fonctionnel, mais extrêmement statique!

Très cartésien, trop cartésien.

Il était hors de question que je fasse un  »tile map » pour One Man’s Land.

Je voulais des décors dessinés à la main, quelque chose de moins figé et, disons-le, plus moderne dans l’éxécution.

Je vous raconterai dans la prochaine entrée de quelle façon on ne passe pas au travers du plancher dans mon nouveau projet!

Première entrée!

Et voilà, c’est parti!

Après un rapide coup d’oeil, mon premier repository pour One Man’s Land date du 10 janvier 2015.  J’ai donc quelques mois de retard dans ma chronique, mais je vais me rattraper rapidement et tenter de nous faire un « digest » des premières étapes déjà passées.  Soyez sans crainte, je me souviens parfaitement des problèmes rencontrés et des jurons lancés.