PureBasic

Salut,

ça fait un petit moment que je joue a divers jeux type : Empyrion , Space engineers ...

et je me posais une question (dont la réponse m'est venu tout a l'heure d'une coup, alors que je n'y pensais meme plus
le cerveau est etrange , comme si il travaillait en tache de fond a un probleme qu'on c'ets posé il y a 10 jours ... bref ...

pour ce type de jeux 3d , il y a un principe d'objet qui diffuse de l'energie (une batterie)

et des cubes de constructions... qui permettent de construire bases, vaisseaux, vehicules etc....

il y a aussi des objets qui en contact avec les cubes ,fonctionnnent comme par exemple des moteurs , des lampes
des portes, des pistons etc....


et ça fait environs 10 jours que je me demandais , mais comment les programmeurs ont gerés le fait

qu'une batterie , "diffuse" le courant dans les cubes en contacte avec elle, mais aussi en contacte avec d'autre cubes (comme une chaine)
pour alimenter un objet lampe ou moteur etc .....



bien sur si on supprime un cube de la "chaine" le courant ne passe plus a partir de la coupure......


reflechissez un peut a ça , et donnez moi votre perception du truc ....
j'ai trouvé une solution.... mais je voudrai connaitre votre réflexion a ce sujet, qui n'es pas si évident de prime abords

en clair , comment feriez vous ça vous ???

notez que ça peut aussi concerner la 2D (sprites ) par exemple

Salut Zorro,

Pas certain d'avoir compris ta question, mais à mon avis une classs de type construction comporte une liste (vide à la base) d'autres objets qui vont la composer.

Les objets de construction hérite d'une classe abstraite avec toutes les méthodes qui pourront être appelée par la class de construction.

Chaque objets de construction exécutera une action différente selon son type.

Avec ce type de développement il est très facile d'ajouter par la suite d'autre objet et faire ainsi évoluer le jeu.

ha mais toi tu as une vision "Objet Code" du truc
moi je parle en temps de codeur procedural

pas de "classe" et autre potion magique (mais je dois dire que tu es proche de ce que j'ai pensé )
mais c'est plus simple que ça



ma question porte surtout sur la transmission du courant (de l'ennergie)
d'un bloc a l'autre du point de depart (la batterie) au point d'arrivé (la lampe)

ou un moteur ....

On peut être voir cela comme une liste chaînée. Ainsi chaque information passe de l'un à l'autre

Avec une structure ?
Je suis peut être à coté de la plaque...

non Shadow !! c'est ça !!

j'ai mis 12 jours pour finir avec cette conclusion !!


voici le resultat de ma reflexion :

bravo a shadow ...

j'ai bien fait d'arreter la prog moi LOL

Merci Zorro

Ouais, bon bha tu as trouvé, c'est bien déjà

Tu sais, avec mon convertisseur de code Visual Basic en PB ou j'en est chier un max et sans aucune aide de personne, j'ai appris pas mal
de chose et je suis arriver à faire se que je voulais, je dois avouer que moi même je n'en revenais pas du résultat final

Le truc ardu c'est se que tu as dis, mais pas d'autre solution que la récursivité !
C'est très efficace !

L'écrasante majorité des fonctionnements ci-dessous sont tirés du fonctionnement en jeu d'un bon nombre de mods Minecraft. À quelques rares exceptions près je n'en ai pas regardé le code source.

I) Considérations
Il y a plusieurs systèmes possibles qui dépendent du comportement souhaité, des ressources utilisées et du nombre de cachets d'aspirine ingurgités.

Parmi les comportements souhaités :
- stockage (ou non) d'énergie tampon
- contrôle de la répartition de l'énergie en fonction de divers paramètres (niveau des équipements, type d'équipement, réglage du joueur, contrôle d'une zone)
- temps de propagation de l'énergie (ressemble plus souvent à une conséquence qu'à un choix)
- nécessité de l'équilibre production/demande/stockage.
- niveau de réalisme par rapport à une chaîne de transmission réelle : (électricité, liquide, gaz, mécanique)
- débit maximum réalisable
- circulation dans un ou plusieurs sens
- détection des courts circuits (boucles) de manière proactive ou passive.
- économie du CPU en fonctionnement à vide ou à saturation du réseau
- économie du CPU lors du fonctionnement ou lors de la modification du réseau.
- présence pertes de charge/effet joule
- inertie des liens pour simuler des coups de béliers
- ...

Dans tous les cas, pour la gestion de la répartition plusieurs modes de fonctionnement peuvent coexister dans chaque système :
- répartition par stockage égalitaire entre pair
- répartition par consommation
- répartition (pseudo-)aléatoire
- répartition dans l'ordre (de détection, d'une liste)
- répartition par catégorie
- répartition à tout de rôle
- ...

Dans tous les cas, la détection des autres éléments avec lesquels interagir peut être faite :
- automatiquement par simple détection de distance/direction (puis éventuellement mise en cache)
- par le joueur à la mise en place du réseau.
- événementielle à chaque ajout/déplacement/suppression d'élément
- par exploration systématique et cyclique de toutes les possibilités
En cas de mise en cache le système doit pouvoir détecter les changements pour éviter (entre autres) les pointeurs nuls, les index de tableaux invalides et autre joyeusetés qui peuvent faire crash le jeu.

Dans tous les cas, le lancement des calculs peut être :
- systématique ou temporisé selon la production et/ou la consommation
- déclenché par un/le producteur
- déclenché par un/le consommateur
- une combinaison de tout ça sinon c'est pas marrant...

II) Répartitions de l'énergie

Système par pot commun, semble être la solution préférée des moddeurs mais c'est peut être un artifice du fait de sa généralité.
Sur le principe, tous les éléments sont directement reliés à un unique point relais qui matérialise le pot commun. Il peut être présent en jeu ou entièrement virtuel. Sur un réseau on liste l'ensemble des producteurs, des consommateurs et des capacités de stockage. On calcule la demande et la production totale et, au besoin, ce que le stockage peut absorber ou fournir. Si ça passe on valide le tout, si ça passe pas on bride la production ou la demande selon le facteur limitant.
- Interconnexions entre réseaux : Les connexions entre réseaux peuvent se faire via un partage hiérarchique de la production/consommation/stockage du pot ou de manière pair à pair via un stockage tampon en périphérie.
- Avantages : simple programmer en cas de réseau autonome ou hiérarchique en étoile. un peu moins en cas de méta-réseau par stockage tampon . Statistiques facilement disponibles, les liens filaires peuvent être des éléments passifs.
- Inconvénients : Peut poser problème selon le fonctionnement interne du jeu*. Relier directement les capacités de production/consommation/stockage de plusieurs réseaux de même niveau sans passer par un réseau de plus haut niveau peut être Les interconnexions par partage des sont plus lourdes à gérer. Elles peuvent générer des boucles infinies ou faire crash, en fonctionnement ou en cas de modification de la topologie, si ce n'est pas géré correctement. Cela peut être le cas avec des boucles de réseaux de même niveau ou d'éléments connectés à deux réseaux reliés entre eux ou calculés en parallèle.

