Discussion :

[ShinobiX1]

Bonsoir à tous
je voudrais savoir comment je peux programmer une fonction qui gère des objets temporaires comme
des balles de pistolet ou des missiles dans le cas d'un Shoot'em up


Y-a-t-il une façon simple de le faire?

L'ordinateur ne sait pas quand et combien de fois je vais tirer, alors je ne peux pas utiliser une variable ou un tableau à taille fixe je pense


merci pour vos réponses , idées et suggestions !

[LittleWhite]

Bonjour,

Certains jeux font une piscine (pool) d'objets (de missiles, par exemple). Dans le sens, il faut un tableau, qui dès le début du jeu est alloué avec 500 objets (aucun objet actif pour le début, bien sur, mais l'espace mémoire est réservé).
Pourquoi une telle solution ?
-> Car sur console (et un peu sur PC), les allocations de mémoire et les déallocations sont lentes (du moins, plus lent que d'autres fonctions). De plus, car la mémoire était limitée et qu'il était bien plus pratique de dire : ok, on a 500 missiles max et on sait que l'on ne dépasse jamais.

Coté implémentation :
-> Simplement un tableau avec les informations de chaque missile (une structure). Il faut un entier, pour stocker le nombre d'objets actuellement actifs. Celui permet de savoir quelle case du tableau utilisée lorsque l'on rajoute un objet. Lors de la mort (l'objet n'est plus utile), il suffit de faire un swap entre la case de l'objet et la dernière case active, et de diminuer le nombre d'objet actif de un. Ce qui invalidera l'objet qui a été mis à la fin (faites un schéma )

Coté mis à jour des objets :
-> une simple boucle qui parcours le tableau, parcours que sur les éléments actifs. Chaque objet est mis à jour selon ses paramètres.


En C++ (ou en orienté objet, plus généralement), ça peut être un peu plus simple, avec un objet qui possède une fonction membre "update".

Pour la mort des objets, c'est souvent :

• soit, il y a une collision ;
• soit, il est sorti de l'écran.

[ShinobiX1]

pour gérer mes missiles, je dois utiliser un tableau de structure disons de 50 missiles (comme avec le temps ou les collisions certains missiles vont disparaitre, donc on aurait toujours un nombre en dessous de 50 je pense) , sa position x et y, et sa vitesse de croisière, son état (détruit ou sorti)

l'état servirait à réutiliser la structure pour un nouveau missile

si je dois utiliser d'autres tableaux pour les missiles ennemis , comme dans le cas où un stage a 20 vaisseaux ennemis , ça me ferait 21 tableaux à créer?


l'algorithme serait comme ça?

1 tire missile joueur détecté (par exemple j'appuie sur "espace")


2 parcourir le tableau de mes missiles pour ajouter le missile dans une structure libre

3 une fois trouvée la structure libre, j' enregistre ses attributs (x , y, vitesse , état)

4 effacer missile (on enlève la dernière postion du missile)

5 afficher missile (on ajoute la nouvelle position du missile)


pour le 4 et le 5 je ne sais pas si l'ordre est correct
car au tout début il n'y a pas de missile à effacer

~~ code

[LittleWhite]

21 tableaux O_o

Vous êtes en orienté objet, ou pas ?

2 parcourir le tableau de mes missiles pour ajouter le missile dans une structure libre

Non.
Vous avez le nombre d'éléments actifs, donc vous savez directement à quel index insérer/activer un nouvel élément.

Pour 4 et 5, je ne comprends pas. Pour afficher, on ne touche pas à la position. Pour effacer un missile ... euh, dans un jeu on efface tout l'écran, d'un coup et on raffiche tout à chaque fois, c'est bien plus simple.

[ShinobiX1]

je ne suis pas sur de penser comme vous concernant ce tableau, pouvez-vous m'expliquer un peu ?

sinon je pense que si je dois gérer tous les missiles sans distinction de leur origine (soit je tire ou un ennemi tire), dans ce cas, j'utilise un seul tableau

je programme en c++ mais en faisait du c aussi

concernant l'effacement de l'écran , je n'y avais pas pensé comme ça
effectivement c'est plus simple
!

[LittleWhite]

Ok, on va essayé d'expliquer.
Disons que l'on a un tableau de cinq éléments :[*][ ][ ][ ][ ]

Là, ils sont vides, c'est normal, c'est le début.
On a aussi un compteur d'élément actif, qui est à zéro, pour le moment :
compteurElemActif = 0;

Ok, on lance la partie, l'utilisateur (ou l'IA) lance un missile. On doit initialiser un élément :
[elem1][ ][ ][ ][ ]

On met à jour le compteur :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

compteurElemActif++;

C'est cool.
Pour ajouter un élément (un nouveau), il suffit d'utiliser compteurElemActif.
Regardez :

tableau[compteurElemActif], correspond toujours à la première case vide.
Ici, il vaut 1, donc il correspond à la seconde case (car en C, on compte à partir de 0).
Donc à chaque initialisation d'élément on doit le faire à la position :
tableau[compteurElemActif].init(); // Par exemple.

Bref, on s'amuse et disons que 3 missiles ont été tirés, ce qui fait :

[elem1][elem2][elem3][ ][ ]
compteurElemActif vaut 3


On veut retirer le second missile. Pas de problème. On peut soit utiliser un flag d'activité (un boolean), mais ce n'est pas vraiment nécessaire. Regardez bien.
elem2 n'est plus utile (il est sorti de l'écran).
Du coup, on enlève un élément actif :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

