IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Développement Windows Discussion :

Jeu massivement multijoueurs : Sockets & SQL


Sujet :

Développement Windows

  1. #1
    Membre averti Avatar de Jerede
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mai 2010
    Messages
    271
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Mai 2010
    Messages : 271
    Points : 422
    Points
    422
    Par défaut Jeu massivement multijoueurs : Sockets & SQL
    Bonsoir,

    Je réalise actuellement un jeu massivement multijoueurs, oû le serveur est séparé en deux parties distinctes, afin d'avoir par la suite plusieurs serveurs.
    La partie "Connexion" et la partie "Game" propre à chaque serveur de jeu.
    Le jeu pourra donc tourner avec un serveur de connexion ouvert et de multiple "serveur game".
    Là ou ça se corse, c'est la coordination entre les deux.

    J'ai cru bon d'éviter le maximum de requêtes non indispensable dans la base de données. Le serveur de connexion chargent donc tous les comptes à son lancement ( nom compte, pass ).
    Lors d'une inscription sur le site, le php utilise un socket de connexion pour informer le serveur de l'inscription ( donc pas besoin de SELECT en permanence ).

    Au choix du serveur, le client est redirigé vers le socket ( adresse et port) du serveur qu'il à sélectionné.
    Une fois connecté au "Game Serveur", celui ci va charger les infos sur ses personnages depuis la Base de données.

    Le fonctionnement est t'il optimal selon vous ?

    Devrais-je précharger les informations concernant les personnages au lancement du "game serveur" pour éviter des requêtes incessantes ?
    (Sorry si c'est pas assez explicite, je m'embrouille facilement )

    Edit : Petite question : Un envoi de socket, et y vraiment plus rapide qu'une légère requête sql ?
    Y'a t'il des points sur lesquels je devrai me concentrer afin d'optimiser au maximum les perfomances du serveur ?

  2. #2
    Expert éminent
    Avatar de Immobilis
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mars 2004
    Messages
    6 559
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Mars 2004
    Messages : 6 559
    Points : 9 506
    Points
    9 506
    Par défaut
    Salut,

    L'idée de charger des données en mémoire est bonne. L'accès à la mémoire du serveur web sera toujours ce qu'il y a de plus rapide.

    Ici tu es sur un forum ASP.Net VB ou C#. Es-tu certain de ne pas t'être trompé?
    Petite question : Un envoi de socket, et y vraiment plus rapide qu'une légère requête sql ?
    Il faut tester.
    Y'a t'il des points sur lesquels je devrai me concentrer afin d'optimiser au maximum les perfomances du serveur ?
    Quel serveur? SQL ou web? Pour le web mets en cache tout ce que tu peux. En .Net c'est assez facile à programmer mais en PHP...

    A+
    "Winter is coming" (ma nouvelle page d'accueil)

  3. #3
    Membre averti Avatar de Jerede
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mai 2010
    Messages
    271
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Mai 2010
    Messages : 271
    Points : 422
    Points
    422
    Par défaut
    Concernant le chargement des données au démarrage, je parlais du choix à faire entre :
    * charger tous les comptes des joueurs au lancement du serveur
    * charger le compte associé à chaqu'un quand il se connecte
    Des requêtes sans arrêt ne vont pas baisser les performances pour rien ?

    Petite question : Un envoi de socket, et y vraiment plus rapide qu'une légère requête sql ?
    Y'a t'il des points sur lesquels je devrai me concentrer afin d'optimiser au maximum les perfomances du serveur
    Je voulais en faite parler du Serveur de jeu, et non du serveur web, désolé pour la confusion

    Edit : je n'ai pas eu souvent à faire avec le dataSet, peuvent ils mettre utiles dans ce cas ?

  4. #4
    Expert éminent
    Avatar de Immobilis
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mars 2004
    Messages
    6 559
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Mars 2004
    Messages : 6 559
    Points : 9 506
    Points
    9 506
    Par défaut
    Citation Envoyé par Jerede Voir le message
    Je voulais en faite parler du Serveur de jeu, et non du serveur web, désolé pour la confusion
    Ben là tu es dans le forum ASP.Net. On y parle essentiellement de web. Tu veux pas que je déplace ton topic dans le forum windows?
    "Winter is coming" (ma nouvelle page d'accueil)

  5. #5
    Membre averti Avatar de Jerede
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mai 2010
    Messages
    271
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Mai 2010
    Messages : 271
    Points : 422
    Points
    422
    Par défaut
    Ben, à la base il était dans la partie VB .NET, mais j'ai mal dû m'exprimé, donc il àa était déplacé içi

  6. #6
    Membre chevronné
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2009
    Messages
    1 048
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Finance

    Informations forums :
    Inscription : Avril 2009
    Messages : 1 048
    Points : 2 201
    Points
    2 201
    Par défaut
    On est dans le développement d'application client Windows ici.

    Je ne vois donc pas ce que fait une discussion ou j'entends les termes serveurs (encore que), ou php.

    Edit: Autant pour moi désolé, je voyais déjà une orde de manchot débarqué...

  7. #7
    Membre expérimenté
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    1 103
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 103
    Points : 1 561
    Points
    1 561
    Par défaut
    sinople arrete de penser que meme sous windows il n'y a pas de serveurs

    avant d'avoir un client quelconque, il faut quand même une partie serveur.

    Pour répondre à ta question Jerede...
    Il n'y a pas de réponse toute faite à ton problème.

    Le préchargement des comptes client pour le "logon server" peut être une solution, mais la mise à jour devra se faire par des requêtes et donc des updates/remontées... donc tant qu'à faire... autant en profiter pour faire tes batchs lors de ces cycles.
    Il est préférable pour un logon server d'avoir en mémoire la majorité des informations de compte, que de devoir aller les chercher à chaque connexion d'un nouveau client.

    Pour ce qui est d'un game server, la problématique n'est plus du tout la même... Si tu ne fait pas de mécanisme pour que les game-server communiquent entre eux, ils ne partagerons finalement que les comptes, mais les joueurs connectés à l'un, ne pourrons pas voir ni communiquer avec ceux connecté sur un autre... typiquement idéal pour 2 realms différents avec les mêmes comptes donc un logon-server unique.
    Passé ce détail conceptuel, il faut savoir que ton game server manipule nettement plus de données qu'un logon-server.
    J'entends par là qu'il manipule TOUTES les données du jeu, à tout instant, donc cela veut dire qu'en plus des "prototypes" des objets, des spells si ton jeu dispose de magie, des créatures et des npc, il faut gérer les connexions clientes pour les joueurs et donc les actes des joueurs...
    Cela représente une charge mémoire et cpu assez importante au final, quand des joueurs sont connectés.

    A titre d'exemple, pour un émulateur de core World Of Warcraft, développé en C++, lorsque le game server se lance, il faut charger en mémoire TOUTES les DBC ce qui représente quelque chose comme environ 100mo de RAM, ensuite il faut charger les maps ce qui représente pas mal de place aussi (surtout les vmaps pour les collisions) et pour finir la base de données avec les données jeux, sans la base realm qui ne contient que les données joueurs.
    On arrive déjà à quelque chose comme 700mo...
    En rajoutant les données joueurs, ....
    Tu va me dire ce n'est rien 700mo... oui c'est sure que sur 4Go ce n'est pas grand chose, mais quand une application consomme trop de mémoire, arrive un moment, ou la consommation excessive de mémoire ralentie encore plus l'application, qu'une consommation minimale, il faut donc trouver le juste équilibre.

    Dans l'ordre général, vue que tu développe en dotnet, il me semble logique d'utiliser une architecture massivement multi-threadée..
    A partir de ce postulat, il est inutile d'encombrer la mémoire avec des données inutiles, comme les données joueurs inutilisées. Ton serveur aura déjà fort à faire avec les données de modèle des créatures, unités/npc, les quêtes s'il y en a, les gameobjects et autres choses que tu jugera bonne d'intégrer à ton gameplay... et également et de façon obligatoire et unilatérale, toutes les instances de tes créatures et de tes npc, car chacune étant "indépendante" il te faudra une instance d'objet par créature et par npc, ce qui peut très vite conduire à des consommation mémoire exponentielles.

    C'est pourquoi il ne vaut mieux charger les données joueurs depuis la base, qu'au moment où l'on va s'en servir, c'est à dire à la connexion de celui-ci au gameserver, et ce dans le thread qui va accueillir au moins au départ, l'intérêt c'est que seul le joueur subira les temps nécessaire au chargement de ses données, le reste du serveur n'est pas impacté par cela.
    Après tout, le joueur n'est pas à 30ms prêt au démarrage de sa session sur le serveur de jeu, n'oublie pas que le joueur est un humain et qu'en dessous d'une seconde, la perception du temps et de la latence est toute relative, surtout lorsque tu n'est pas encore entré dans le monde de jeu...

    Ensuite n'oublie pas non plus qu'à moins que le serveur de données soit physiquement sur le même serveur que le gameserver, l'accès au serveur de données, se fait également par socket, donc ta question commence du coup à perdre son intérêt car, après tout quand tu fait une requête SQL cela équivaut à faire de la communication par les sockets, même si tu n'en n'es pas conscient.

  8. #8
    Membre expérimenté Avatar de ctxnop
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juillet 2007
    Messages
    858
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Morbihan (Bretagne)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2007
    Messages : 858
    Points : 1 732
    Points
    1 732
    Par défaut
    Salut,
    Personnellement je pense que la question que tu te pose n'est pas complète.
    Il ne faut pas se dire "est-ce mieux de tout charger ou de requêter à chaque fois", mais plutôt "qu'est-ce que je dois précharger, mettre en cache, conserver en mémoire ou ne pas conserver du tout ?".

    Il y a des cas où tu peux prévoir ce qui va avoir besoin d'être charger, il peut être judicieux de commencer à charger ca tranquillement en tâche de fond.
    Après, il y a 3 grandes "sources" de ressources pour ton serveur :
    - Les données qu'il a déjà chargé.
    - Celles mises en cache (sur disque dur le plus souvent).
    - Celles qu'il n'a pas chargées (disponibles dans la base de données).

    Pour faire un jeu massivement multijoueur tu n'a pas trop le choix tu dois etre massivement multi-thread, comme l'a dit cinemania. En conséquence il ne faut pas trop se dire "comment économiser les performances ?" mais plutôt "comment répartir les tâches ?".
    Si ton serveur vient a manquer de ressources système il va ralentir, mais tu peux prévoir le coup et organiser tes tâches par ordre d'importances.
    Par exemple, si le serveur manque de ressource, vaut-il mieux ralentir tous les autres joueurs ou faire en sorte que la connexion d'un nouveau client soit plus longue ?
    Pour moi il est clair que le joueur va pas venir pleurer si il met 4/5 secondes de plus a se connecter, alors que si il rame...
    Autre exemple, un personnage est constitué de statistiques (force, endurance, ....), d'un historique (quête accomplies), d'une liste d'amis, d'un inventaire en banque, d'un équipement, ...
    Est-ce que tout ceci est primordiale dès la connexion ? Je pense qu'on peux se permettre de charger plus tard, quand ca sera utile ou en tâche de fond, la plupart des éléments ci-dessus. Après tout si tu ne charge pas l'équipement tout de suite ca veut juste dire que le joueur va se trimballer à poil, par contre s'il est tapé ou qu'il tape une créature sans que ses statiques ne soient chargées, la ca va pas aller.

    Donc pour moi tu dois surtout prévoir un gestionnaire de ressource très générique, qui gère toutes les ressources et surtout leurs chargements et donc qui aura la charge de prendre la décision de garder la ressource en mémoire, de la mettre en cache ou de la supprimer aussitôt utilisation (et donc d'aller la rechercher en base). De plus, un tel système va te permettre de mettre en place des compteurs de performances qui vont t'indiquer quelles ressources sont le plus souvent utilisées ou au contraire le moins souvent. Et donc tu pourra déterminer quelles doivent être mises en cache voire conservées en mémoire et lesquelles peuvent être rechargée depuis la base à chaque fois.

    EDIT:
    Ah oui, juste une petite précision sur les bases de données. Je ne sais pas ce que tu va utilisé mais ca sera probablement une "vrai" base de données (Oracle, Sql Server, Postgresql, MySql, ...).
    Qui sera potentiellement sur une machine différente que celle qui va faire tourner ton GameServer.
    Il est évident que les requêtes à travers le réseau sont moins performante que l'utilisation d'un cache local ou que de conserver les données en mémoire (dans le cas où c'est possible car il faut qu'elle soit disponible cette mémoire).
    Cependant ce n'est pas inefficace pour autant. Les serveur de bases de données implémentent déjà de très nombreuses technologies pour répondre aux requêtes dans des temps extrêmement courts. Sans compter qu'il y a de nombreuses optimisations à faire directement dans le serveur de base de données. En effet, deux requêtes peuvent retourner le même résultat mais plus ou moins rapidement. Par exemple une requête complexe (avec pleins de jointures) est moins rapide qu'une requête simple sur une vue construite via cette première requête (pas sur d'être bien clair).
    L'utilisation des vues, des procédures stockées ou encore des triggers, tout ca peux grandement améliorer la vitesse d'exécution des requêtes.

  9. #9
    Membre averti Avatar de Jerede
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mai 2010
    Messages
    271
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Mai 2010
    Messages : 271
    Points : 422
    Points
    422
    Par défaut
    Merçi à vous deux pour ces réponses très complètes

    Je pense donc, précharger les données des comptes avec le Realm ( sinon il n'a plus trop d'intérêt ).
    Celui ci redirigera le Joueur vers le GameServer approprié ( en avertissant le gameserver, celui ci chargera les informations de base, comme ses personnages ) puis lors du choix du personnage, je chargerai son équipement, et toutes les informations qui le concerne, en esperant que ça ne nuise pas trop aux performances

    Une dernière petite question : sachant que je dois savoir si un pseudo est déja utiliser ou non, le plus optimal serait d'effectuer un COUNT à chaque coup voir s'il n'est pas déja utilisé ou de stocker en local dans une list les pseudos déja utilisé ?

  10. #10
    Membre expérimenté Avatar de ctxnop
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juillet 2007
    Messages
    858
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Morbihan (Bretagne)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2007
    Messages : 858
    Points : 1 732
    Points
    1 732
    Par défaut
    Déterminer si un pseudo est déjà utilisé n'a pas besoin de performances exceptionnelles, et sachant que toute requête doit être placée dans un using afin de libérer correctement les ressources mais également dans un try/catch car il n'y a jamais aucune garantie que la requête s'exécute correctement.
    En conséquence je laisserai le serveur SQL indiquer que le pseudo est déjà utilisé : si la table est bien faite le pseudo est soit en primarykey soit en contrainte unique, donc si tu fais un INSERT d'un nouveau compte donc le pseudo est déjà pris, la requête échoue.

  11. #11
    Membre averti Avatar de Jerede
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mai 2010
    Messages
    271
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Mai 2010
    Messages : 271
    Points : 422
    Points
    422
    Par défaut
    Oui, le problème étant que je ne souhaite pas implanter directement les nouveaux comptes lors de leur création dans la base de données, plutôt les sauvegarder en même temps que les autres comptes, à des intervalles bien précis. De même il faudrait renvoyer au client, si oui ou non, le pseudo est disponible afin de changer l'interface graphique en conséquence. Je pense donc que je vais m'orienter vers un COUNT(), le pseudo est un champ avec un index unique, le clé primaire étant l'id du personnage

    Edit : Je ne peut pas rajouter "Résolu" au titre du message car je ne peut plus l'éditer, cela vient t'il du fait qu'il ai été déplacé ?

  12. #12
    Membre expérimenté Avatar de ctxnop
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juillet 2007
    Messages
    858
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Morbihan (Bretagne)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2007
    Messages : 858
    Points : 1 732
    Points
    1 732
    Par défaut
    Le count est superflu dans la mesure où l'exécution d'une requête indique le nombre de lignes de résultat, en l'occurrence 0 ou 1.
    Mais je ne comprend pas l'intérêt de sauvegarder tous les comptes d'un seul coup périodiquement. Quand tu as 3 comptes ca peut le faire, mais dans un MMO tu peux avoir plusieurs centaines de milliers de comptes et la je te souhaite bon courage.

    Quand au tag RESOLUT il ne faut pas modifier le titre, il faut cliquer sur le bouton en bas de la page.

  13. #13
    Membre averti Avatar de Jerede
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mai 2010
    Messages
    271
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Mai 2010
    Messages : 271
    Points : 422
    Points
    422
    Par défaut
    Ben, je pensais, quitte à utiliser la connexion, autant tout sauvegarde en même temps, en cas de pépin, tous les joueurs ont la même sauvegarde à un moment X. Avec 1000 Joueurs, sauvegarde chaque joueur, disons toutes ses 2min du jeu. Ma base de données va être inondé de connexion ? de plus si la sauvegarde de plusieurs de centaine joueurs tombent en même temps. Tandis que faire des sauvegarde du "monde" à un interval régulier je m'assure en quelque sorte le contrôle des sauvegardes. Disons que je ne prend pas de risque

  14. #14
    Membre expérimenté
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    1 103
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 103
    Points : 1 561
    Points
    1 561
    Par défaut
    Jerede, il ne faut pas confondre, sauvegarde des informations player dans le gameserver, et informations de comptes sur le logon-server.

    La sauvegarde/synchronisation des données joueurs ingame ne nécessite pas de "packager" les saves, car chaque joueur y va de sa propre avancée, et donc de son propre trafic, si un mec se pointe dans une zone vide, et qu'il n'y croise aucun pécor et qu'il va prendre un café, ba ya pas de trafic réseau entre le client et le serveur, juste des tests pour savoir si la connexion est encore en vie... à ce moment là, il n'y a pas besoin de sauvegarder les données.
    Il te suffit de faire des saves régulières genre toutes les secondes, ou toutes les 5 secondes, cela permet d'avoir une base relativement synchro avec les joueurs et d'avoir relativement peu de données à synchroniser au final avec la base de données.
    Dans ton cas l'usage d'un ORM est tout indiqué, car il va gérer lui même l'état des objets mémoires mappés à la base, et selon que leurs propriétés ont été ou non modifiées, les synchroniser lors d'une save régulière...
    En plus tu fou le process de synchronisation dans un thread séparé.

  15. #15
    Membre averti Avatar de Jerede
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mai 2010
    Messages
    271
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Mai 2010
    Messages : 271
    Points : 422
    Points
    422
    Par défaut
    Un ORM ? Je viens de chercher sur google, mais je vois pas trop ce que cela représente un genre de DataSet ?
    Quand tu parle de save régulière du joueur toutes les x secondes, c'est bien dans la base de données ?
    Le Process de synchronisation que tu aborde à la fin de ton message, c'est un thread/joueur ou sur mon gameserv ?

  16. #16
    Membre expérimenté
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    1 103
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 103
    Points : 1 561
    Points
    1 561
    Par défaut
    bon il faut différencier les données qui varient souvent des données à faible variations.

    globalement lorsque tu réalise un gameserver, quelles sont les données susceptibles d'être le plus mises à jour, et donc nécessitant le plus de trafic vers la base de données pour leur sauvegarde ?

    ce ne sont pas les données, sur les comptes joueurs... après tout un account, à part pour le créer, et éventuellement indiquer sa dernière connexion, ou un tag s'il est banni ou game master... il est difficile d'y voir autre chose... cela ne représente que quelques octets qu'on met à jour quand au moment où cela est nécessaire.

    ce ne sont pas non plus les données de base de fonctionnement du gameserver, comme par exemple, les profils des prototypes de créatures/npc si tu en utilise, ou les prototypes des objets du jeu et éventuellement des spells si ta de la magie... a priori ces données ne varient pas ou peu, on peut donc les "persister dans la DB" au moment où elles varient.

    les données qui varient le plus dans un jeu, ce sont les données attenantes à un joueur ou dépendant indirectement de celui-ci. tu va donc avoir deux pôles de données à persister...
    - les informations du joueurs, comme ses points de vie et de mana ou tout autre statistique/caractéristique qui varie pendant un combat, par exemple, et parmi cela on a la position géographique du joueur, pour pouvoir le faire revenir au dernier endroit où il se trouvait lorsqu'il se reconnecte au serveur, par exemple. La géolocalisation est la donnée la plus susceptible de varier.
    - les informations équivalentes sur les différentes instances des créatures et des npcs, actuellement dans le monde du jeu. (je ne parle pas des instances de jeu, mais des créatures effectivement présentes... dans wow si on a 36 instances d'un garde de stormwind cela signifie qu'a l'instant T il y a effectivement, 36 gardes de stormwind présents dans le realm entier, même s'il devrait y en avoir 50...)

    les données à faible variances comme les sorts dont un joueur dispose, sont typiquement des données que l'on peut persister au moment où on en prend acte.
    les données à forte variance ne peuvent être persisté de la même façon, il est nécessaire de faire des lots.
    pour cela, la plupart des serveurs sauvegarde/persiste ce genre de donnée de façon régulières et cyclique, par exemple toutes les secondes, ou toutes les 5s.
    quand tu as 5 joueurs de connectés, cela représente somme toute assez peu de données, mais quand tu commence à avoir beaucoup de joueurs et énormément de créatures dans le monde, cela fait vite beaucoup de données à persister périodiquement, pour cela on peut procéder, en organisant les données à persister.
    Ainsi tu peux décider de regrouper les données relatives à n joueurs ensembles et les persister ensembles en même temps, dans un thread séparés des threads joueurs et des threads critiques du système. Cela étant une tâche assez ponctuelle même si elle se reproduit sans cesse, elle est typiquement candidate à des tâches pour la thread-pool, ou des threads dédiés, mais d'importance moindre (priorité minimale)
    Si tu regroupe, tu fait juste en sorte que la persistance de chaque groupe de données, ne se fait pas en même temps, mais l'une après l'autre, par exemple, ce qui fait que ton thread de persistance travaillera en permanence, et de façon périodique et cyclique persistera les données de tel joueur.

    pour ce qui est de la notion d'ORM c'est totalement différent.

    tu ne vois la gestion des données de la base que comme des tableaux en 2 dimensions avec chaque colonne ayant son propre type.
    cette vision un peu archaïque du monde, est celle qu'on a un php, 99% du temps quand on traite des données... ces données sont ensuite passée dans diverses méthodes et divers objets pour en ressortir le contenu et modifier en mémoire dans les objets concernés les données à modifier ou l'inverse...

    quand on créé un jeu, la première chose que l'on va faire, si on fait de la programmation objet, c'est de manipuler du tout objet, et ton champ de données n'est jamais qu'une instance d'un type spécifique avec des propriétés spécifiques, comme par exemple les points de vie du joueur...
    Un ORM type NHibernate ou Entity Framework permet de créer les liaisons entre ton monde objet, ton modèle de données d'application, et le monde relationnel qui compose ta base, donc ton modèle de données MCD/MPD SQL.
    Parmi les tâches d'un ORM, on a celle du mapping, qui va consister à mapper les données relationnelles sous forme d'instances d'objets d'un type donné.
    typiquement une entité du MCD = un type dans ton application... donc sur un SELECT FROM <entite> on va avoir n lignes de réponses correspondant à n instance de ce type...
    C'est a l'ORM qu'incombe la tâche de suivre les modifications apportées à un objet pour savoir si celui-ci est candidat ou non à la persistance lorsqu'on demande à celui-ci de persister l'état mémoire, dans la base.

    Tu vois, il y a énormément de choses à tenir en compte

  17. #17
    Membre averti Avatar de Jerede
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Mai 2010
    Messages
    271
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET

    Informations forums :
    Inscription : Mai 2010
    Messages : 271
    Points : 422
    Points
    422
    Par défaut
    Je vais regarder du coté des ORM alors

    Tu me conseillerai lequel pour commencer ?
    J'ai cherché sur developpez.net et je crois pas avoir vu de tutoriel dessus, y'en a vraiment pas ?
    J'vais allez voir ça sur la msdn (http://msdn.microsoft.com/fr-fr/library/bb399572.aspx)

  18. #18
    Membre expérimenté
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    1 103
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 103
    Points : 1 561
    Points
    1 561
    Par défaut
    je ne conseil ni l'un ni l'autre...

    le choix d'un ORM plutôt qu'un autre relève d'affinités plus que de logique et développement, car on abouti au même résultat avec différents ORM, seul le cheminement est différent.

    moi personnellement je préfère Entity Framework (dont tu trouvera la doc sur la msdn...) mais cela suppose d'être déjà bien familier avec le concept d'un ORM pour en tirer partie et savoir ce que l'on fait, mais surtout pour comprendre la documentation... en effet, les docs msdn pour ce genre d'outils sont généralement destinées à un public initié ou expert...

    Pour NHibernate on trouve énormément de How-to/tutoriels sur le net et donc plus facilement de la doc que pour Entity Framework.

    Entity Framework est une technologie récente apparue avec dotnet 3.5 SP1 (qu'ils auraient due renommer en 3.6 tant qu'à faire, car on est loin d'un simple assemblage de correctifs de bugs, vu que nombre de fonctionnalités y ont été ajoutée à cette occasion)

    On trouve donc relativement peu de tutoriels ou documents, ou toujours destinés à un public averti car la majorité des personnes communiquant sur le sujet, sont des membres de Microsoft, ou des MCPD.

    NHibernate est nettement plus agé en terme d'existance, et provient d'une communauté libre et ouverte, et n'est donc pas l'apanage de spécialistes en technologies Microsoft d'où la plus grande facilité à trouver de la documentation accessible à tous niveaux (néophyte, initié, expert, ...)

    Maintenant EF dispose d'outils intégrés à Visual Studio 2010 pour faire ses schémas et modéliser les données coté objet et le mapping avec le coté relationnel (on peut même créer le modèle relationnel depuis le modèle objet)
    Mais l'usage de tels outils ne devraient pas être utilisés sans réellement savoir ce que l'on fait, car les problèmes engendrés par les ORM ne sont pas aisés du tout à corriger, et ils sont multiples pour qui ne sait pas ce qu'il fait.

    Je dirais que dans ton cas, avant de te fixer sur un ORM plutôt qu'un autre, tu as déjà beaucoup d'autres choses à affiner.
    Il va falloir sévèrement dégrossir le mammouth comme on dit...
    Non sérieusement, tu as suffisamment de choses à analyser et développer avant d'en venir au choix d'un ORM plutôt qu'un autre, et d'ici là tu seras déjà plus fixé sur les tenants et aboutissant et ce qu'il faut et ne faut pas...
    Tu seras également plus fixé sur ta façon de procédé, qui te guidera vers d'elle même vers un ORM plutôt qu'un autre.

    A partir de là, il sera possible de t'aider à en choisir un, mais pour l'instant je pense que c'est un peu prématuré. Tu n'est même pas sure de ce que tu dois persister, quand, comment... c'est le minimum syndicale avant de se lancer dans une modélisation via ORM... de savoir d'où on vient, vers où on va, et surtout... comment on y va.
    Ce n'est pas à l'ORM de faire ce travail pour toi, la majorité des problèmes vient d'un mauvais usage des outils et parce que les développeurs ne prennent jamais le problème par le bon bout...

  19. #19
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    8 347
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2006
    Messages : 8 347
    Points : 20 347
    Points
    20 347
    Par défaut
    Salut tu ne dis pas du tout quels langages et quel solution logicielle ( .NET,Java ) tu utilises
    Citation Envoyé par Jerede Voir le message

    Edit : Petite question : Un envoi de socket, et y vraiment plus rapide qu'une légère requête sql ?
    Y'a t'il des points sur lesquels je devrai me concentrer afin d'optimiser au maximum les perfomances du serveur ?
    Ce sont 2 choses différetentes : via un socket tu envoies des données un peu "brutes".
    Avec une requête SQL c'est un niveau plus évolué : le client ODBC vérifie les dépassements horaires ( "timeouts"), la gestion des erreurs..
    je dirais que c'est kif-kif, 50/50...

    Avec un socket qui est crée si tu envoies un gros paquet de données,le récepteur prendra plus de temps pour les recevoir et les traiter.
    Il faut éviter donc les gros "buffers".
    Avec une requêtes SQL sur un serveur via ODBC ( ou en natif) c'est simplement une requête..
    si tu veux optimiser les performances c'est soit au niveau des requêtes SQL soit au niveau du code de ton programme...
    Citation Envoyé par Jerede Voir le message
    Devrais-je précharger les informations concernant les personnages au lancement du "game serveur" pour éviter des requêtes incessantes ?
    (Sorry si c'est pas assez explicite, je m'embrouille facilement )
    c'est évident que oui ! Plus tu places de données et de paramètres en mémoire, moins tu fais de requêtes SQL, mieux c'est
    Il faut que tu crées des classes de personnage avec ses attributs ( force,points,position..etc) et ses données sont initialisées au moment du démarrage d'une session.
    En plus avec une grosse base de données le disque qui contient la base a tendance a "swapper" c.a.d. faire un gros fichier temporaire d'échange.

  20. #20
    Membre expérimenté
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    1 103
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 103
    Points : 1 561
    Points
    1 561
    Par défaut
    Mat.M il est sur une section Dotnet, il me semble cohérent et logique de dire qu'il n'est pas partie sur Java...

    puis bon un peu de sérieux, un mmo en java... mouahahahahah
    bon ok je sors

    pour ce qui est des liens SQL... bien disons que ODBC c'est comme qui dirais tendre la perche pour se faire taper dessus...
    c'est lent et tout sauf exploitable pour un MMO, ou un jeu ou une application métier à fort trafic en règle générale.
    on utilisera donc typiquement des liaisons natives ou des connecteurs spécifiques, mais pas d'odbc, ou il alors c'est qu'on a pas la lumière à tous les étages.

    la communication par socket ca c'est pour la communication avec les clients, parce que bon... refaire la com avec une database... je te souhaite bien du plaisir à reprogrammer cela

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 2 12 DernièreDernière

Discussions similaires

  1. [Projet terminé] Transformice, un petit jeu flash multijoueur
    Par Tigrounette dans le forum Projets
    Réponses: 1
    Dernier message: 09/05/2010, 16h58
  2. Petit jeu flash multijoueur en ligne
    Par mage34 dans le forum Flash
    Réponses: 1
    Dernier message: 08/01/2008, 21h49
  3. Jeu en multijoueur
    Par poly128 dans le forum Web & réseau
    Réponses: 9
    Dernier message: 06/01/2008, 17h57
  4. jeux en ligne massivement multijoueur
    Par @v@lon dans le forum Développement 2D, 3D et Jeux
    Réponses: 20
    Dernier message: 16/03/2007, 11h54
  5. [MFC] Problème Socket + Connexion SQL
    Par BananaUltra3C dans le forum MFC
    Réponses: 6
    Dernier message: 20/05/2005, 17h41

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo