resolution liste d'actions : reinjecter de nouvelles actions?

[php_addict]

Elle l'est, mais comme pour l'attaque il lui faut une heure pour aller au camp adverse je suppose.

De plus, à lire le dernier message de php_addict, je pense que son « retour d'attaque » n'est pas une contre attaque, mais plutot l'arrivée du butin à la maison.

oui c'est bien cela, désolé si ce n'était pas très clair, je fais du mieux que je peut...

[Argorate]

effectivement dans ce cas là c'est très différent, c'est pas du tout une "contre attaque"^^

Sinon, pour ce qui est de traiter les actions du même type dans l'ordre, je suis d'accord seulement si cela n'a pas d'importance.
Mais comme depuis le début on me répète qu'ici ça en a, peut être que de faire toute les construction avant les attaques permettrais la destruction d'un bâtiment qui en réalité aurait de se faire qu'après l'attaque...
Donc faut voir^^

[Ter Rowan]

à mon sens la récursion est "simple", via un tableau à trier.

les événements ne sont finalement pas liés, ils arrivent dans l'ordre (temps)

prenons un exemple. En base :

A est en 10,13
B est en 15,10

#1,A se déplace vers 15,10 départ 10h00, arrivée 11h30
#2,A attaque B départ 11h30, arrivée 11h30
#3,B se déplace vers 12,13 départ 12h00, arrivée 14h00

#x l'id de l'événement

maintenant le script se lance à 15h00, on doit donc résoudre toutes les actions :

phase 1 récupération de la bdd (avec un order by à trouver entre début et fin que j'ai du mal à bien préciser)

t[0] =#1,A se déplace vers 15,10 départ 10h00, arrivée 11h30
t[1] =#2,A attaque B départ 11h30, arrivée 11h30
t[2] =#3,B se déplace vers 12,13 départ 12h00, arrivée 14h00
....

phase 2 on résout les actions dont l'arrivée est avant 15h00 (fonction récursive avec comme paramètre le tableau t)

boucle de t[0] à t[count(t)] :

on résout t[0], ok tout va bien :

+ mise à jour de la position de A en BDD
+ suppression de la ligne #1 en BDD (éventuellement via un tableau pour pouvoir faire à la fin un delete where id in (#1, #x, ...)-+


on résout t[1], là ça se corse un peu, algorithme de résolution, supposons que l'issue soit A écrase B qui fuit au hasard (on dira en 15,16) :

+ mise à jour de A en BDD (trésor, perte, ? ...)
+ suppression de la ligne #2 en BDD
+ parcours de t (de 2 à count() ), suppression de tous les événements concernant B (dans l'exemple unset(t[2])
+ suppression de la ligne #3 en BDD (car abandonné suite à l'événement)
+ création de t[n+1]=#NULL, B se déplace vers 15,16 départ 11h30, arrivée 15h30
+ tri du tableau sur le même algo que le order by de la phase 1

le fait qu'on ait supprimé et ajouté des lignes imposent de stopper la boucle

du coup on rappelle la fonction récursive avec comme paramètre le nouveau table t (déjà trié),
et on recommence, jusqu'à ne plus avoir d'événement finissant AVANT sysdate

phase 3 maj BDD
+ on insert toutes les lignes de t encore présente qui n'ont pas d'id (#NULL pour la fuite de B en 15,16 dans l'exemple)
+ éventuellement si on a bufferisé le delete, c'est le moment de l'appliquer pour toutes les actions résolues (évidement avec id, celles sans id n'ont pas besoin d'être persistées : elles ont été créés et immédiatement résolues par le script)



voilà, je ne sais pas si je suis clair, y a peut être une faille

[php_addict]

Merci Ter Rowan c'est ce que je m'apprête à faire quand j'aurais mieux digéré tout ca.

le seul hic qu'il peut y avoir c'est le nombre de récursion en php... peut être je vais faire comme suit:

- je prends 50 actions à résoudre (avec recursion etc...)
- test si il y a encore des actions a resoudre, et si oui je relance la fonction

[Ter Rowan]

- je prends 50 actions à résoudre (avec recursion etc...)
- test si il y a encore des actions a resoudre, et si oui je relance la fonction

bah le problème c'est si une action parmi les 50 a des conséquences sur d'autres que les 50, tu risques d'avoir des soucis

maintenant peut être que ça marcherait si :

au lieu de supprimer le tableau entier, tu restes sur un tableau de 50, tu supprimes les événements dans le tableau ET un delete where ce qui va bien en BDD (dans mon exemple "where acteur = B")


ce qu'il faudrait voir, c'est quelle volumétrie d'événements pour un joueur, et combien de joueurs (parce qu'après tout, le problème est volume plus qu'algo)

[Shidame]

Mais comme depuis le début on me répète qu'ici ça en a, peut être que de faire toute les construction avant les attaques permettrais la destruction d'un bâtiment qui en réalité aurait de se faire qu'après l'attaque...
Donc faut voir^^

En effet, j'étais passé à coté de ce point, après dans mon idée un bâtiment à des points de structures, et c'est pas parce qu'il n'est pas fini qu'il ne peut pas subir de dégâts.

J'aime beaucoup, ton explication Ter Rowan, et pour répondre à tes craintes c'est vraiment très clair

Edit : j'ai posté trop lentement ;p

Je rejoints Ter rowan sur la volumétrie d'évènements et sur leur délai comme je le disais plus haut :

Si tu as une chaine d'action/réaction avec un intervalle de 5min, ca me semble difficile à mettre en place.

[niahoo]

tu n'as pas vraiment besoin de récursion au final. il va te falloir rajouter une boucle, du style
while(count(monTableauD'actions) > 0) {

[php_addict]

tu n'as pas vraiment besoin de récursion au final. il va te falloir rajouter une boucle, du style
while(count(monTableauD'actions) > 0) {

oh bein oui j'suis con...une simple boucle va me suffir...

effectivement la volumétrie des données risque d'être le problème...mais le probleme c'est que je sais pas si mon jeu va plaire et combien il y aura de joueur, c'est une donnée inconnue...c'est un mmorpg donc il y aura pas mal de monde (1000 serait un minimum je pense)

[Shidame]

Je suis peut être naïf, mais à mes yeux le nombre de joueur a peu d'importance pour ce problème non ? je vois bien le rapport plus de joueurs = plus d'actions à résoudre mais aussi une plus grande fréquentation les deux devraient s'équilibrer ?

Il est vrai que la connectivité devrait augmenter aussi ... bref je suis naïf je crois

[Ter Rowan]

tu n'as pas vraiment besoin de récursion au final. il va te falloir rajouter une boucle, du style
while(count(monTableauD'actions) > 0) {

je ne suis pas d'accord

au début c'est ce que je pensais mais le problème vient des réactions


exemple :

A attaque B
C attaque B


sauf que quand A attaque B plusieurs cas peuvent se produire :
- B est détruit (donc supprimer C attaque B)
- B survit et se protège pour parer à une nouvelle attaque (donc nouvel événement)
- B fuit (donc nouvel événement)

dans les deux derniers cas, la résolution impactera "C attaque B" (peut être que B est trop protégé, peut être que B n'est plus là, ...), c'est la où la récursion est utile et que la boucle ne permet pas (du moins je crois) de traiter : impossible d'intercaler un événement dans ton tableau (le curseur du tableau se paumerait), impossible de supprimer un événement du tableau (le curseur du tableau se paumerait aussi)

quand je dis impossible, je veux dire fonctionnellement, d'un point de vue technique, il tombera sur un autre événement, mais lequel ? pas forcément celui qui devrait naturellement être le bon