Cette semaine malgré la grippe et la gastro persistante de Godzilla, j’ai remanié mes sprites pour que leurs activités soient basées sur la géométrie vectorielle. Il me reste encore beaucoup de travail sur ce sujet. À partir de ma première implémentation de la classe Sprite, j’en ai fait une plus simple pour qu’elle puisse gérer les sprites sans animations. Avec une image en fait. Je voulais une sprite pouvant représenter un projectile simple et qu’il soit utilisable des milliers de fois à l’écran afin de pouvoir créer un « Bullet Hell » ou "manic shooter".
Avant de définir ce qu’est le « Bullet Hell », je dois expliquer à quel genre mon jeu appartient. Il s’agira d’un jeu basé sur Gradius de Konami. Dont voici une image :
Un « Bullet Hell » est tout simplement un « shmup » où le joueur est littéralement submergé par le feu ennemi. Les projectiles sont déployés selon des patterns qui, à l’écran, donne un rendu presque artistique. Comme des feux d’artifices mettons. Le joueur doit ce frayer un chemin à travers cette pluie infernale et éliminer son adversaire. Cette vidéo montre exactement ce qu’est un « Bullet Hell ».
Ce que l’on remarque d’abord, c’est que le gameplay est vertical. Cela semble faciliter la création de patterns pour les projectiles. C’est comme-ci elles formaient des fleurs ou des fractales. On remarque également qu’il y a très peu on pas d’obstacles ce qui facilite grandement la gestion des collisions. Le nombre d’entités actives autres que les projectiles, autrement dit les acteurs, est limité au joueur et son adversaire. Ce qui facilite encore le processus de collision. D’ailleurs dans la plupart des « Bullet Hell » que j’ai observés, le nombre de projectiles atteignait vraiment son maximum lors de combat avec les boss. Et en plus, il y a rarement des obstacles environnementaux pour compliquer la navigation. Certes, il y a des ennemis, mais ils ne sont pas calculés dans le système de collision avec leurs projectiles. Ce que je veux dire, c’est qu’on vérifie s’il y a collision entre le joueur et les ennemis et le feu ennemis. Mais pas entre les ennemis et le feu ennemis. Enfin, je ne sais pas trop comment l’expliquer, mais en regardant attentivement les vidéos, on peut voir que le feu ennemi passe à travers les autres ennemis. Ok, passons…
En fait, on semble rechercher une chose. Maximiser le nombre de projectiles au détriment de l’environnement interactif. J’ai voulu essayer ce genre justement pour voir jusqu’à quel point je pouvais gérer une grande collection de projectiles, d’acteurs et d’obstacles. Si j’arrive à des résultats intéressant, je suis intimement persuadé que je pourrai faire n’importe quel autre jeu en 2D par la suite.
À la suite de mes recherches sur youtube pour trouver des démos de « Bullet Hell », j’ai trouvé également trouvé cette vidéo montrant le Gradius original remanié par un amateur.
Cette vidéo montre bien le gameplay original de Gradius. Par contre, l’auteur a voulu en faire un « Bullet Hell » et je ne crois pas qu’il a réussi. Comme je l’ai expliqué plus haut, le nombre de projectile devrait être beaucoup plus élevé, et à mon avis, on dépasse rarement la centaine. Par contre, l’auteur à implémenté un environnement navigable mais si vous regardez attentivement, vous verrez que les projectiles passent à travers les obstacles. Bien sur, il s’agit probablement d’un projet en cours de développement tout comme le mien. Mais quand l’auteur aura appliqué les fonctions de collisions de détections, les performances de son jeu ne seront plus les mêmes. Et il doit le faire, on ne peut pas permettre que les projectiles passent à travers les murs. S’il y a des murs, c’est pour aussi fournir au joueur une protection contre les balles.
Revenons à nos moutons. Après plusieurs tests sur mon jeu, j’ai réussi à remplir mon écran avec des milliers de balles se déplaçant au hasard dans l’écran. Elles n’ont pas d’animations et ne gèrent pas les collisions. Voici une vidéo de mon jeu en action :
Mon vidéo.
On voit d’abord la scène qui défile avec un arrière plan à thématique spatiale. L’avant plan est une série de briques qui forment l’environnement. Je les ai créées avec TileStudio.
Peu après, les premières balles apparaissent. J’en fais apparaître environ 2000 sans pertes de « frame rate ». À la fin, la scène en contient environ 10 000 avec un frame rate qui passe de 80 à 30. La scène est de 1000 x 600 pixels. On ne peut pas la voir en pleine grandeur avec le vidéo youtube. Il faut comprendre que c’est la première fois que je fais un "screencast" et le résultat est assez ordinaire. En réalité, l’animation est plus fluide et l’image plus claire. Par contre, je m’attendais à des résultats plus intéressants. J’aurais voulu atteindre au moins ce que Harbour a obtenu avec son démo de sprite mais sans succès. Il a pu afficher 10000 sprites sans problèmes apparents. Il n’y avait pas de statistiques affichées. Il faut dire que les conditions ne sont pas identiques. Son démo n’a pas d’arrière-plan, ni d’avant plan. Et ces sprites ne bougent pas. Toutefois, elles sont animées et plus grosses. À force de recherche sur le web, j’ai pu apporter quelques optimisation à la façon de faire le rendu de mes sprites, mais si je tiens à avoir une performance optimale, je crois que je devrai migrer mon programme vers JOGL qui est une API gérant OpenGL. Ça sera à voir. Pour le moment, je continue à développer avec les API standard de Java. Mais avec certaines optimisations et de bons choix de conception, je crois que je peux atteindre un résultat impressionnant.
Parmi ces optimisations, je vais utiliser des managers pour les différentes catégories d’entités. Par exemple, j’ai créé la classe EnnemyFireManager qui contient une collection de 2000 balles. Le rôle du manager est de faire l’initialisation, la mise à jour du mouvement et les requêtes d’affichages de chaque balle. Le manager créé les objets balles à l’avance pour les utiliser plus rapidement. C’est lui aussi qui contient les images des projectiles. Il les affiches une fois que les balles ont été mises à jour. Ma classe est encore loin d’être optimale, mais j’ai l’impression que je suis sur la bonne voie.
Il y a aussi des façons d’optimiser la vitesse des rendus dans java2D, mais ces optimisations sont au détriment de la qualité. Par exemple : une résolution plus faible. Ce qui implique moins de pixels à traiter, mais des images moins détaillées. Il y aura donc des compromis à faire.
Au niveau du jeu, les situations vont décider de la quantité de balles qu’il sera possible d’afficher. Par exemple, dans l’introduction des courses. À la manière de Gradius, le joueur se trouve dans un environnement en plein espace, sans obstacles. Ces zones sont propices à plus d’acteurs ennemis, mais moins de balles puisque l’on est au début. Il faut respecter le tempo. Cela donne des situations ou le joueur doit détruire ses ennemis pour amasser un arsenal adéquat pour la suite. Il pourrait y avoir aussi des zones avec plus de terrains mais moins d’ennemis pour favoriser la navigation. Et quand sera venu le temps du « Bullet Hell » avec un joueur pleinement équipé, le terrain sera réduit au minimum ou carrément absent, avec peu d’ennemis et une tonne de balles. Tout est une question d’équilibre finalement.
En terminant, voici un lien intéressant sur le genre « shoot’em up ». Il contient des jeux, des fiches techniques, un dictionnaire sur le monde du « shoot’em up » et plus encore. Mais attention, je soupçonne les jeux disponibles propices aux virus…
http://www.shmup.com/
Avant de définir ce qu’est le « Bullet Hell », je dois expliquer à quel genre mon jeu appartient. Il s’agira d’un jeu basé sur Gradius de Konami. Dont voici une image :
On appel ce genre « 2D space shooter » ou « shoot’em up » ou encore « shmup ». Essentiellement, le joueur est représenté par un vaisseau spatial et il doit affronter vague après vague de d’engins ennemis. Le but étant de survivre jusqu’à la fin de la course. Pour survivre, le joueur doit détruire ses ennemis, ramasser les bonus laissés par ceux-ci et éviter le feu ennemi. Dépendamment du sous-genre, il y a des obstacles à éviter ce qui ajoute un élément de navigation. À la de chaque course, on rencontre un ennemi plus difficile à vaincre. Il s’agit du boss. Les « shmup » ce présentent généralement sous deux formes : avec action horizontale et action verticale. Ces formes réfèrent au défilement de l’action. Horizontale, le joueur progresse de gauche à droite et verticale, de haut en bas. J’ai choisi le mode horizontale parce qu’il offre plus de facilités pour la navigation entre les obstacles du terrain. Par contre, comme il y a plus d’obstacles à gérer, le système de détection de collision devient plus lourd ce qui peut limiter le nombre d’entités affichables à l’écran. Ceci, m’amène donc à parler du sous genre « Bullet Hell ».
Un « Bullet Hell » est tout simplement un « shmup » où le joueur est littéralement submergé par le feu ennemi. Les projectiles sont déployés selon des patterns qui, à l’écran, donne un rendu presque artistique. Comme des feux d’artifices mettons. Le joueur doit ce frayer un chemin à travers cette pluie infernale et éliminer son adversaire. Cette vidéo montre exactement ce qu’est un « Bullet Hell ».
Ce que l’on remarque d’abord, c’est que le gameplay est vertical. Cela semble faciliter la création de patterns pour les projectiles. C’est comme-ci elles formaient des fleurs ou des fractales. On remarque également qu’il y a très peu on pas d’obstacles ce qui facilite grandement la gestion des collisions. Le nombre d’entités actives autres que les projectiles, autrement dit les acteurs, est limité au joueur et son adversaire. Ce qui facilite encore le processus de collision. D’ailleurs dans la plupart des « Bullet Hell » que j’ai observés, le nombre de projectiles atteignait vraiment son maximum lors de combat avec les boss. Et en plus, il y a rarement des obstacles environnementaux pour compliquer la navigation. Certes, il y a des ennemis, mais ils ne sont pas calculés dans le système de collision avec leurs projectiles. Ce que je veux dire, c’est qu’on vérifie s’il y a collision entre le joueur et les ennemis et le feu ennemis. Mais pas entre les ennemis et le feu ennemis. Enfin, je ne sais pas trop comment l’expliquer, mais en regardant attentivement les vidéos, on peut voir que le feu ennemi passe à travers les autres ennemis. Ok, passons…
En fait, on semble rechercher une chose. Maximiser le nombre de projectiles au détriment de l’environnement interactif. J’ai voulu essayer ce genre justement pour voir jusqu’à quel point je pouvais gérer une grande collection de projectiles, d’acteurs et d’obstacles. Si j’arrive à des résultats intéressant, je suis intimement persuadé que je pourrai faire n’importe quel autre jeu en 2D par la suite.
À la suite de mes recherches sur youtube pour trouver des démos de « Bullet Hell », j’ai trouvé également trouvé cette vidéo montrant le Gradius original remanié par un amateur.
Cette vidéo montre bien le gameplay original de Gradius. Par contre, l’auteur a voulu en faire un « Bullet Hell » et je ne crois pas qu’il a réussi. Comme je l’ai expliqué plus haut, le nombre de projectile devrait être beaucoup plus élevé, et à mon avis, on dépasse rarement la centaine. Par contre, l’auteur à implémenté un environnement navigable mais si vous regardez attentivement, vous verrez que les projectiles passent à travers les obstacles. Bien sur, il s’agit probablement d’un projet en cours de développement tout comme le mien. Mais quand l’auteur aura appliqué les fonctions de collisions de détections, les performances de son jeu ne seront plus les mêmes. Et il doit le faire, on ne peut pas permettre que les projectiles passent à travers les murs. S’il y a des murs, c’est pour aussi fournir au joueur une protection contre les balles.
Revenons à nos moutons. Après plusieurs tests sur mon jeu, j’ai réussi à remplir mon écran avec des milliers de balles se déplaçant au hasard dans l’écran. Elles n’ont pas d’animations et ne gèrent pas les collisions. Voici une vidéo de mon jeu en action :
Mon vidéo.
On voit d’abord la scène qui défile avec un arrière plan à thématique spatiale. L’avant plan est une série de briques qui forment l’environnement. Je les ai créées avec TileStudio.
Peu après, les premières balles apparaissent. J’en fais apparaître environ 2000 sans pertes de « frame rate ». À la fin, la scène en contient environ 10 000 avec un frame rate qui passe de 80 à 30. La scène est de 1000 x 600 pixels. On ne peut pas la voir en pleine grandeur avec le vidéo youtube. Il faut comprendre que c’est la première fois que je fais un "screencast" et le résultat est assez ordinaire. En réalité, l’animation est plus fluide et l’image plus claire. Par contre, je m’attendais à des résultats plus intéressants. J’aurais voulu atteindre au moins ce que Harbour a obtenu avec son démo de sprite mais sans succès. Il a pu afficher 10000 sprites sans problèmes apparents. Il n’y avait pas de statistiques affichées. Il faut dire que les conditions ne sont pas identiques. Son démo n’a pas d’arrière-plan, ni d’avant plan. Et ces sprites ne bougent pas. Toutefois, elles sont animées et plus grosses. À force de recherche sur le web, j’ai pu apporter quelques optimisation à la façon de faire le rendu de mes sprites, mais si je tiens à avoir une performance optimale, je crois que je devrai migrer mon programme vers JOGL qui est une API gérant OpenGL. Ça sera à voir. Pour le moment, je continue à développer avec les API standard de Java. Mais avec certaines optimisations et de bons choix de conception, je crois que je peux atteindre un résultat impressionnant.
Parmi ces optimisations, je vais utiliser des managers pour les différentes catégories d’entités. Par exemple, j’ai créé la classe EnnemyFireManager qui contient une collection de 2000 balles. Le rôle du manager est de faire l’initialisation, la mise à jour du mouvement et les requêtes d’affichages de chaque balle. Le manager créé les objets balles à l’avance pour les utiliser plus rapidement. C’est lui aussi qui contient les images des projectiles. Il les affiches une fois que les balles ont été mises à jour. Ma classe est encore loin d’être optimale, mais j’ai l’impression que je suis sur la bonne voie.
Il y a aussi des façons d’optimiser la vitesse des rendus dans java2D, mais ces optimisations sont au détriment de la qualité. Par exemple : une résolution plus faible. Ce qui implique moins de pixels à traiter, mais des images moins détaillées. Il y aura donc des compromis à faire.
Au niveau du jeu, les situations vont décider de la quantité de balles qu’il sera possible d’afficher. Par exemple, dans l’introduction des courses. À la manière de Gradius, le joueur se trouve dans un environnement en plein espace, sans obstacles. Ces zones sont propices à plus d’acteurs ennemis, mais moins de balles puisque l’on est au début. Il faut respecter le tempo. Cela donne des situations ou le joueur doit détruire ses ennemis pour amasser un arsenal adéquat pour la suite. Il pourrait y avoir aussi des zones avec plus de terrains mais moins d’ennemis pour favoriser la navigation. Et quand sera venu le temps du « Bullet Hell » avec un joueur pleinement équipé, le terrain sera réduit au minimum ou carrément absent, avec peu d’ennemis et une tonne de balles. Tout est une question d’équilibre finalement.
En terminant, voici un lien intéressant sur le genre « shoot’em up ». Il contient des jeux, des fiches techniques, un dictionnaire sur le monde du « shoot’em up » et plus encore. Mais attention, je soupçonne les jeux disponibles propices aux virus…
http://www.shmup.com/
Bon, j'ai amélioré le nombre de bullets que je peux afficher à l'écran. Maintenant je peux en afficher 5000 au lieu de 2000 en gardant un FPS acceptable (55fps).
RépondreSupprimer