Serialize <- Sessions -> Unserialize, Simple question

Bonjour, je pensais passer tout mon jeu en POO. Mais bon, ça me rajoute des requêtes bla et bla et ça ne m'a pas paru si avantageux que ça ( maniaque... ).

Mais je me suis rappelé de la serialisation d'un objet instancié et de la création d'un autre objet avec les mêmes valeurs que l'objet précédent via serialize() et unserialize(). Est-ce une méthode intéréssante pour moi ou il vaut mieux faire plein de requêttes sql ?... :/

Ça dépend vraiment beaucoup de ton projet et de la façon dont il va évoluer. Si tout est figé et que tu ne cherches que l'amélioration des perfs alors va pour le serialize. Mais si tu vises à plus long terme, perdre l'aspect relationnel de ta BDD avec des serialize à gogo c'est dommage, même si c'est moins gourmand en requêtes.

M'enfin je dis ça et j'avais commencé en abusant du serialize dans mon projet, maintenant je regrette et j'en bave un peu pour tout remanier, mais je trouve qu'au final c'est plus élégant.

Quel est exactement le besoin ?
Tu as besoin de faire une copie de l'instance ou de partager la même instance ?

Oui je cherche à copier une instance initialisée au login du joueur contenant les informations importantes du joueur et les utiliser ainsi sur toutes mes pages visitées en évitant un maximum les requêtes ^^'. Comme le dis HauteLune effectivement on peut en "ch***" pour mettre en place ou défaire ce genre de systémes ^^', d'ailleurs je n'ai toujours pas fini, mais bon, à priori j'ai décidé de mettre à jour les données membres de ma classe et les re-serialiser à la fin de chaque page modifiant ces données membres, ainsi je n'ai pas trop de soucis .

Dans un cas pareil j'utilise un système de cache genre XCache ou Eaccelerator, dans lequel je stocke mes variables sérialisées, ne les enregistrant en BD que si il y a modif.

Pourquoi ne pas utiliser les variables de sessions PHP pour conserver des données de page en page, en ne les enregistrant en BDD que s'il y a modif effectivement ?

Arf j'ai du mal m'expliquer ! Pardonnez moi !
Enfaite j'utilise éxactement vos idées c'est ce qui était prévu et je fais mes test comme ça dans les pages:

et à la fin de mes pages et avant toute redirection:

Voilà enfaite ça me semblait une trés bonne idée, et ça continue de me plaire cette idée
( et quand j'y pense que je l'ai eue dans un rêve v__v' ).

Il faut juste faire gaffe à ne pas introduire de bug/faille avec ce système.

Par exemple si le nombre de pièces d'or est stocké dans la session et qu'un joueur ouvre deux sessions, il peut acheter un objet dans une session, puis un deuxième objet dans l'autre session. Dans ce cas, la 2e session n'a pas "vu" que le nombre de pièces a baissé, lorsque la BDD est mise à jour, la valeur enregistrée sera nombre initial - prix 2e achat.

Effectivement c'est embêtant :/, j'avais aussi pensé à ce cas précis:
Joueur1 tue joueur2
joueur2 était en train de tapper un pnj mais il n'est pas mort.
La bdd considére que le joueur2 est mort tandis que la session joueur2 pense qu'il est toujours vivant. Je n'ai pas encore trouvé de solution magique, pour les pièces d'or je pensais faire que la bdd gère tout à partir de ses connaissances, exemple:
Joueur1 achète un objet qui coûte 180 Pièces d'Or, la bdd va simplement retirer 180 de la base de données et 180 des données de session du joueur ^^'. Je me dis que du coûp ça parait un peu inutile de porter mon jeu en P.O.O v__v'... Enfin je trouverais bien quelque chose . Stockage sur fichier texte peut-être ? ça évite des requêttes sql mais est-ce plus pratique ? ...
Enfin tout pour dire, ça peut être sympa mais effectivement comme il a été dit plus haut... DurDur

Les sessions permettent de se dispenser d'appels permanents à la BDD mais la contrepartie est que lorsqu'on effectue des opérations qui interagissent avec l'environnement de jeu (achat d'objet, combat...) on DOIT faire les tests sur des données "fraîches" et pas se contenter de celles contenues dans la session, sinon effectivement on va avoir des surprises:)

Dans nos deux exemples lors de l'achat, même si la session indique une fortune suffisante, il doit au dernier moment avoir un test sur la quantité d'or réelle avant la transaction.
Idem pour le combat, lors d'un coup on doit faire les calculs de toucher, mais en même temps ajouter une clause du type "and assaillant is alive".

Y'a pas moyen d'y déroger.

D'où l'interet d'utiliser des variable stockée dans un cache coté serveur, ça permet de partager une instance entre les sessions.

Je ne connais pas de méthodes pour enregistrer des variables en cache côté serveur comme tu me dis là =o.
Je pensais sinon à un systéme de temps géré avec le constructeur etc, un systéme qui vérifie une date avec time() et si le temps prévu est dépassé on recharge les données avec la bdd, une sorte de systémes de PA en somme avec les données du joueur , en même temps je sors à peine de mes partiels le temps que ma cervelle fume moins...

Tu installe xcahce ou eaccelerator et tu regardes les API:
http://xcache.lighttpd.net/wiki/XcacheApi
http://bart.eaccelerator.net/doc/phpdoc/

C'est facile à utiliser, et franchement ça simplifie la vie. En pratique c'est géré par des segments de mémoire partagés, accessible donc par les divers threads apaches. Je l'utilise comme cache pour mes objets persos, groupe etc... ça m'évite de tout recalculer chaque fois qu'un utilisateur affiche la page.

