Discussion :

[hoolay]

Salut à tous !

J'ai un souci dans la logique de mon code,

j'ai pas mal de données qui possèdent un timer à mettre à jour (ils ont tous un time_left en seconde dans leur table)

• ressources : mettre à jour les ressources de chaque utilisateurs
• cartes actives : des cartes qui applique des bonus à tout et n'importe qui mais qui ont une durée de vie
• constructions : des batiments et unitées en cours de construction
• fleets : les attaques en cours

J'imagine qu'il faut mettre à jour tout ça a chaque actualisation du site (donc appeler la fonction "update" depuis index.php)
car par exemple : si une flotte attaquante est arrivée à destination,

• il faut savoir si les flottes du défenseur ont étés construites, pour défendre
• combien il a de ressources à ce moment là, pour le pillage
• si ses bonus de défense sont encore actifs...

autre exemple : un joueur veut lancer une attaque, le choix de ses cibles dépend du score de chacun (et vous vous doutez bien que le calcul du score dépends d'un peu tout ça)

Première option :

1. j'enregistre la date de la dernière action sur le site,
2. à la prochaine action je calcule la différence entre les deux dates
3. je déduis le temps en secondes à chaque entrée (constructions, attaques en cours, durée des bonus...)
4. je met à jour les ressources et les scores
5. je met à jour la date de la dernier action sur le site

C'est jouable ! Mais si j'ai 1000 joueurs, qui font 3 actions par minutes,
ça fait 3000 calcul de score, 3000 calcul de ressources
3000 * mises à jour des files d'attentes et attaques en cours...

ça fait juste au minimum 10000 mises à jours de la base de données par minutes... c'est ... heu comment dire...


Deuxième options :
J'actualises les infos propres au joueur uniquement quand il est concerné (en cas d'attaque ou quand il se balade sur le site)
En plus ça m'évite de créer une table qui stocke juste l'heure...
Mais bon imaginons : il a un bonus de production qui s'arrète à 11h... et il se connecte à 13h
Comment je calcule ses ressources entre 9h et 13h ?


Enfin voila, comment on gère ça habituellement ?

[sabotage]

Tu n'as effectivement pas besoin de mettre à jour les infos des joueurs qui ne sont pas concernés.

[hoolay]

Oui je pense aussi, j'étais en train de me rendre fou là ^^

Merci pour ta réponse !

Du coup j'ai fais comme ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// Mise à jour des données
if (User::isLogged()) {
    $user = new User($_SESSION['user']['id']);
    $queue = new Queue($user->id);
    $fleets_mobile = new Fleets_mobile($user->id);
 
    // mise à jour des ressources
    $user->update_ressources();
 
    // mise à jour des construction
    $queue->update_queue(get_time_diff($user->last_refresh)); 
 
    // résolution des combats
    Combat::solve_combats();
 
    // mise à jour de l'heure
    $user->update_value('last_refresh',date("Y-m-d H:i:s"));
}

[hoolay]

Coucou !

Toujours dans ma lancée de logique POO...
(d'avance pardon je sais que je m'éloigne un peu de la question, mais pas du sujet principal : un jeu par navigateur)

Alors voila :

A la base, je pensais faire quelque chose de propre en séparant toutes mes entités de manière sémantique,
Dans le cas d'un combat j'ai donc des classes qui sont fréquement appelées : fleet / fleets_manager / fleet_mobile / combats/

Mais au final je me prends le cerveau avec trop de fichiers. POURQUOI ?

Parce que selon ce que j'ai compris de la POO : Fleet ne doit concerner qu'une flotte. Elle n'est pas censée être au courant de ce qui se passe à côté.
Or ça me changerais la vie si je pouvais y intégrer une méthode statique get_all_fleets(), et d'autres tels que get_damages(), send_fleet_to_user(), reset_fleets(), loot_ressources() ...

Mais vous l'avez compris pour moi c'est des classes au dessus comme combat et fleets_manager qui gèrent tout ça. Pour tant je vois que d'autres CMS font ce genre de truc...
Qu'est ce que je n'ai pas compris dans la logique de la POO ?

[Tsilefy]

Mais au final je me prends le cerveau avec trop de fichiers.

C'est une conséquence naturelle de la POO, il n'y a pas de quoi paniquer. Il suffit d'utiliser un bon IDE :-)

Parce que selon ce que j'ai compris de la POO : Fleet ne doit concerner qu'une flotte. Elle n'est pas censée être au courant de ce qui se passe à côté.

C'est exact.

Or ça me changerais la vie si je pouvais y intégrer une méthode statique get_all_fleets(), et d'autres tels que get_damages(), send_fleet_to_user(), reset_fleets(), loot_ressources() ...

Ça te changerais la vie maintenant, mais ça te compliquera la tâche dans le futur si ton application devient un peu plus compliquée. Qu'est-ce qui va se passer si tu commences à utiliser d'autres variantes de fleet? Ex: DefensiveFleet et OffensiveFleet, chacun avec leurs particularités. Comment vas-tu gérer ça dans ta classe Fleet (qui n'existera peut-être même plus)? Tandis que si tu utilises une autre classe pour gérer l'ensemble des fleets, et pour peu que tu crées une interface Fleet que DefensiveFleet et OffensiveFleet implémentent, ça sera plus facile.

En passant, je ne conseille pas l'utilisation de méthode statiques. À part quelques cas précis, l'utilisation de méthode statiques est souvent indicative d'une conception inappropriée. Parfois on passe outre pour raison de temps ou de facilité, mais il faut savoir que cela peut entraîner des problèmes (et elles sont non testables, par ailleurs, ce qui pose un autre problème).

Mais vous l'avez compris pour moi c'est des classes au dessus comme combat et fleets_manager qui gèrent tout ça. Pour tant je vois que d'autres CMS font ce genre de truc...

Ces CMS n'ont pas compris la SRP (principe de responsabilité unique). Analyse bien ton domaine ("métier"): est-ce qu'il est logique qu'une flotte resette le nombre de flotte d'un utilisateur? Si les objets de ton domaine sont biens définis, tu verras tout de suite ce qui appartient à une classe et ce qui n'y appartient pas.

[hoolay]

Woaw !

merci beaucoup : c'est un vrai soulagement de savoir que je n'étais pas trop dans le faux. Et tes éclairissement clarifient beaucoup les chose... Sur le net on trouve facilement comment faire. Mais pas trop le pourquoi du comment...

J'ai beaucoup avancé cette nuit du coup, mais j'ai l'impression de faire à nouveau fausse route :
J'aimerais bien fonctionner de la manière dont tu le propose
DefensiveFleet et OffensiveFleet qui héritent de Fleet (une classe en active record, sinon c'est trop facile )

Or actuellement deux table
- fleet_owned : id | unit_id | user_id | quantity (donc avec une ligne par type d'unités et par joueurs)
- fleet_mobile : id | target_id | user_id | json_fleets | arrival_time (donc une ligne par attaque qui contient la liste de toutes les unités au format json {unit_id:quantity, ...}

et c'est bien là mon problème pour la classe Fleet_mobile() je n'ai qu'une ligne pour toute une flotte avec une méthode pack_json() et un unpack_json()
alors que la classe Fleet_owned() instancie plusieurs classes Fleet()

J'ai choisi de fonctionner comme ça pour deux raison :
si un combat doit avoir lieu il suffit de voir dans ma table fleet_mobile si arrival_time est dépassé
et parce que la classe Fleet() est en active record et donc directement synchronisée avec la table fleet_owned


Oki ...

Au fur et à mesure que j'écris, je me rends compte que je pourrais stocker les fleet_mobile et fleet_owned dans une même table Fleet_owned (ajouter une colone "combat_id" pour garder une contrainte d'unicité unit_id|user_id|combat_id) et donc avoir une nouvelle table combats : id | target_id | user_id | arrival_time

De cette manière les classe Fleet_mobile et Fleet_owned fonctionneraient vraiment pareil et hériteraient d'une même classe (ou implémenteraient le même interface ?)

en terme de fichiers ça nous ferait :

• Fleets abstraite
• Fleet_mobile extends Fleets
• Fleet_owned extends Fleets
• Fleet extends ObjectModel
• Combat extends ObjectModel

en bdd ça donnerais :

• fleets : id | unit_id | user_id | quantity | combat_id (NULL si pas en déplacement)
• combats : id | target_id | user_id | arrival_time

Peut-tu me confirmer si c'est comme celà qu'il faut faire ? ou si mon fonctionnement précédent est mieux avant que je refasse tout ?

[Tsilefy]

On entre ici dans une discussion très spécifique à ton jeu, et je n'en ai pas une connaissance approfondie, donc tout ce que je dis sur ton jeu spécifiquement est à prendre avec des pincettes. Tu es le seul à pouvoir décider de la meilleure approche.

Maintenant, la trop grande importance qu'on accorde aux patterns de persistance (Data Mapper, et surtout Active Record) fait qu'on commet l'erreur (à mon goût) de concevoir une application en partant par le schéma de la bdd, et à forcer l'architecture de la partie modèle (ou entité) de l'application à être dictée par le schéma. Active Record est le plus coupable de cela, d'ailleurs. Et pourtant, malgré l'importance de la bdd, ce n'est qu'un "détail de l'implémentation". Tu peux utiliser plusieurs formes de persistance, et c'est donc ton application qui doit dicter du schéma, et pas l'inverse.

Je ne te dis pas ça pour que tu te débarrasses d'Active Record, c'est pour que tu comprennes en quoi un choix technique de départ influence la manière dont tu fais ton application, alors que dans l'idéal ça devrait être l'inverse.

Tout ça pour dire qu'il faut partir des éléments de ton jeu (on entre dans la partie à prendre avec des pincettes!)
- Fleets est le "manager" des entités Fleet, c'est ça?

- Une flotte est une flotte. Est-ce que le fait d'appartenir à un user, ou de participer à un combat change vraiment sa nature? Pour reprendre mon exemple, une flotte défensive et une flotte offensive sont de natures différentes, avec des objectifs différents, des particularités différentes (une flotte défensive est forte en défense mais nulle en attaque, et vice-versa), avec éventuellement des vaisseaux différents. Mais entre fleet_mobile et fleet_owned, c'est la même chose, n'est-ce pas? Une fleet owned peut en même temps être une flotte mobile. Donc, ta nouvelle idée me semble logique.

- Maintenant, si on va plus loin, owned et mobile me semblent plus une différence de statut, et pas de nature. Je me pose donc la question de la nécessité de séparer la classe manager Fleets en 2 classes? Mais peut-être y-a-t il des différences plus importantes entre les deux?

[hoolay]

Re !

Je vais répondre en deux temps :

premièrement j'ai repris l'organisation comme nous l'avions convenu un peu ensemble :

Fleets abstraite
Fleet_mobile extends Fleets
Fleet_owned extends Fleets
Fleet extends ObjectModel
Combat extends ObjectModel

Déjà la transition a été beaucoup plus simple que prévu et maintenant tout semble plus logique tu avais complètement raison ! J'aimerais être capable de trouver plus rapidement une bonne solution dans mes développement, j'ai beau travailler sur papier, je retombe souvent sur des erreurs de parcours ou des contraintes techniques qui m'obligent à procéder et implémenter différement (tu vois ou je veux en venir... ?). Quoi qu'il en soit et tu l'avais dis ça aussi : beaucoup de méthodes statiques ont disparues. Dans mes prochains dév quand je me retrouverais face à une statique, je réfléchirais à deux fois à mon organisation... Celà dit maintenant je me retrouve confronté au problème des limites de mon active record.

Et là je peux répondre à ton dernier message !

D'abord merci beaucoup pour ton temps et la clarté de tes propos; Tu parles des contraintes dues au choix technique. En effet je me retrouve trop souvent dans cette situation à devoir développer autour des outils plutôt que des vrais objectifs et besoins de mon appli. Mais ça je crois que c'est surtout un problème d'expérience et de maîtrise desdits outils. Alors je continuerais à apprendre par l'erreur, mais j'y prêterais plus attention. Celà dit je suis déjà en train de prévoir de nouvelles possibilités pour le jeu en question basé autour de draggable et droppable de jquery ui... encore une fois je risque de retomber dans le piège... On verra.

Pour la partie pincette, je n'avais pas vraiment saisi des F_Défense et F_attaques (maintenant c'est bon)
De mon côté, tu as tout à fait saisi mon schéma : Fleets c'est le manager et en effet F_Moving et F_Owned sont les même, ce qui les différencie c'est que F_Moving à $combat_id en plus en argument de constructeur et sa requête de SELECT est un peu différente. Donc il y'a surement quelque chose à faire à ce niveau
n'utiliser que Fleets($user_id, $combat_id = null)... je vais laisser mûrir cela encore une nuit

[Tsilefy]

Attention, ne confonds pas contraintes et choix techniques.

Savoir s'adapter en fonction des contraintes techniques doit aussi faire partie de notre bagage en tant que développeurs. Un jour tu bosses avec un client qui a plusieurs serveurs et un contrôle technologique total, et un autre jour tu bosses avec un client qui a un hébergement mutualisé limité auquel tu ne peux accéder que par FTP...

Mais lorsque tu as le choix et que c'est toi qui décides, mieux vaut en effet ne pas se tirer une balle dans le pied.

Après, tu ne trouveras pas toujours le bon choix du premier coup (ou même du deuxième!). La période de conceptione est utile, mais il ne faut pas perdre trop de temps à chercher l'architecture parfaite. Commence à coder rapidement, fais un truc qui marche (truc != application complète, ça peut être une méthode, une classe, etc...). Si tu es plus confortable avec Active Record, des méthodes statiques (voire des singletons et des variables globales), utilise-les au début pour obtenir un truc qui marche. Et ensuite, il faut faire du refactoring, encore et encore et encore. C'est par le refactoring et l'expérience que tu trouves la bonne architecture et que tu acquières les bons réflexes (lire le code des autres est pas mal aussi pour apprendre).

[hoolay]

oui pardon, un problème de vocabulaire, j'avais saisi l'idée.
En tout cas, c'est vraiment passionnant tout ça, tu m'as fait mettre une bonne dizaines de pages en favoris ce soir

Pour trouver mes techniques j'essai d'éplucher des CMS mais tu le sais vu certains ne sont pas forcément des références.

je reviens rapidement sur la différence entre fleet_owned et fleet_mobile
fleet owned doit également croiser des infos avec les tables "modifiers" (qui agissent sur le prix, le temps de construction...) et aussi units_infos (qui contient justement les prix de base, les nom...)
et ça mon active record ne fais pas les jointures je suis obligé de refaire des boucles dans le manager de fleets j'aime beaucoup ça ^^