Note 1 : Dans Minecraft, ce fonctionnement peut être une version généraliste et non optimisé du fonctionnement interne de l'écrasante majorité des machines consommant de l'énergie. C'est pourquoi je le mets en premier.
Note 2 : Selon le type d'interconnexions choisies, si on simule une gestion basée sur un équilibre pressions/tensions/couples <=> débit/intensité/vitessederotation et une éventuelle inertie et/ou perte de charge des liens, on peut agrandir le réseau à l'infini de manière presque réaliste pour le joueur :
- Réseau électrique : réseau hiérarchique (presque) sans stockage. Liens ayant des pertes de charges par effet joule.
- Réseau hydraulique : réseau hiérarchique avec stockage (châteaux d'eau). Liens avec inertie si on veut simuler les coups de béliers.
- Réseau pneumatique : réseau avec stockage pair à pair ou hiérarchique.
Note 3 : C'est souvent le fonctionnement lorsque on a un réseau nécessairement hiérarchisé du type : générateur > réseau > batterie > réseau > point de distribution > consommateur.

Système pair à pair (comme de l'air comprimé) :
Chaque élément ne connaît que ses voisins immédiats et fonctionne de manière autonome. Tous les éléments peuvent stocker de l'énergie. À chaque tic, le système réparti/diffuse/égalise la "pression" d'énergie dans/avec toutes les entités adjacentes.
- Interconnexion : Tous les liens sont traités de la même façon.
- Avantages : Simple à programmer, gère nativement et simplement les modifications du réseau (réseau maillé par nature) et donc facilement extensible par le joueur. Devrait fonctionner dans tous les cas.
- Inconvénient : Débit limité à une fraction du stockage de chaque élément. Solution hyper-lourde pour le CPU du serveur s'il y a beaucoup d'élément, car chaque élément doit être mis à jour à chaque tic et fait un paquet de calculs inutiles/redondant.

III) Divers

Remarques :
- Les fonctionnalités de certains réseaux peuvent être des propriétés émergentes d'autres réseaux ou combinaisons de réseaux. (ça aide pas à s'y retrouver)
- La gestion du monde par le jeu peut limiter ou gêner certaines architectures de réseaux : mise à jour par élément, zone non chargée, mise à jour répartie sur plusieurs threads/cpus/ordinateurs, ...

ps : Il y a certainement d'autres possibilités mais là il faut que je me change les idées .

bon je reviens dans 3 ans
Apres avoir déchiffré tout ton texte ...

Je pense que spontanement j'ai trouvé la façon " pair a pair" que tu cites a la fin ! ?

Bon ben je soupçonnait une complexité caché dans cette histoire ...

Je pense qu'un flag pour chaque objet dans une structure peut fonctionner
Mais effectivement le systeme "reseau" oblige probablement a utiliser la récursivité
Car un objet peut etre ajouté ou retiré de ce reseau...

Et doit etre assez lourd en temp machine si beaucoup d'objets dans le reseau ...

En tout cas ce probleme m'occupe toujours les méninges lorsque je joue a ce genre de jeux ..

Je verrai si je me lance dans un prototype de ce genre de chose .. a l'occasion

Merci pour tes recherches et reflexions. Nalheulf


Ps je me demande si l'algo de la fonction FILL. (remplissage) ne conviendrai pas au final ??
Car changer la couleur de pixel d'une zone donné.. reviens au final a montrer graphiquement une propagation ennergetique ..
Les cubes dans ce cas , etant les pixels . ??

Fill irait bien pour de la 2D mais tes cubes sont en 3D. Je pense qu'il s'agit simplement d'un changement de texture. L'avantage étant de pouvoir animer une texture pour donner un effet "power ON/OFF" ^^

Sans moteur physique, procéduralement parlant, j'aurai aussi comparé ça à une liste chaînée et structurée genre.


Ainsi en déplaçant un cube a N pixel proche du sprite batterie, tu passes BLOC(tonbloc)\ETAT = 1 et ainsi de suite.

oui mais ensuite, tu viens de placer tout tes blocs
il sont donc a "On"

mais si tu en retire un .... il faudra changer l'etat des blocs en aval ... c'est chaud cette histoire non ?

Il faut utilisé je pense, une Structures avec un Arbres, puis aussi de la récursivité
Je pourrais essayer de faire quelque chose pour te faire voir, si j'y arrive bien sur car il faut que jme remette à tous ça

Tu ajoutes un 3eme etat : LAST
Le dernier BLOC déclipsé prend l'etat LAST ON et si tu en enlève 1, LAST ON devient N-1 donc tous les BLOC > LAST ON passent a l'état 0
Et si tu reclipses ton bloc, Recheck de batterie jusqu'à "nombre de bloc".
Dans une liste chainée ça doit pas du tout être sorcier vu que tu peux swapper, virer, ajouter des éléments.
Tu fais au pire une liste avec tous les bloc et une avec seulement les blocs "alimentés"

oui , je vois ...

faudra que j'essai ça a l'occase