Calcul de tour qui passe maaaal

[Feldoran]

Mouarf... en même pas une soirée j'ai déjà passé le quart de mes traitements en actions immédiates "atomisées"... comme quoi des fois on a juste de la merde devant les yeux, hein
Je sais pas, c'est bizarre... j'ai longtemps cru qu'il valait mieux limiter au max les requêtes pdt la journée pour profiter des heures creuses et y caler les grosses requêtes, et ça peut peut-être se justifier dans certains cas, mais pour le coup je suis probablement perdant en y allant comme ça. Reste à boucler le codage puis à faire de vrais comparatifs, mais j'ai peu de doute sur l'issue qui a de bonnes chances d'être favorable.

Merci donc pour les conseils, ça devrait aller nettement mieux après tous ces changements, je vous tiendrai au courant.

[wild-D]

Je sais pas, c'est bizarre... j'ai longtemps cru qu'il valait mieux limiter au max les requêtes pdt la journée pour profiter des heures creuses et y caler les grosses requêtes

oui enfin concentrer toutes les requêtes d'une journée sur un gros traitement c'est pas franchement l'idéal non plus (surtout quand on est pas sur du dédié; donc qu'on doit partager les ressources du serveur plutot que les monopoliser)

de plus avec des actions "immédiates" tu t'évites des requêtes non ? (au lieu d'avoir 2 opérations: enregistrement ordre, puis exécution à un autre moment; tu exécute directe l'ordre)

[Feldoran]

Oui mais les requêtes en 2 opérations avaient l'avantage de n'agir que sur un seul champ pendant la journée.

Je voulais surtout éviter qu'aux heures de pointes (genre entre 12 et 14h et vers 20h j'imagine) une multitudes de requêtes à action immédiate ralentissent considérablement les performances du serveur. On verra ce que ça donne.

[Allwise]

De toute façon, ça c'est "des problèmes de riche". Que tu en arrives à avoir des problèmes de performance avec un jeu que tu n'as pas encore lancé est tout le bonheur que je te souhaite
Tu devrais concentrer tes efforts sur le jeu lui-même et sur une logique qui laisse la porte ouverte à des optimisations futures, un code modulaire... Mais il ne faut PAS essayer de sur-optimiser son code pendant la phase de développement. Ton cas en est un très bon exemple :

Ou alors une refonte du gameplay

Tu avais prévu de faire marcher ton jeu d'une certaine façon, et pour des problèmes de (sur)charge que tu n'as pas encore, tu t'apprêtes à modifier le gameplay de ton jeu.
Non, tu devrais développer le jeu tel que tu l'as imaginé, et ne faire l'impasse sur aucune fonctionnalité / aucun concept sous prétexte que ça pourrait poser problèmes le jour où tu auras 10 000 joueurs.
Le jour où ces problèmes surviendront, alors tu t'intéresseras aux optimisations que tu pourras mettre en place, mais pourquoi perdre du temps et des idées pour résoudre ces problèmes qui n'existent pas et qui n'existeront peut-être jamais ?

[wild-D]

^^ oui enfin le gameplay conçu pour 30 joueurs inutilisable avec 1000 c'est p-e pas le top non plus. L'idéal c'est justement d'avoir quelque chose de suffisamment bien conçu pour s'adapter facilement; sans être obliger de tout recommencer à chaque fois que t'as un zéro de plus au nombre de joueurs. (histoire de pouvoir ce concentrer sur l'évolution du jeu, de nouvelle option; plutot que de faire que des refontes de gameplay juste parce qu'à cause du nombre de joueurs ça tient plus la route)

sur une logique qui laisse la porte ouverte à des optimisations futures,

va vraiment falloir me l'expliquer... parce que je vois pas pourquoi je m'enquiquinerais à faire un code "crade" pour avoir à reprendre plus tard son nettoyage pour avoir la version "optimisée".

[Allwise]