compteurElemActif--;

(Maintenant, compteurElemActif pointe sur elem3, mais cela ne suffit pas, en effet, elem3 et actif et c'est elem2, que l'on veut "oublié".)
On va donc les inverser (swap) :
[elem1][elem3][elem2][ ][ ]

Comme compteurElemActif vaut 2, elem2, ne sera pas affiché, car la boucle d'affichage utilise compteurElemActif, pour savoir le nombre d'élément à afficher.


Et voilà, je pense avoir détaillé le principe.

[ShinobiX1]

merci je vais tester cette méthode , si j'ai d'autres questions ou un problème , je reviendrai

sinon en fouillant le web, j'ai lu qu'on peut utiliser le vecteur ou bien une collection, qu'en pensez-vous?

[LittleWhite]

Une collection, ce n'est pas C++, c'est plus Java ou C# du coup, j'ai du mal à vraiment voir ce que cela représente.
Un std::vector, c'est un tableau à taille dynamique. En C++11, je pencherai plus sur un std::array, pour ne pas m'embêter avec le risque d'avoir une allocation sans faire exprès (après un push_back()). Mais bon, normalement, cela n'arrive jamais.
Le std::vector, il faut l'utiliser (pour ne pas avoir gérer de pointeur, car les pointeurs, faut pas les gérer, le PC peut le faire), mais à la déclaration/construction, il faut faire un reserve() (ou utiliser le constructeur, en spécifiant une taille). Afin qu'il fasse bien l'allocation des N éléments que l'on veut, directement (et que l'on ne risque pas d'autres allocations par la suite).

[Kannagi]

pour gérer mes missiles, je dois utiliser un tableau de structure disons de 50 missiles (comme avec le temps ou les collisions certains missiles vont disparaitre, donc on aurait toujours un nombre en dessous de 50 je pense) , sa position x et y, et sa vitesse de croisière, son état (détruit ou sorti)

Si ça peut te rassurer je fais comme cela , et ça marche bien.

21 tableaux O_o

Qu'est qui te choque , normalement cela se trouver dans une structure Bullet par exemple donc pour ma part je vois rien étonnant , après peut être que c'est un peu inutile de faire un tableau de 50 * tirs pour les ennemis et il peut réduire ce tableau a 10 par exemple et on peut optimisé on considèrent seulement les ennemis a écran ce qui fera qu'il aura des données statique pendant le jeu (et donc pas de malloc/free en plein jeu et avec optimisation en mémoire).


Pour algo il faudra effectivement faire un tri (mais c'est pas ce qui manque les algo de tri sur le net).

[LittleWhite]

Je ne parlais pas encore du tri (dans l'explication que j'ai donné, j'en avais pas besoin). Et puis, moi, mon tableau, il est global (ça veut dire que toutes les bullets de tous les éléments sont dans un unique tableau) (je dis pas variable global, je dis, global au jeu).

Comment évitez vous la création de tableau à la volée, si vous avez une création d'ennemies à la volée ?
Ou alors, vous avez un tableau d'ennemies, que vous gérer comme je l'ai décris ?

[Kannagi]

Oui enfin dans la pratique ce n'est pas super agréable de gérer cela sur un seul et même tableau surtout si les tirs sont assez différents ,donc il faut toujours être raisonnable sur optimisation et lecture du code , mais il peut gérer ça sur un seul tableau mais ce n'est pas obligatoire , enfin en terme de pratique il devra aussi faire une boucle sur tout les bullets pour les collisions alors que il n'en aurait pas besoin si les donnée serait séparés (testé seulement ceux des ennemis).
Mais qu'il soit global ou non faudra faire quelque tri tout de même (enfin ce que tu fais si j'ai compris c'est un tri a la volée , les élément qu'on voudra enlevé seront toujours a 'droite' du tableau).

Sinon oui on a un tableau d'ennemi ,créer des ennemis a la volé me semble pas être une bonne idée en soi (surtout que un ennemi c'est quoi quelque variable).
On C ou C++ on a quelque chose c'est les pointeurs , il saura forcément quel ennemi et a écran/ou actif , donc de donner une adresse (des bullets) a chaque vaisseau (je rappel a écran/ou actif) , il connaitre son jeux mais imaginons qu'il se fixe pas plus de 20 ennemis a écran , il aura qu'a charger "20 tableaux" qu'il donnera adresse au vaisseau actif/a écran (et pourra toujours faire en sorte que les vaisseaux ayant un pointeurs nul n'agit pas au cas ou y'a dépassement).

