Aujourd'hui j'ai une question plutôt en rapport avec la conception.
Je suis actuellement en train de développer un platformer en 2D avec SFML et il se trouve que l'on peut utiliser des lances-grenades qui lancent des grenades explosives dans mon jeu. Ça fait des explosions plutôt sympathiques et je suis très content du résultat final.
Le code marche très bien si je m'arrête là, mais j'aimerais aussi faire en sorte que les explosions affectent l'environnement et je vais être obligé de revoir cette partie de mon code.
Juste pour avoir une petite idée :
Pour l'instant, j'ai une classe Explosion. Les explosions sont contenues dans un conteneur. Chaque explosion peut-être activée ou désactivée. Une explosion "activée" signifie qu'elle doit encore être "appliquée" aux éléments du jeu (pour l'instant que les joueurs). Le problème c'est que la "désactivation" de l'explosion, je la fais manuellement (lorsque j'ai appliquée l'explosion sur mes joueurs) et c'est pas top.
Du coup, voilà ma question :
Comment vous y prendriez vous pour représenter une explosion dans votre code ? Et comment faire pour qu'elles affectent une seule et unique fois les éléments du jeu (joueurs, murs, etc...) ? J'ai pas besoin de formules, j'aimerai juste avoir votre vision du problème d'un point de vue purement conceptuel.
Je me rends compte que sans contexte c'est peut-être un peu dur mais ce que je cherche vraiment c'est un avis extérieur sur le sujet, une vision différente de la mienne, pas une solution parfaitement adaptée à ma situation.
Comment vous y prendriez vous pour représenter une explosion dans votre code ? Et comment faire pour qu'elles affectent une seule et unique fois les éléments du jeu (joueurs, murs, etc...) ?
Oh ba j'utiliserai le système de particules de Unity . Plus sérieusement, si je devais coder un système d'explosion avec collision, je m'en inspirerai fortement.
L'idée est simple, tu as un point central, l'émetteur de particules (le coeur d'une explosion). Dans ton cas, une particule peut être représenté par un sprite, lequel aura une box collider. Si une particule rencontre un élément du décor, on la détruit et on agit en fonction sur le décor qui a été touché.
Le plus compliqué dans tout ça c'est d'avoir une trajectoire de particule qui donne l'impression d'une explosion naturelle, si on veut faire les choses bien on pourra éventuellement ajouter une plage de random pour l'angle d'émission des particules, ce qui peut être un petit plus niveau design.
Comment vous y prendriez vous pour représenter une explosion dans votre code ? Et comment faire pour qu'elles affectent une seule et unique fois les éléments du jeu (joueurs, murs, etc...) ?
Oh ba j'utiliserai le système de particules de Unity . Plus sérieusement, si je devais coder un système d'explosion avec collision, je m'en inspirerai fortement.
L'idée est simple, tu as un point central, l'émetteur de particules (le coeur d'une explosion). Dans ton cas, une particule peut être représenté par un sprite, lequel aura une box collider. Si une particule rencontre un élément du décor, on la détruit et on agit en fonction sur le décor qui a été touché.
Le plus compliqué dans tout ça c'est d'avoir une trajectoire de particule qui donne l'impression d'une explosion naturelle, si on veut faire les choses bien on pourra éventuellement ajouter une plage de random pour l'angle d'émission des particules, ce qui peut être un petit plus niveau design.
- Edité par Guit0Xx il y a moins de 30s
J'y ai pensé moi aussi mais en general lors d'une explosion, les particules ne proviennent pas de l'engin explosif lui même mais des elements environnants.
Perso j'aurais plus vue ça d'un point de vue purement physique. L'explosion crée une onde de choc ou force radiale qui repousse tout ce qui ce trouve sur son chemin. Après ça depends du degré de realisme que tu souhaites, mais à priori ça ne m'a pas l'air compliqué à implementer.
Donc ton idée ça serait de représenter l'explosion non pas par une impulsion instantanée mais par de vraies "débris" qui inflige des dégâts et projettent les joueurs. Pas mal !
C'est différent de ce que je fais actuellement (juste une impulsion avec une animation) mais c'est clairement faisable. Et surtout, ça résoudrait un problème important : empêcher que les explosions traversent les murs. Si je représente ça avec des particules, ça serait beaucoup plus simple à gérer.
@eugchriss
Ça reste un jeu, donc je vais pas faire un truc méga réaliste mais c'est vrai qu'une onde de choc peut être intéressante. Après, je peux toujours combiner ça avec l'idée de Guit0Xx en faisant des particules invisibles qui infligent quand même des dégats.
Perso j'aurais plus vue ça d'un point de vue purement physique. L'explosion crée une onde de choc ou force radiale qui repousse tout ce qui ce trouve sur son chemin. Après ça depends du degré de realisme que tu souhaites, mais à priori ça ne m'a pas l'air compliqué à implementer.
Aussi . Après selon la physique d'un jeu, si une particule avec une masse conséquente est envoyée avec assez de force elle repoussera automatiquement tout élément intéragissant avec la gravité.
Raynobrak a écrit:
Donc ton idée ça serait de représenter l'explosion non pas par une impulsion instantanée mais par de vraies "débris" qui inflige des dégâts et projettent les joueurs. Pas mal !
Yes .
Après l'idée de @eugchriss n'est pas mauvaise non plus si j'ai bien compris. En gros, il y'aurait une onde de choc (pas forcément visible) représentée par un cercle qui gonflerait et où tu chercherais les différents points d'intersection avec d'autres objets. Si il y'a collision, on applique une force sur l'objet touché dans la bonne direction.
C'est de la simple trigo', suffit de trouver l'angle du point d'intersection par rapport au centre de l'explosion quand il y a collision et d'envoyer l'objet valser en conséquence.
Après tout dépend, disons qu'un système d'envoi de particules, si c'est bien fait, tu peux le ré-utiliser pour autre chose que des explosions.
Au pire je fais les deux techniques en même temps, l'onde de choc pour l'impulsion et les particules pour les dégâts.
Mais je pense que je vais plutôt partir sur les particules, parce que avec l'onde de choc, ça va être compliqué de gérer quand un mur bloque le passage. Au final, ces deux techniques reviennent un peu à la même chose (des points qui s'éloignent de l'explosion), juste que ça sera calculé différemment.
Par contre, perso j'aurai pas utilisé la trigo. J'aurai commencé par calculer un vecteur unitaire pour la direction et ensuite j'aurai calculé l'intensité de ce vecteur. Bon, au final, ça ressemble beaucoup à la trigo et si on creuse un peu ça donne pratiquement les même calculs.
Allez, je vais faire avec les particules et je vais garder mon animation d'explosion pour donner un meilleur rendu visuel. Je vais essayer de faire des particules en forme de rectangles de tailles et de couleurs différentes pour donner un effet unique à chaque explosion.
Je vais faire ça maintenant et si j'y pense, je posterai une capture d'écran ou une vidéo pour vous montrer le rendu final !
Voilà ! C'était un peu plus long à faire que prévu, mais voici le résultat actuel :
C'est pas encore fini, j'aimerais aussi faire en sorte que chacun des débris aie une taille et une couleur différente et éventuellement que la couleur change en fonction du temps écoulé (comme si le débris se refroidissait).
Mais bon voilà, c'était juste pour vous montrer le résultat car j'ai dit que je le ferai
Ah oui et faites pas attention aux textures des blocs ahah
Ah oui, effectivement mon idée était un peu trop réaliste pour ce type de jeu.
Vu que que tu es parti sur l'idée de particles system, pour la couleur, tu peux stocker differentes types de teintes (genre celles ci par exemple) dans un tableau. Ensuite la vie de chaque particule correspondra à l'indice du tableau de teintes à utiliser pour la couleur de la particule en question. Je ne sais pas si c'est clair....
Pour la taille, je ne sais pas si on parle de la même chose, mais il me semble que les particules rappetisent au fur et à mesure, non?
Avis perso, c'est peut-etre dû au rapport taille des particules/ taille des blocs, mais ça fait bizarre de voir les particules rebondir ^^.
Hier j'ai pu finir la version finale avec tailles de particules et couleurs aléatoires. Pour les couleurs, la particule démarre avec une couleur au bol (jaune, orange ou brun) et cette couleur de départ va s'assombrir au fil du temps jusqu'à ce que la particule disparaisse .
Du coup, voilà la version finale pour les curieux :
bacelar a écrit:
Heu, sinon, c'est pas les moteurs physiques qui manquent non plus.
En fait, c'est la partie que je trouve la plus passionnante dans le développement d'un jeu. C'est pour la même raison que j'utilise pas Unity ou Unreal Engine.
eugchriss a écrit:
Ah oui, effectivement mon idée était un peu trop réaliste pour ce type de jeu.
Vu que que tu es parti sur l'idée de particles system, pour la couleur, tu peux stocker differentes types de teintes (genre celles ci par exemple) dans un tableau. Ensuite la vie de chaque particule correspondra à l'indice du tableau de teintes à utiliser pour la couleur de la particule en question. Je ne sais pas si c'est clair....
Pour la taille, je ne sais pas si on parle de la même chose, mais il me semble que les particules rappetisent au fur et à mesure, non?
Avis perso, c'est peut-etre dû au rapport taille des particules/ taille des blocs, mais ça fait bizarre de voir les particules rebondir ^^.
Sinon GG, toi au moins t'as un truc concret....
Du coup, je suis parti sur un système un peu différent pour la couleur. Chaque particule a une couleur de base, et je calcule la couleur à un temps donné en multipliant chaque composant de la couleur par le pourcentage du temps de vie restant de la particule, ce qui a pour effet de l'assombrir petit à petit.
Et puis pour la taille, elles commencent avec une taille de base et, comme pour la couleur, je multiplie la taille par le pourcentage du temps de vie restant.
Je fais rebondir les particules parce que c'est elles qui donnent des dégâts au joueur (je crois qu'on le voit sur le GIF) et je trouve ça plus sympa parce que ça permet d'éviter que l'explosion soit 'étouffée' si un truc explose dans un coin.
Bref ! Je vais essayer d'éviter de transformer ce post en devblog ahah
En fait, c'est la partie que je trouve la plus passionnante dans le développement d'un jeu. C'est pour la même raison que j'utilise pas Unity ou Unreal Engine.
Héhé, j'ai tenu le même discours pendant 1 an, puis un jour j'ai testé Unity. Après je comprends parfaitement ta vision de la chose, on a envie de faire les choses nous même et finalement c'est assez formateur et gratifiant.
Mais... tout dépend de ton objectif. Si par la suite tu souhaites créer ton propre moteur, pourquoi pas, mais... c'est un boulot de titan. Et seul, je doute fort que l'on puisse rivaliser avec des moteurs déjà existant qui eux, sont gérer par toute une équipe depuis des années.
Après il ne faut pas croire, ce n'est pas parce qu'on utilise Unity ou Unreal qu'on ne fait rien. Bien au contraire, cela permet de se concentrer sur la logique du jeu tout en évitant de devoir taper 3 ou 4 lignes de codes pour créer un sprite alors que typiquement c'est un truc répétitif dont on ce fou complètement.
La majeure partie du temps on a le nez dans les scripts, ba oui la rocket ne va pas s'envoler toute seule puis il va falloir lui indiquer quoi faire si elle touche quelque chose. Perso j'utilise surtout l'éditeur pour me faciliter la tâche dans l'édition d'une scène (placement d'entité, point de trigger, ajustement de la lumière etc). Quand à la partie comportement, calcul et algo' c'est full scripted.
Et puis... faire un jeu demande bien plus d'effort qu'on ne pourrait le penser, d'autant plus si on est seul. Il faut créer ses models 2D/3D (en admettant d'avoir une bonne patte graphique :p), s'occuper du level design, s'occuper du son, s'occuper du scénario, s'occuper de l'animation etc, etc. Et crois-moi, c'est un sérieux atout d'utiliser un moteur déjà existant.
Maintenant si ton objectif est vraiment de créer un jeu, je ne me fais pas trop de soucis, en principe tu finiras tôt ou tard par te tourner vers un moteur qui s'occupera des tâches ingrates pour toi.
Le jour où le moment inertiel (l'élan) ou le moment cinétique de rotation de l'explosif, les courants d'air, les caractéristiques physiques du décor, etc.. vont avoir de l'intérêt pour le gameplay (et je l'espère pour l'expérience ludique de votre jeu), vous allez très vraisemblablement pleurer des larmes de sangs alors qu'en utilisant ces moteurs (et en comprenant leurs mécaniques internes), vous serez à même de savoir très rapidement si c'est faisable avec la plateforme cible (n'importe quel crétin peut faire un jeu qui tourne sur une machine à minage de Bitcoin).
En plus, l'usage d'un moteur généralement vous permet d'inventer des axes d'amélioration du gameplay des plus sympa.
EDIT :
+1000 avec @Guit0Xx, et c'est vrai que pour une première expérience avec des effets de particule "fait main", c'est vraiment pas dégueu.
- Edité par bacelar 19 avril 2019 à 14:33:58
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Oh, je ne critique en rien les moteurs de jeu tels que Unity ou UE. Si je veux me lancer dans la création de jeux à un niveau professionnel, je serai pratiquement obligé d'apprendre à utiliser ces outils, car comme vous l'avez les deux dit, cela permet de consacrer plus de temps sur des éléments plus important, tels que le gameplay, le level design, etc...
Ce platformer c'est plutôt un challenge pour m'entrainer. Je le développe avec un pote, il s'occupe surtout des textures (sans lui, il n'y aurait que des rectangles colorés ).
Guit0Xx a écrit:
En tout cas, sympa le résultat .
- Edité par Guit0Xx il y a environ 1 heure
Merci
Comment représenter une explosion ?
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
...
Eug
...
Eug
...