J'ai jamais parlé de coder crade. Avant de commencer à développer, a fortiori un jeu, qui demande des développements complexes, on réfléchit... Et on fait en sorte de pouvoir intervenir ça et là sans avoir à tout péter / tout refaire. On fait donc un code modulaire, avec des classes, des fichiers... On entremêle pas toutes les parties du jeu dans des gros plats de spaghettis bordéliques. C'est en gros ce que je voulais dire. Si on commence avec de bonnes bases, on ne devrait pas avoir de problème pour greffer des nouvelles fonctionnalités / modifier les existantes pour les optimiser.


Bien entendu, en amont, il faut concevoir quelque chose de réaliste, et qui s'accorde avec les moyens qu'on a. On va certainement pas refaire WoW dans un jeu web...

Pour le coup, Feldoran parlait d'une situation à 10 000 comptes, pas 1000. C'est bien de se projeter dans un avenir où on prospère, mais faut rester réaliste. Je pense aussi qu'il arrive un stade où on ne peut plus envisager de faire tourner son jeu sur un petit espace mutualisé et que se lancer dans le développement d'un jeu web peut demander autre chose que de la motivation et des compétences en programmation. Si on envisage d'avoir 10 000 joueurs, il faut aussi envisager les ressources qui vont avec. Imaginer lancer son jeu sur un hébergement mutualisé, outre la question d'argent, c'est accepter le fait que le jeu ne demandera guère plus qu'un mutualisé en terme de ressources.
Et si on a du mal avec tout ce qui concerne les ressources, les hébergements, les serveurs, les moyens de contourner certaines limitations... Ben demander de l'aide et des conseils, comme l'a fait Feldoran est la bonne démarche.

Mais je pense toujours que faire l'impasse sur des fonctionnalités / sur son gameplay pour des soucis d'optimisations qui n'existent pas est la mauvaise démarche, sauf cas d'exception : les trucs changés sont pas si importants que ça et offrent beaucoup, ils tenaient pas à coeur, les utilisateurs s'en porteront pas plus mal.

[gameprog2]

Je lui conseille d'optimiser pendant le développement justement, car c'est dans cette phase de notre programme que l'on optimise, et pas après.
Car en continuant le programme tel qu'il l'avait initié, un jour les joueurs seront plus nombreux, et le mécontentement se fera plus sentir qu'avoir une vingtaine de joueurs, et à ce moment-là les changements seront plus lourds et plus longs, surtout que d'ici là des ajouts auront surment été apportés au jeu comme des évennements sur les pnj, ou d'autres idées qu'auront eus les joueurs etc...et ce sera donc plus dur de tout changer, tandis qu'en optimisant dès maintenant dans la phase de développement du jeu, c'est le moment de programmer modulaire et adaptable, pour donner un jeu d'entrée déjà assez optimisé et prévu pour de futures modifs éventuelles.

[Mycroft]

Je crois qu'il faut distinguer "bonne architecture" de "bonne optimisation".

Je me range de l'avis de Allwise, c'est plus important d'avoir un site fonctionnel avec une architecture claire plutôt que de passer un mois sur un algorithme pour gagner quelques secondes.

Par contre, avoir une bonne architecture ça veut aussi dire être capable de se rendre compte où seront les "bottleneck" du programme et en avoir conscience. Quitte à modifier cette architecture si c'est irréaliste. Mais c'est plus un problème de conception que d'optimisation.

[gameprog2]

Je préfère de beaucoup passer plusieurs mois à optimiser pour lancer quelque chose de potable au niveau code, au niveau aspect, et au niveau des fonctionnalités, plutôt qu'être pressé de sortir un truc avec le premier code qui marche, mais ça c'est chacun sa façon de faire

Et puis c'est plus facile de réparer un code qui a été pensé plutot qu'un code qui a été juste fonctionnel ^^

J'ai l'impression que mon avis est le même qu'Alwise^^

[Siko]

C'est comme crée un car alors que tu es célibataire, rien ne t'empeche dans 10 ans quand tu auras 3 femmes et 10 gosse et 30 petit enfants de t'acheter un car.

Actuellement c'est du temps, de l'argent perdu et du plaisir en moins.