resolution liste d'actions : reinjecter de nouvelles actions?

[Argorate]

as tu lu le topic ?

on réinjecte des données dans la base au fur et à mesure de l'exécution, on ne peut donc pas faire de "grosse requête" au départ alors que des données viendront s'ajouter ensuite en base de données.

Tu peux très bien tout faire en mémoire et finir par la maj globale de la bdd, ça dépend des cas en fait

[niahoo]

Non parce que dans ce cas là c'est une seule personne qui va se taper le temps d'affichage de dix minutes.

Ce qui revient à utiliser une tache cron en boucle.

quand on en est là, une seule chose à faire, changer d'architecture et de langage.

[Shidame]

Je pense qu'il faut que tu listes l'ensemble des actions, engendrant de nouvelles actions, que tu envisages et aussi faire une estimation de la durée entre ces actions.

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

Par contre si une action engendre une autre action qui aura lieu dans plusieurs heures alors c'est un peu différent, tu peux "attendre" qu'un autre joueur charge une page, ou même envisager un cron.

[srm]

Pour ta résolution d'action, à l'instant T tu résous toutes les actions.
Si tu dois en réinjecter tu en réinjectes, MAIS tu ne les résous pas maintenant, car c'est un instant T+1 ces nouvelles actions.

Si cependant tu as des actions qui doivent aussi être à T (genre retour d'attaque), alors ça fait partie du traitement de départ.
C'est à dire que attaque et retour d'attaque sont indissociable donc ça n'est pas une nouvelle action à créer.

[Argorate]

Pour ta résolution d'action, à l'instant T tu résous toutes les actions.
Si tu dois en réinjecter tu en réinjectes, MAIS tu ne les résous pas maintenant, car c'est un instant T+1 ces nouvelles actions.

Si cependant tu as des actions qui doivent aussi être à T (genre retour d'attaque), alors ça fait partie du traitement de départ.
C'est à dire que attaque et retour d'attaque sont indissociable donc ça n'est pas une nouvelle action à créer.

Exactement.

[php_addict]

merci pour vos avis

par contre j'ai toujours vraiment du mal a concevoir que l'action "attaque" et l'action "retour d'attaque" soit une seule et meme action :

- à 00h00 je lance une attaque (arrivera à 01h00)
- à 01h00 l'attaque arrive et on résout les combats (pertes etc...) si il y a des survivants
- à 02h00 le retour des attaquants arrive si il y a des survivants (on met à jour la BDD)

je ne comprends pas comment vous faites pour faire de ces 2 actions une seule et même action

[Shidame]

Lorsque tu résous le combat, à ce moment la ta fonction te donne s'il y'a des survivants ou non.
Tu fais alors la mise à jour de la base de donnée, si il y'a aucun survivant c'est trivial, si par contre il y'en a tu calcules le temps de retour. Si le délai est déja terminé, les troupes doivent être chez leur propriétaire sinon tu met l'heure de retour en base de donnée.

[Argorate]

le truc pas logique surtout c'est qu'après qu'on te tape, tu doivent attendre 1h pour taper le gars si t'as survécu... Pourquoi la contre-attaque n'est pas déclenché immédiatement après?

[niahoo]

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.


Moi je trouve que ce sont bien deux actions différentes, je vois pas pourquoi vous voudriez les regrouper.

[Shidame]

Je pense comme niahoo, qu'il s'agit en effet d'un retour de troupe et non d'une contre attaque.

C'est en effet assez logique de voir la deux actions, mais je vois pas pourquoi il n'y aurait autant de récursivité que çà.

D'autre part, je me trompe peut être mais il ne me semble pas judicieux de traiter différents types d'actions simultanément. Il me semble plus logique de traiter toutes les constructions, les attaques etc... (l'ordre est arbitraire ici). Enfin est ce que tu as d'autre "actions en deux temps", car pour l'instant il n'y a que les attaques mais si il s'agit d'un cas particulier, il faut peut etre revoir le design de tes tables.