02:17 Mot de passe oublié ?

30

./27 > Ben ouais, mais quels objets ont besoin d'interagir avec quels objets ? De quelle manière ? (Pas au niveau implémentation, mais au niveau fonctionnel)
Si un objet x n'a pas besoin d’interagir avec un objet y, c'est pas la peine de t'embêter à rendre ça possible.

De manière générale, tu te contenterais de relations entre les objets. Mais si tu commences à avoir trop de relations entre les objets, alors c'est pas la bonne solution. Mais ça, tu le sais qu'à partir de tes besoins concrets.
Par exemple, pour une map, représenter chaque tile par une instance d'objet distincte, c'est un coup à se tirer une balle dans le pied. Mais pour des objets de jeu (joueur, bonus, ennemi, projectile…) ça se tient tout à fait.
Sauf qu'en général, tu ne voudras pas gérer tous les objets de ton niveau de manière simultanée, parce que tu auras peut-être 5000 objets dans ton niveau mais seulement 30 à l'écran ou proche de l'écran, du coup tu ferais sans doute une seconde liste d'objets. (De fait tu auras deux représentation de ton niveau, une représentation "figée", et une représentation "animée")
Mais si tes objets veulent interagir avec ceux qui ne sont pas encore à l'écran (enfin c'est un peu ce que j'ai l'impression de comprendre que tu veux rendre possible en parlant de message), alors il faut penser à un mécanisme plus complexe.
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

31

Je pense tout simplement au tile magique qui donne une arme quand le perso le traverse. A la base, on peut se demander ce qu'un tile a à voir avec les armes du perso.
Donc pour moi les possibilités sont :
- un passage de message (le bloc émet un message "donne arme truc à perso", le dispatcher envoye ça gentiment au perso). Mais c'est hyper casse-noisettes d'écrire une quantité de classes de messages et de les gérer dans tous les sens.
- des vars globales. Ajout brutal de l'arme à la liste par le bloc. C'est bien crade amha.
- un accès à la liste des armes du perso. Le bloc fait un : this -> level -> getPerso () -> getLitseArmes () -> addArme ("canon à troll version yAronet");

C'est crade ce genre de méthodes ?

32

Moi je choisirais la troisième possibilité dans ce cas wink
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

33

Ok, merci. Il y a des cas où c'est conseillé, d'autres à proscrire j'imagine, des mix entre messages et ce genre de choses ?
Par exemple, les messages je ne pourrai pas y couper si j'ai besoin de timer : "le bloc truc explose dans 5 secondes". Comme j'utilise SDL, faudra qu'une callback émette un event 5 secondes plus tard pour traiter le problème (le moteur tourne autour du traitement des events (hw, timers) de SDL). Mais à mon avis, ça reste limité comme emploi des messages, donc ça devrait aller.


En tout cas, merci pour ton ton temps et ta sali ton énergie digitale, je suis dur de la comprenette apparemment grin

34

Ben tu pourrais tout simplement avoir une liste de blocs à faire exploser (plus exactement, une pile FIFO), avec un timestamp, et un truc identifiant le bloc.
À chaque fois que tu veux faire exploser un bloc "plus tard", tu rajoutes un élément à la fin de la file, et puis voilà.
À chaque trame, tu vérifies si le temps est écoulé pour le premier élément, et lorsque c'est le cas, tu le "fais péter" et tu le supprimes de la liste. Ça ne demande même pas forcément de timer ou de messages wink (Pour des délais variables c'est un mini-poil plus complexe parce qu'il faut une liste toujours triée par ordre temporel)
Mais ça c'est une solution spécifique à un cas spécifique. (Qui n'est plus forcément aussi bien si tu veux un mécanisme similaire pour x autres trucs ^^)
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

35

Le truc, c'est que ça demande à ce que le moteur fasse une vérification de cette liste à chaque frame, et comme tu le soulignes, c'est très rigide. Et en fait, je me prends la tête, il y a une fonction toute cousue pour ce genre de trucs : int SDL_SetTimer(Uint32 interval, SDL_TimerCallback callback);

36

À voir combien de timers SDL peut gérer simultanément.
avatar
— Zeroblog —

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

37

Tu peux créer des singleton: un gestionnaire de maps, d'entités, de tile... Ça permettrait de gérer la communication perso contrôlé - tiles / blocks / poneys de facon totalement interne au singleton.

Pour le coup des vérifications à chaque frame, tu peux te contenter de le faire à chaque fois qu'une entité se déplace, qu'elle soit sur l'écran ou pas (selon un booléen dans la classe de cette entité, par exemple bool Entity::AlwaysUpdate() { return _alwaysUpdate; } qui définit si même si l'entité n'est pas sur l'écran, elle doit être "updatée". à partir de là, plus besoin de timers, sauf dans le cas de délais nécéssaires. Comme le dit GC' tu restes un peu trop générique pour qu'on puisse te répondre clairement, mais c'est normal pour un premier projet de jeu scrollable tongue
avatar

38

Merci bien happy

Le coup des singletons, je sais pas trop quoi en penser. Par contre, j'ai découvert l'usage d'un membre statique dans une classe, ça peut être fun ça, je vais voir comment je peux rigoler avec cheeky

39

(un rien t'amuse ^^)
avatar
— Zeroblog —

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

40

Attend, ça fait des tas d'expérimentations sur du code poubelle à faire grin

41

L'avantage du singleton c'est juste de ne pas avoir plusieurs instances d'une classe tongue Je dois par contre avouer que je ne sais pas comment la mémoire est gérée avec un singleton, sachant que je suis dév web à la base, mes connaissances à ce sujet se basent sur PHP (qui est déplorable à ce niveau). Faudrait que je creuse, tiens grin
avatar

42

(juste une remarque comme ca: t'as pas de gestion native dans le langage des singletons hein, c'est toi qui l'implemente comme tu veux en C++, donc la "gestion de la memoire", c'est toi qui decide tongue)
avatar
HURRRR !

43

OK donc c'est comme dans PHP, c'est bon à savoir, j'sais maintenant pourquoi mes programmes leak grin
avatar

44

Folco (./40) :
Attend, ça fait des tas d'expérimentations sur du code poubelle à faire grin


GT calin Folco wink
avatar
Accrochez vous ca va être Cerebral !!

45

Au moins, dans un jeu à la Mario, les éléments de décor réagissent de la même façon à tous les "objets" (Mario, ennemis), la plupart des exceptions étant simplement des objets qui ignorent entièrement le décor (fantômes, cheep cheep qui sautent à travers les ponts, marteau de Hammer Brother...) il n'y aura donc pas besoin de double-dispatch à ce niveau-là.

Ensuite pour les objets... 'faut voir.
avatar
Maintenant j'ai la flemme de garder une signature à jour sur ce site. Je n'ai même plus ma chaîne Exec sous la main.
Aide Charte Contacts Crédits Réalisé avec yAronet 110 ms