Ah bah ça peut être sympa, pour le moment je vais choisir la facilité je manque cruellement de temps et par la suite je vais regarder ça . PS: 8 requêtes par page çe ne fait pas un peu trop ? :/

[edit] Bon ce genre de solutions sont incompatibles avec mon cas, je ne suis pas propriétaire du serveur :}, je ne peux pas modifier php.ini ni ajouter de modules. Donc je vais trouver une astuce pour gèrer mon probléme.

Là en effet ça part pas bien si tu te pose ces questions

Si en effet tu as une redondance de données entre ta session et ta bdd, tu va pas t'en sortir je pense (sauf si par exemple tu stocke en session que des données issues de la base, et jamais l'inverse, i.e. ta session te sert de cache d'affichage, avec eventuellement des objets dedans).

Par contre BDD rel + POO ça se fait bien (i.e. stockage des objets dans la base). Y'a des frameworks pour faire ça (tu voudra sans doute faire le tien propre en regardant comment sont fait ruby/rails, hibernate, ... qui font référence dans d'autres langages).

Merci j'y jetterais un coup d'oeuil en temps voulu .

Et outre le fait que ça puisse rajouter quelques requête, n'oublie pas que l'orienté objet peut te permettre d'utiliser moins de code.

Mais c'est -particulièrement en PHP- qu'un projet fait à 100% en objet sera inefficace, puisqu'il rechargera des informations souvent inutiles et inchangés entre chaque page. Il faut savoir utilise intelligemment le concept.


Rien ne t'empêche d'avoir un projet hybride, un peu comme les projets dont certaines parties aux performances critiques sont fait en ASM plutot qu'en C comme le reste.

Je suis du même avis que Sybler.

Certaines parties d'un jeu mérites d'être en objet pour l'avantage que l'on tire de la structure de ce paradigme. Mais le PHP étant de base un langage de script impératif sait aussi très bien fonctionner avec ces dits scripts et il ne faut pas s'en passer.

Par exemple les armes, personnages, lieux et autres choses plutôt facilement modélisables et nombreuses sont surement à faire en objet pour rendre tout d'une certaines souplesse. L'objet permet de belles choses et il ne faut pas s'en priver quand ca peut être utile. (contraintes de Typage, héritage, interface, abastraction ...)

Oui en commençant à rèfléchir au projet et à coder je m'en suis vite rendu compte, ça devenait plutôt lourd, incohérent. J'ai récemment décidé de détruire certaines classes et en garder que quelques unes. J'ai aussi commencé à jeter un oeuil à AJAX pour voir si ça pouvait être sympatique, l'idée me semble plutôt bonne, plutot que de charger 36 pages pour effectuer quelques actions plutôt faire 4 requêtes HTTP ( en mode GET ) bien pensées et afficher le résultat sur la page déjà chargée... Les requêtes font entre 300ms et 350ms, celà vous semble beaucoup ? Est-ce réellement intéressant ? Je sais qu'en abuser serait une très très grosse bétise... Mais utilisé juste pour les actions des joueurs ?

Entre quoi et quoi ? Ca inclu l'envoi ou seulement le temps de travail du serveur ?

AJAX peut effectivement surcharger un serveur de requete.

Au fait, depuis PHP5, la POO est devenue super intéressante. Et pour la gestion de la session vous avez une simplicité de codage assez intéressante :
__destruct est une méthode qui est lancée automatiquement à la fin d'un script si vous avez déclaré une variable global qui contient la principale information (comme le compte user).
Mettez dans cette méthode __destruct de quoi enregistrer l'instance en session, et vous n'avez plus qu'à gérer l'unserialize dans la vérification de votre session.
Autre conseil : ne pas utiliser les cookies pour garder votre serialized, un joueur techniquement au point vous cassera votre petit site comme il faut.

Si vous enregistrer le serialized dans la BdD, pour moi, ça n'a d'utilité que si vous gérez également les sessions dans la BdD... chose qui peut se faire si vous faites un log des connexions (recherche de multicomptes)... Et dans ce cas, ça ne fait que déporter la gestion des sessions :-D

Et pour abonder dans le sens des Pro-POO : je n'étais vraiment pas persuadé de son intérêt il y a quelques années... j'y ai mis les pieds dedans par pure curiosité, et aujourd'hui je me vois mal continuer sans.
Un déboggage est rapidement fait, une évolution du site est faite aussi très rapidement, et pour ce qui est de l'argument "Trop de requêtes", je l'ai eu en tête dès le départ, et je ne trouve pas que cela soit un problème si les objets les plus importants sont correctement fait (càd prenant en compte le fait que les requêtes c'est long).
Pour mon jeu, j'ai utilisé différentes techniques objets qui, à mon avis, optimisent au mieux les requêtes sur le serveurs, la mémoire utilisée, leur maintenabilité, leur évolutivité, etc.
Les pages demandant un nombre important de requêtes sont rares, et uniquement utilisées par les administrateurs.
Les pages des joueurs utilisent très peu de requêtes.

La POO en PHP c'est comme tout : un problème de conception au départ, et c'est la mort du programme.

Pour ce qui est d'AJAX (ou ActionScript), faire attention aux fameux "hits" qui sont une façon de mesurer la charge d'un serveur. L'AJAX explose les hits, et beaucoup de hits, ça fait ramer un serveur : vaut mieux une grosse page, que 1000 petites pages.