[LittleWhite]

J'avais (et j'ai encore) un peu de mal à voir comment vous mettez en place votre architecture.
Pour savoir à qui appartient ma bullet, je peux toujours avoir un pointeur sur l'entité ayant initiée la bullet (très mauvaise idée car l'ennemi pourrait mourir et m'entrainer un accès sur une mauvaise référence) ou juste garder un int de propriétaire (genre, des groupes (un groupe allié, un groupe ennemie)).
Je ne vois pas en quoi ma méthode est plus compliquée, sachant que je peux clairement tirer parti de l'orienté objet (peux importe le type de bullet que j'ai, elle hérite d'une classe Bullet, et même d'une classe Objet (pour le déplacement/mis à jour))). En terme d'optimisation, oui, on perdra surement un peu, car j'utilise à mort les vtable et autre, mais sincèrement c'est de la micro optimisation si j'en viens à ce point (note : à part si la console cible ne supporte pas le C++, mais là encore, en 2014, je pense que cela n'existe plus ).
Mon code semble simple (je m'enfonce pas trop dans les structures, mais élément sont géré en un parcours, non imbriqué).
Après, les deux méthodes fonctionnent, je n'en doute pas. Je trouve tout de même l'overhead mémoire avec votre méthode un peu plus gros (un ennemie est obligé d'avoir son tableau de N bullet), si on a 25 ennemies avec 20 bullets chacun (qu'il les aient tirés ou pas), on obtient le même nombre d'éléments qu'avec ma méthode.
Oui, je ferais une boucle pour les tests de collisions sur tout mes bullets, je risque de perdre un peu de temps, mais on ne peux pas faire moins (vous avez le même problème avec votre méthode, mais certes, ok, vous enlevez la partie "bullet des joueurs" (mais un jour, faudra bien les tester avec les ennemies, donc on en revient vraiment au même).
Mon parcours est toutefois optimisable avec un classique quad tree (pour un jeu 2D évidemment). En effet, moi, je peux prendre mon tableau est le réorganisé en zone logique. Je n'ai pas nécessairement besoin d'utiliser beaucoup plus de mémoire, si je me débrouille bien. Que vous, vous allez déjà devoir parcourir les N ennemies (les bullets ne sont pas nécessairement dans la même zone que l'ennemie en lui même) puis les bullets, pour les classer par zone. Là, bien que cela ne soit pas impossible, il faudra surement un stockage temporaire (genre, élément classifié), même si cela se fait avec des pointeurs.

Alors, sur une machine actuel, ou une machine un peu plus vieille, là, on parle d'optimisation et de polish un peu extrême car nous n'aurons pas de soucis, d'un point de vue générale, mais j'essaie de mettre en avant pourquoi ma méthode me semble un peu plus évidente.

Ah oui, vous avez aussi une dépendance très forte bullet <-> ennemie, et il me semble que si l'ennemie meurt, ses bullets ne peuvent rester.

[Kannagi]

Je n'ai pas dit que ta méthode était mauvaise , mais je revenais sur un point ou j'avais impression que tu était 'choquée' sur un point alors qu'au final ça revient au même.
Pour la complexité elle est relatif , je parle plus en fait que ma façon de voir et que chaque entité a sa donnée , chaqu'un a sa façon de codé mais pour la mienne c'est celle la.
Si tu mélange les donnée ben faudra que chaque bullet a quelque info en plus , pour incrémentation que t'a faite faudra faire une différence entre incrémentation du tir joueur et celui des ennemis/boss qui seront eux pas pareil , donc prévoir un tableau temporaire pour informer quel type de bullet c'est : vitesse ,sprite ect (vu que c'est pas le même type de tir).

Oui, je ferais une boucle pour les tests de collisions sur tout mes bullets, je risque de perdre un peu de temps, mais on ne peux pas faire moins (vous avez le même problème avec votre méthode, mais certes, ok, vous enlevez la partie "bullet des joueurs" (mais un jour, faudra bien les tester avec les ennemies, donc on en revient vraiment au même).
Mon parcours est toutefois optimisable avec un classique quad tree (pour un jeu 2D évidemment). En effet, moi, je peux prendre mon tableau est le réorganisé en zone logique. Je n'ai pas nécessairement besoin d'utiliser beaucoup plus de mémoire, si je me débrouille bien. Que vous, vous allez déjà devoir parcourir les N ennemies (les bullets ne sont pas nécessairement dans la même zone que l'ennemie en lui même) puis les bullets, pour les classer par zone. Là, bien que cela ne soit pas impossible, il faudra surement un stockage temporaire (genre, élément classifié), même si cela se fait avec des pointeurs.

ça revient pas au même parce que pour les ennemis tu testera les bullets ennemi sur les ennemi , alors que moi je testerai que celui du joueur.
Je vois pas ce qui m’empêche de réorganiser aussi mes zones avec mes bullets ,Le quad tree me semble exagérer sauf si on fait un danmaku.

Ah oui, vous avez aussi une dépendance très forte bullet <-> ennemie, et il me semble que si l'ennemie meurt, ses bullets ne peuvent rester.

C'est peut être la différence de nos méthode ,j'ai une vision très procédural et indépendante de chaque structure donc pour te répondre , les bullets resteront je prend un exemple grosso modo.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
Bullet bullet[20];
 
init(bullet[0]);
 
// dans la boucle
ennemi[5]->bullet = bullet[0];
//admettons que ennemi meurs
ennemi[5]->bullet = NULL;
 
tir(bullet[0]);

L'ennemi peut mourir ces données seront toujours traité.

J'ai parlé optimisation parce que je me suis dit que c'était cela qui "t’étonnai".

[LittleWhite]

Étonné ? Je ne sais pas J'explore juste votre façon de faire pour en tirer les pour et les contres

quel type de bullet c'est : vitesse ,sprite

Pour moi, cette information est essentielle, même dans votre cas. Notamment car si un ennemi tire des bullet dans deux directions différentes, l'information est nécessaire, même dans votre cas (ou un truc m'échappe).

[Kannagi]

Pour moi, cette information est essentielle, même dans votre cas. Notamment car si un ennemi tire des bullet dans deux directions différentes, l'information est nécessaire, même dans votre cas (ou un truc m'échappe).

faudrait quoter toute ma phrase sinon elle n'est pas compréhensible , oui moi aussi je devrais le faire mais j'aurais pas de tableau temporaire et ce tableau devra avoir ce genre info (juste pour différencier les différent tir a initialisation).

[LittleWhite]

Pourquoi parlez vous d'un tableau temporaire ? (pour la vitesse ?)

[Kannagi]

Bon je reprend , pour ton exemple tu fais

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

compteurElemActif++;

Si le joueur et ennemi partage ce même tableau , faudra initialiser la position du tir ( le joueur et pas a la même position que les ennemis , pareil pour les ennemis entre eux) , la vitesse sont pas pareil (on général ceux des ennemi sont plus long).
Sur mon cas les donnés etant sparer je saurais ou ce trouve la position ,et qui l'a incrémenté (donc sa vitesse aussi).

Donc t'es d'accord que faudra les différenciés vu que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

compteurElemActif++;

ne permet pas de savoir qui l'a incrémenter.
Donc pour ma part je ferais un tableau temporaire , si on a incrémenter 2 fois en même temps sur ce tableau on aura information de qui l'a incrémenter (et des infos relative a celui ci).

[LittleWhite]

Euh, sauf que la demande de création de Bullet, chez moi, se fait pas les entités même (joueur ou ennemies) et qu'ils initialisent la Bullet en passant le minimum d'information : Type + Position + Vitesse. Et voilà, c'est tout. Le tableau gardera toutes les Bullet et tout va bien (enfin, je crois).

[Kannagi]

T'as pas compris je crois , je pars sur ton raisonnement et donc que toute les donnés sont global et pourquoi je parle de tableau temporaire (c'est toi qui me l'a demandé) je t'explique pourquoi ton aurait besoin avec ta méthode et pas la mienne.

Donc oui je sais que tu met tout sur ton tableau , mais a 'initialisation' tes bullets faudra bien savoir quoi mettre dedans "Type + Position + Vitesse" ok d'accord mais quel info tu as pour savoir qui a demandé un nouveau tir ?

[LittleWhite]

Global, dans le sens, mon tableau de Bullet est global au jeu (donc, visible que dans la boucle de jeu )
Sinon, je n'ai pas besoin de connaître l'initiateur du tir, car c'est lui même qui créer la nouvelle Bullet (donc, qui initie le tir).