|
Légende
|
Bonjour à tous,
j'aimerais monter un dossier sur la constitution ou plutôt les composants techniques des jeux de rôles en ligne. Votre aide serait plus qu'apprécié. Qu'est-ce qui compose exactement un jeu? Nous entendons souvent parler de moteurs graphiques, moteurs physiques, DirectX, OpenGL, bases de données, etc. Quel est le rôle de chacun de ces composants? Pouvez-vous donner des exemples comparatifs? (exemple : Ogre pour les moteurs 3D, utilisé pour X, Y ou Z jeu.) Voilà, j'espères qu'avec votre aide, je vais moins m'y perdre, en ayant asser de ne pas tout comprendre. Amicalement, Sere |
19/01/2007, 09h53
|
Comment c'est fait?
| Suivre |
|
|
Partager | Rechercher |
|
Ca a plus sa place sur les Faiseurs.
En provenance de la Croisée. |
|
19/01/2007, 12h54
|
|
Alpha & Oméga
|
Houlà, que de vastes questions... Je vais essayer de répondre brièvement pour pas te noyer trop dans la masse d'informations dans un premier temps.
PS: Je part des le status quo suivants car ta demande est assez floue... 1- en parlant de "jeux de rôle en ligne" tu parles uniquement de MMORPGs et non pas de jeux de rôle solo avec mode multijoueur via internet 2- tes questions portent uniquement sur la partie software du jeu et non pas sur la partie hardware ni sur la partie logistique Si je me trompe sur un point merci de me le signaler que je corrige mes réponses. Citation :
1- Le serveur Il s'agit du programme qui centralise les informations et coordonne le tout afin que les joueurs puissent jouer ensemble (par exemple: quand un joueur déplace son personnage, le serveur centralise l'information et la redistribue aux autres joueurs à sa portée pour qu'ils puissent voir que le dit personnage s'est déplacé) Il est lui-même composé de nombreuses parties comme: 1.1- Le code réseau C'est ce qui assure la communication des informations entre le serveurs et les joueurs. Assez transparent, il est néanmoins vital car mal programmé, il est une des sources majeures du problème connu sur le nom de "Latence" ("Lag" en anglais) qui cause des saccades à l'écran quand on joue 1.2 - La base de données C'est ce qui stocke toutes les informations sur ce qui se passe dans le jeu. Quand un joueur arrive par exemple dans un lieu, la base de données est consultée pour voir quels personnages sont présents dans ce lieu et que le programme client du joueur puisse alors les lui afficher. 1.3- Le gestionnaire d'évènements Aussi parfois appelé, par abus de langage, "L'IA du jeu", c'est la partie du serveur qui régule les actions qui se passent dans le jeu. Par exemple, si un joueur essaie de frapper le personnage d'un autre joueur, que ce passe-t'il? Et bien le code réseau fait transiter l'information jusqu'au serveur, là le gestionnaire d'évènement le récupère, applique les règles de combats, faits les calculs pour savoir si la cible se fait toucher, combien de dommage elle subit... etc Puis le gestionnaire d'évènements renvoie les résultats à tous les joueurs à portée de vue de l'action pour qu'ils sachent ce qui s'est passé. La raison pour laquelle ce n'est pas le client qui décide ce genre de chose directement est essentiellement pour éviter la triche: si le moniteur d'évènements était sur le client, rien n'empêcherait les joueurs versés dans l'art de la programmation de le modifier pour permettre à leurs personnages de faire des choses qu'ils ne devraient théoriquement pas pouvoir faire comme traverser les murs, voler, esquiver absolument toutes les attaques... etc Cela ne semble pas grand chose mais l'impact est gigantesque: comme c'est une seule et même machine (celle sur laquelle est installé le serveur) qui gère tous les évènements de tous les joueurs, il faut qu'elle soit très performante (un PC de salon ne suffit pas!) et donc elle coute très cher à achter et à entretenir, ce qui est une des raisons majeure du fait que les MMORPGs font payer un abonnement. De plus, cela impose d'avoir une structure centralisée et interdit donc l'emploi de la technologie P2P pour ce genre de jeu (et ce jusqu'à ce qu'on trouve un autre moyen pour empêcher la triche... mais c'est pas gagné) 2- Le client Il s'agit du programme que le joueur installe sur son ordinateur pour pouvoir jouer au jeu (on dit par abus de langage "installer le jeu", mais en fait on installe pas le jeu: on installe le programme qui permet de joueur au jeu) Comme le serveur, il est composé de plusieurs parties, dont: 2.1- Le code réseau Oui oui, le même que celui du serveur... enfin presque. Disons qu'il est codé différemment sur le client mais son but reste le même... tu peux voir le code réseau du client et celui du serveur comme le téléphone que tu tiens dans la main et celui que tient la personne que tu appelles dans la main pour te parler: les deux sont similaires, bien que probablement différent, mais ils fonctionnent comme un ensemble pour vous permettre de dialoguer entre vous. Et bien le code réseau c'est pareil que les téléphones, mais entre le programme-client et le programme-serveur d'un jeu. 2.2- Le moteur graphique C'est la partie du programme-client qui permet d'afficher le jeu à l'écran. Un moteur graphique est directement responsable de la beauté d'un jeu: sans un bon moteur, le jeu est moche... pareil si le moteur est bon mais qu'il a mal été employé par les développeurs. Par exemple: le moteur graphique décide des changements de couleurs à appliquer aux objets quand on passe de la nuit au jour, comment on dessine une jambe ou un bras à l'écran... etc. OpenGL et DirectX sont des technologies à travers lesquelles le moteur graphique peu donner ses ordres à la carte graphique de l'ordinateur du joueur... carte graphique qui pilote l'écran de l'ordinateur et donc ce qui s'affiche dessus. OpenGL est plus simpliste mais compatible avec tous les systèmes d'exploitation, un moteur graphique qui utilise OpenGL marche donc sur tous les types d'ordinateurs en théorie... DirectX est lui plus complet et donc nécessite moins de travail (et donc d'argent) pour faire un bon moteur graphique mais c'est un produit de Microsoft et donc les moteurs graphiques qui l'utilisent ne fonctionnent que sur Windows. 2.3- Le moteur physique C'est l'élément qui régule les déplacement dans le jeu. Par exemple, un personnage peut-il traverser un mur? Si une flèche est lancée, quelle est sa trajectoire? Un objet qui percute un mur rebondit-il ou s'arrête-t'il tout simplement? Dans un MMORPG, le moteur physique est en deux parties: celle des effets graphiques et celle des mouvements des personnages. La partie des effets graphiques (entends par-là les mouvements qui n'influence pas le résultat d'une partie, comme les étincelles de deux armes qui s'entrechoquent) est gérée par le moteur graphique... cette partie du moteur physique y est donc souvent inclue. La partie des mouvements des personnages (tout ce qui influence le résultat du jeu, comme savoir ou le personnage se trouve parce que cela le met à portée de telle attaque ou de telle action) est en fait un simple moniteur qui récupère les résultats provenant du gestionnaire d'évènements du serveur et qui dit au moteur graphique comment les appliquer à l'écran. Exemple: Un personnage se déplace... l'info transite via le code réseau jusqu'au serveur, là le gestionnaire d'évènements applique les règles du jeu, dont une qui dit que s'il entre en collision avec un autre personnage, il s'arrête... en consultant la base de donnée, il voit qu'il y a bien un autre personnage sur son chemin à 3,1 mètres de lui et donc décide qu'il doit s'arrêter à cette distance... cette décision repart par le code réseau jusqu'au client et est récupéré par le moteur physique qui dit au moteur graphique: "dessine sur l'écran le fait que le personnage se déplace en avant de 3,1mètres, puis s'arrête brutalement" 2.4- L'interface C'est la partie du programme qui dit "Le joueur à appuyé sur la touche X, ça veut dire qu'il veut faire ceci.... et puis il a cliqué à tel endroit de l'écran avec sa souris, donc ça veut dire qu'il fera cela sur l'objet situé à cet endroit de l'écran" Bien que cela semble trivial, l'interface (on dit parfois "interface graphique) n'est pas négligeable dans le sens qu'elle conditionne 90% de l'ergonomie d'un jeu. Une interface mal conçue et le joueur ressent un inconfort réel quand il essaie de jouer au jeu... vous avez déjà appuyé sur une touche sur votre ordinateur en pensant que ça allait faire un truc mais cela vous a fait complètement autre chose qui vous a mis dans la merde? Et bien c'est l'interface qui est responsable... Cependant, il est impossible de faire une interface parfaite, parce qu'aucun être humain n'a la même logique ou les mêmes réflexes face à un PC, ce qui fait qu'il est assez dur d'avoir une interface que tout le monde trouve bonne... donc ne soyez pas trop durs à son sujet. En général on juge plutôt une interface au nombre de personnes qui n'ont pas trop de problème avec... en dessous de 15%, c'est déjà une très très bonne interface. |
|
19/01/2007, 12h59
|
|
Alpha & Oméga
|
Pour coté serveur, il faut aussi penser à tout ce qui est plateforme d'authentification, de facturation...
Pour la base de données, on peut les découper en 3 familles: - la BDD static: ce sont les données de l'univers invariants - la BDD dynamic: ce sont les données liés au instances des mondes virtuels - la BDD abonnés: ce sont les données personnelles du joueurs (liée à l'authentification). A coté, il y a tout ce qui est outils permettant d'ajouter des quetes/evenement dans le jeu par des exploitants type GOA, des outils de supervisions... Pour l'interface client, attention: ne jamais faire confiance au joueur. En general, il est preferable d'envoyer des infos brutes type "il y a eu un clique en coordonnée x, y de l'ecran... Le serveur sera en charge de le traduire en action de jeu (par ex "deplacement en x,y,z")). En effet, donné acces à des interfaces permettant le deplacement dans le monde virtuel ouvrirait la porte à des hack comme la teleportation. Pour faire simple, le client: - lit les evenements utilisateurs ; - envoie un flux de controle ; - recoit un flux descriptif d'affichage ; - fait l'affichage. Le(s) serveur(s): - recoit les flux de controles & controles la veracité de ces flux puis les prend en compte si ok; - calcul l'evolution du monde (IA, recherche de chemin, execution des GameMechanics...) ; - gere les BDD; - envoie un flux descriptif de ce que doit afficher le client pour chaque client. - gere la connexion/facturation - gere des interfaces backoffice pour les admin & les animateurs. |
|
19/01/2007, 16h19
|
|
Alpha & Oméga
|
Citation :
J'attends de qu'il me confirme si cet aspect l'intéresse avant me lancer dedans parce que cela inclue beaucoup de choses: hotline, administration, facturation... etc Citation :
 Bon, je vais tenter de répondre quand même, mais si l'auteur du fil n'est pas un technicien dans l'âme, je lui recommande de zapper le passage qui va suivre sous peine de migraine  ----------------------------------------- Oui... et non, Godio. La solution la plus généralement retenue (du moins parmi les devs qui ont jamais communiqué leurs choix sur le sujet) est bel et bien de laisser le client traduire le clic sur l'écran en instruction de déplacement MAIS cette instruction de déplacement n'est ensuite appliquée réellement en jeu que si le gestionnaire d'évènements du serveur donne son aval. Exemple: - Le joueur clique en haut à gauche de l'écran - L'interface traduit en "déplacement du personnage se déplace vers le point X,Y" - Le code réseau transmet cette traduction vers le serveur - Le gestionnaire d'évènement vérifie que X,Y est accessible au personnage, qu'il y a pas d'obstacle du la route, que le personnage est en état de se déplacer... etc etc... et renvoie une réponse style "Ok pour le déplacement du personnage en direction X,Y mais arrêt complet en cours de route sur plan d'eau (type=rivière) au point W,Z " - Le code réseau fait transiter la réponse vers le client - Le moteur physique reçoit la réponse et demande au moteur graphique: "Représente moi le personnage qui court jusqu'en W,Z... avec son pied qui fait une gerbe d'eau de magnétude 2,7 - correspondant à la vitesse prise sur une telle distance de course- à l'arrivée et arrêt brutal du mouvement. Affiche le message 'Vous ne pouvez pas traverser la rivière' à ce moment-là" - A l'écran, le joueur voit en réponse à son clic son personnage courir vers l'endroit où il a cliqué... arriver au bord de la rivière en faisant des éclaboussures avec son pied et s'arrêter... Le jeu lui dit qu'il ne peut pas traverser la rivière Maintenant, pourquoi l'idée de laisser le serveur traduire le clic à l'écran n'est-elle pas beaucoup employée? Des dires des devs qui se sont exprimés sur le sujet, c'est parce qu'il est assez compliqué pour le serveur d'interpréter des coordonnées à l'écran sans avoir toutes les données sur le hardware de l'ordinateur du client. Par exemple, selon la résolution du moniteur, cliquer à 2,7cm à partir de la droite et 11,4cm à partir du haut de l'écran ne représente pas tout à fait le même lieu sur le jeu... il est donc souhaitable que cette interprétation se fasse du côté du client, qui lui a toutes les billes en main pour faire cela (il a même le moteur graphique à disposition, c'est a dire le bout de programme qui a DESSINE à l'écran ce qui se trouve en 2,7 par 11,4... on ne peut pas faire mieux) Cela décharge en plus le serveur d'une partie de ses calculs, même s'il doit quand même vérifier que la traduction soit applicable au niveau des règles du jeu pour éviter toute triche... (Serveur: "Euh... le client vient de me dire que son personnage s'est déplacé en 13476,4390.... je consulte la base de données.... y'a 2,7secondes il était en 2045, 1100... par calcul, ca veut dire qu'il se serait déplacé à 433km/h... ERREUR! La vitesse limite est de 15km/h, je dis au client que je refuse ce mouvement et qui doit afficher le personnage comme n'ayant pas bougé") La preuve de l'application de ce système à beaucoup de MMOG est le phénomène de "retour arrière" qu'on y expérimente en cas de fort lag. Voici ce qui arrive en vrai: - Le joueur est en X1,Y1 - Le client demande un déplacement en X2,Y2 - Le serveur tarde à répondre car le réseau à quelques problèmes - Dans une tentative d'éviter la saccade bien connue, le client va alors décider d'évaluer par lui-même si le déplacement est valide pour tenter de prévoir la réponse du serveur... il applique les règles du jeu, et tout semble bien, alors il demande de manière pré-emptive au moteur graphique d'afficher le mouvement du personnage comme il devrait être - Dans une situation ordinaire, cela ne poserait pas de problème: une saccade aurait été évitée à l'écran et le serveur envoierait une confirmation du mouvement après coup... mais aujourd'hui le réseau est vraiment vraiment mauvais et la réponse, après 3-4 secondes n'est toujours pas arrivée! (sur certain jeux, le client va alors décidé de ralentir la course du personnage à ce moment-là... c'est le phénomène de ralentissement qui se produit parfois avant le retour arrière) - Le joueur continue à courir, le client demande un déplacement un peu plus loin en X3,Y3 - Le serveur a raté le premier message... il reçoit le second... pour lui, le personnage demande à se dépacer directement de X1,Y1 départ en X3,Y3 sur la carte, soit deux fois la distance prévue d'un seul coup... il calcule: cela dépasse la vitesse autorisée... il refuse et annule le mouvement - Le client reçoit l'information... le mouvement est annulé. Il renvoie le personnage en X1,Y1 alors qu'il se situait en X2,Y2 à l'écran... - Devant son écran, le joueur à l'impression que son personnage vient de se téléporter en arrière: c'est le lag qui vient de foutre le bordel. Si le client n'interprétait pas le clic pour le traduire en mouvement, il n'aurait pas pu demander l'affichage pré-emptif et donc à l'écran le personnage ne se serait pas déplacé en X2,Y2... et donc il n'y aurait pas eu de retour en arrière visible quand le serveur aurait exigé que le personnage reste en X1,Y1. Ce phénomène de retour arrière démontre donc l'existance d'une interprétation clic->mouvement du côté du client. |
|
19/01/2007, 18h44
|
|
Alpha & Oméga
|
Y un intérêt aussi et non des moindres c'est que le client peut anticiper et faire l'animation du perso qui se deplace au point choisis immédiatement quitte à faire un 'retour en arriere' si ca va pas, ca permet au joueur d'avoir l'impression qu'il n'y a pas de latence, parce que dans un jeu Point&Click encore ca va, dans les jeux où on controle le perso directement s'il y avait 1/2seconde de décalage entre 'j'appuis sur la touche avancer' et l'action ce serait pas vraiment agréable.
|
|
19/01/2007, 20h00
|
|
Alpha & Oméga
|
C'est en effet sans doute une autre raison de ce choix.
|
|
19/01/2007, 20h25
|
|
Légende
|
Je tiens d'abord à vous remercier, Moonheart, Godio/Chanterelia et Evohe/Lara, vos réponses sont plus qu'appréciés. Jusqu'ici ça va, pas de migraines.
 Citation :
2 - À la base, oui, je ne voulais des réponses que sur la partie "Software", mais tout ce que vous avez dis était très intéressant/enrichissant. Si vous voulez aborder plus en détails les parties "Hardware" et "Logistique", je suis tout ouïe. Submergez-moi de connaissances, je prendrais des notes et poserais des questions au besoin. (Évitez d'écrire en binaire ou de me lancer du code par la tête parcontre, ça c'est moins drôle.) J'ai particulièrement apprécié la partie décrivant les différences DirectX/OpenGL. Si en plus vous aviez la gentillesse de me préciser quel langage de programmation est le plus courant par objet, ce serait super! (moteur graphique, physique, base de données, etc.) C? C++? Encore merci de m'aider à comprendre le fonctionnement d'un jeu en ligne, déjà je peux faire des recherches plus poussées sur le web et combler mes lacunes. Si jamais vous avez aussi des liens d'articles, de sites ou des livres à conseiller, je suis preneur. Amicalement, Sere |
|
20/01/2007, 08h05
|
|
Alpha & Oméga
|
Tes questions sont un peu trop vastes pour qu'on les expose comme ça, sur forum.
Il faudrait que j'écrive tout un dossier pour exposer toutes les connaissances attenantes au style "MMORPG" (je préfère le terme "MMOG" personnellement) que je possède, et je ne suis même pas un professionnel du milieu. Je vais donc m'en tenir aux questions précises parce que les questions génériques me prendrais des joueurs à détailler. Citation :
Citation :
Surtout les articles de Richard Bartle, Jessica Mulligan et Dave Rickey qui sont des professionnels du milieu et donc des sources très fiables d'informations. Attention cependant à bien faire le tri entre ce qui parle de MMORPG et ce qui parle d'autre choses dedans... Sinon, tu risques de faire d'énormes confusions. Richard Bartle, par exemple, par assez souvent des MUDs, les ancêtres du MMOG plutôt que de ces derniers. |
|
20/01/2007, 14h12
|
|
Alpha & Oméga
|
Je ne vois pas trop le pb de dimension d'ecran. les evenements sont publiés selon une echelle correspondant au port de vue de la fenetre (on ne resonne pas en cm en info).
Ce qui me surprend dans ta technique, c'est que la recherche de chemin serait donc executé coté client ("aller de A vers B" peut signifier "A->F->G->B" en recherche de chemin). Or laisser cette logique coté client est quand meme etrange surtout dans un monde dynamique où beaucoup d'objet à collisions circulent (les autres joueurs, les mobs...). Cela depend peut etre du MMO. Ceux que je connais, la recherche de chemin est bien executé coté serveur, la position de progression etant envoyé regulierement par UDP. Pour donner l'effet de fluidité, le client applique un algo de smooth moving type Dead Reckogning Alg (le predicat est que, par redondance, le mouvement des mesh restent fluides, donc on peut anticiper la trajectoire en fonction du mouvement precedant & si il y a erreur on recadre le mouvement pour tendre vers l'objectif). Pour revenir à l'idée du flot de controle pure, il faut savoir qu'il existe meme actuellement des solutions deportant pratiquement l'ensemble du client sur le serveur (soluce utilisée en labo & au Japon)... L'abstraction du client est telle qu'il ne fait qu'envoyer un flux de controle vers le serveur et recoit un flux video en retour. On devrait voire ce type de client/serveur chez nous d'ici quelques années. Voici d'autres ressources à lire: http://www.gamedev.net/reference/des...mmog/page1.asp Plutot Bizz et infra general (tu as des schemas vers la fin) http://www.raphkoster.com/gaming/moore.shtml Plutot Bizz & GD: http://www.igda.org/online/IGDA_PSW_Whitepaper_2004.pdf Sinon il doit bien y avoir des ressources sur gamasutra. |
|
22/01/2007, 10h17
|
|
Alpha & Oméga
|
Citation :
Envoyer des "actions" / "validation d'action" pour un serveur c'est enormement plus simple que d'envoyer une video. On passe de 3KO/s a pour une qualité pas trop pourris du 300KO/s. Autant pour le client (si il est en ADSL ou +) ca passe, mais transpose ca avec 3000 joueurs par serveur. rien qu'avec un serveur on passe de 9GO/s à 900GO/s. sachant que dans le cas des 3KO/s c'est un max (car on fait pas tous le temps des actions), alors que pour le cas de la video c'est continue.... donc à mon avis, on est pas pret de voir ca sur des MMOG... Citation :
Dans le cas des controles type clavier / pad, en regle general tu envoit plutot une vitesse / direction / position regulierement, qui est "corrigé" par le serveur en cas de probleme. Dans tous les cas, le client "aide" le serveur en lui donnant une information plus pertinante que "l'utilisateur à click avec le bouton gauche au pixel 36 / 489" qui serait ingerable pour le serveur. |
|
22/01/2007, 13h25
|
|
Alpha & Oméga
|
Citation :
Pour les debits, il est certain que ca consomme plus en BP (mais en contre partie un client leger suffit pour jouer etant donné que le besoin en calcul 3D disparait) et quand je parle que ce n'est pas pour tout de suite chez nous, c'est bien dans le sens que les debits de dans quelques années ne seront pas les memes qu'actuellement. exemple d'appli en corée: http://www.clubit.co.jp/eng/press_eng/2005/050829.html Pour l'histoire de coordonnées en jeu plutot qu'absolu, j'y crois bien puisque c'est la méthode la plus simple. Néanmoins, un message de type "aller en x, y, z" permet la simulation de trames pour voyager simplement "aller "au coordonnée d'un endroit clé à l'autre bout du monde" et perso si on a la puissance de calcule sur le serveur (surtout que ce n'est pas cela qui va consommer le plus) je ne vois pas en quoi c'est fastidieux de le faire coté serveur (celui-ci ayant la connaissance du port de vue du joueur et des coordonnées des assets & autres objets). Par contre, ce qui m'interresse, c'est de savoir si, dans votre cas, vous utilisez une comm de type TCP ou UDP ou hybride pour gerer les deplacements? |
|
22/01/2007, 13h41
|
|
[nono]
Oracle
|
De toute façon, ce sont les développeurs qui font le choix de la technique à utiliser.
Auttant je connais des jeux où le serveur fait des vérifications des positions des joueurs (Neverwinter Night, Guild Wars....). Auttant, dans certains jeux, seul le client fait les calcul de position (comme DAoC). En effet, même en débranchant un câble réseau, on pouvait continuer à se déplacer. Si on rebranche ce câble avant la fermeture du jeu, rien ne se passe. Pas de retour en arrière. Par contre, les autres joueurs voit un personnage faire "un saut". De même, lors de lag, il apparaissant que le serveur enregistrait un déplacement, alors que le joueur s'était déjà arrété. Le joueur en question ne voit rien, cependant, les autres le voit courir dans une direction avant de le voir se téléporter à sa position initiale. Beaucoup connaissent ce phénomène rendu célèbre pour le "pull au lag" qui a décimé plus d'un groupe... ( le serveur calculé qu'un monstre été à porté d'un joueur, alors que ce n'était pas le cas).par l'absence de vérifications, des logiciel de triches ont effectivement existé (mais il est facile de les détécter, et les comptes les utilisant ont été fermés). Par contre, des bugs qui faisait disparaître des bâtiments entiers, ou juste certaines parties (comme les portes) , empêchait le client de faire les détéction de collisions, et il été possible de traverser les murs. (très embêtant en RvR...). A DAoC, ces bugs ont toujours été corrigé très très vite :P |
|
22/01/2007, 18h00
|
|
Alpha & Oméga
|
Citation :
Ce n'est donc pas une information suffisante pour qu'un programme détermine une destination sur un MMORPG, il faut aussi des infos sur le hardware, et ça, c'est pas trop le genre de truc qu'on envoie au serveur. (Déjà, c'est illégal, ensuite, c'est une hérésie pour la consommation bande passante) Citation :
(Mais ceci dit, ça n'a rien d'impossible, même dans un monde dynamique) |
|
22/01/2007, 18h24
|
|
Alpha & Oméga
|
Je ne parle pas non plus en pixel mais selon un ratio de la fenetre... Le client sait la taille de sa fenetre, il sait où dans la fenetre l'utilisateur clique donc il peut envoyer un evenement interpretable par le serveur. L'affichage & le control deporté est quelque chose qui n'est pas neuf.
^^Pour la recherche de chemin coté client, avec du reverse, il est donc plus facile de modifier le prog afin d'eviter les collisions et pour atteindre des raccourcis. De mon coté, je considere cela comme une faille. De plus, la recherche de chemin des mobs est faite coté serveur: ca fait bizarre de faire un peu de recherche de chemin d'un coté de l'appli et un autre de l'autre alors que le tout existe coté serveur. |
|
23/01/2007, 09h00
|
|
[nono]
Oracle
|
Il faut faire le choix entre sécurité et performances.
Envoyé au serveur la position d'un curseur sur l'écran, c'est réaliser un affichage (même sans textures et effet kikoo , et qui ne sera pas affiché) pour CHAQUE client coté serveur....C'est à mon avis, beaucoup trop de calculs pour un gain de sécurité pas si énorme que ça. Faire les calculs du choix du chemin par le client, c'est alléger le serveur de calculs supplémentaires si il n'a qu'à vérifier le résultat. Quand au client que reçoit un flux vidéo, c'est pas pour tout de suite. Car ça signifie que les carte graphiques doivent être du coté serveur, et non du coté client. Or, nos cartes ont déjà du mal à n'afficher que les images d'un seul joueur. Comme chaque client à une vue différente, celà signifierait qu'il faut autant de cartes graphiques sur le serveur que de clients connectés ! C'est un peu comme le calcul de la vue 3D pour savoir où le client à cliqué, sauf qu'ici on se doit d'afficher les textures et les effets kikoo Même si je suis sur qu'il en faudrait moins en réalité, car les calculs 3D seront plus simple pour les joueurs regroupés dans un même lieu... A propos des langages utilisés, je ne sais pas ce qui est utilisé réellement. Cependant, je sais que les serveurs pirates de certaines jeux (comme Lineage II) sont codé en Java, capable de gérer quelques centaines de joueurs ( inférieur à 500 à ma connaissance). Je ne m'étendrais pas sur ce sujet "sensible", néanmoins celà prouve qu'il est possible de créer un serveur dans beaucoup plus de langage que simplement le C++. (D'ailleur, je verrais mal un serveur codé en C, sans POO.....). |
|
23/01/2007, 10h18
|
|
Alpha & Oméga
|
Citation :
@Godio : tu oublis un truc, la théorie c'est bien, la pratique c'est mieux, il faut faire des concessions entre jouabilité et securité, sur un Point & Click un decalage dû à la latence c'est pas grave, sur un jeu où le déplacement se fait au clavier c'est impensable. Et rien n'empeche de causer des retours en arriere si un mouvement decidé par le client n'est pas valide. |
|
23/01/2007, 10h42
|
|
Alpha & Oméga
|
Citation :
 Ton erreur est cependant de croire que de nos jours, on limite souvent l'interprétation du clic côté client au ratio. En réalité, la plupart du temps, on interprète aussi ce ratio pour en faire des coordonnées de carte, et c'est cela qui est envoyé au serveur. Cela évite en effet au serveur de calculer les correspondances ratio<->coordonnées de carte pour des milliers de joueurs et ce sans risque de triche pour autant car en effet... même admettons qu'un joueur modifie son client pour qu'un clic de souris donne les coordonnées de carte X2,Y2 au lieu de X1,Y1, cela ne lui donnera pas pour autant la possibilité d'amener son personnage là où il ne peut pas aller ou par un chemin différent s'il le peut car cela reste le serveur qui décide de la validation du mouvement et du pathfinding associé. Citation :
Si un joueur modifie son client en ce sens, tout ce qu'il aura ce sera des saccades: le personnage à l'écran commencera a bouger selon le pathfinding qu'il aura programmé, puis le pathfinding calculé par le serveur arrivera et contredira tout, le personnage sera alors "téléporté" à l'écran sur le pathfinding officiel et le jeu considèrera qu'il ne s'en est jamais écarté. Citation :
Si on devait attendre la validation du serveur pour toute action, alors on aurait souvent des temps de latence très très visible entre le moment où le joueur donne un ordre à son personnage et celui où il commence à l'exécuter. Calculer aussi du côté client permet au dit client de prévoir avec 95% d'exactitude la réponse du serveur et de prendre les devants pour donner une vraie impression de temps-réel. |
|
23/01/2007, 11h10
|
|
Alpha & Oméga
|
En fait maintenant que j'y pense sur les Point & Click c'est sûrement des coordonnées x,y,z qui sont envoyés et non juste x,y, quand je click sur la petite colline au fond on va à cet endroit si la colline n'y avait pas été ma destination aurait été à une distance plus grande, donc à mon avis plus qu'une simple position du click par rapport à l'ecran, le client regarde plutot quel était la coordonné x,y,z du pixel qui etait sous la souris au moment du click et transmet cette valeur, car sinon le serveur devrait en plus calculer où ce situe la destination en fonction du point de vue du client, l'angle de la camera (qu'on peut bouger, zoom ou dezoom, l'horreur si la position de la souris est simplement envoyé)
|
|
23/01/2007, 11h29
|
|
Alpha & Oméga
|
Citation :
Citation :
Citation :
Cependant, pour la com type jeux d'action, je n'ai pas non plus dit qu'on ne pouvait pas "anticiper" le mouvement des objets coté client ou meme afficher directement par le client, bien au contraire tant que cela reste du rendu pur & que l'etat réel est calculé par le jeu (le serveur) et non envoyé par le client. Pour moi, c'est là le hic dans certains postes, j'avais l'impression que le client prenait des descisions (mais au vue du dernier post de Moon, j'ai l'impression que pour lui aussi le serveur fait foi. Le client ne faisant que des calculs tel que Pathfinding dans un souci d'anticipation). Dans le premier cas, si le client s'est trompé dans l'anticipation, il existe dejà des algo pour "recadrer en douceur l'erreur d'anticipation sur la trajectoire réelle". Il suffit de ne pas envoyer un descriptif du render state à débits trop lent pour que cela ne soit pas perceptible par le joueur. Apres, c'est comme tu dis: Securité vs performance... Citation :
|
|
23/01/2007, 11h30
|
|
Alpha & Oméga
|
Citation :
|
|
23/01/2007, 11h37
|
|
Alpha & Oméga
|
Il existe dejà beaucoup de jeux marchant avec cette soluttion, issue de PC, PS2 & XBox. L'idée est d'executé le jeu coté serveur (le serveur executant plusieurs sessions de jeux). Ce meme serveur se charge du rendu (dans le cas qui nous interresse le serveur d'affichage jour le role de client du MMO) et au lieu d'injecter le rendu à l'ecran, il l'injecte dans un flux video... Donc que ce soit 2D, 3D, c'est indepedant de la plateforme de diffusion. La dependance etant plus dans le cout en calcul que peut demander un jeu 3D au meme titre que tout jeu.
Apres, question chiffre, je ne peux parler que de ce qui est communiquer par GCluster (NDA oblige). |
|
23/01/2007, 11h44
|
|
Alpha & Oméga
|
Tu réponds pas à ma question au sujet l'impact de la latence sur la jouabilité du jeu
|
|
23/01/2007, 11h46
|
|
Alpha & Oméga
|
Tout ce que je peux dire (NDA et tout ca), c'est que selon les criteres d'ergonomie dans le jeu c'est largement acceptable pour des jeux d'actions. Pour te donner un ordre concret avec des annonces publiques, ils ont des jeux d'action (donc jouable (sous entendu temps de reponse correspondant aux attentes publics)) tournant tel que Collin Mc Rae 2005, Toca Racing, les Resident Evil... Tu as quelques autres titres ici
|
|
23/01/2007, 11h48
|
|
[nono]
Oracle
|
Citation :
Moon aussi le dit:Citation :
Quand on clic sur l'écran, on obtient les coordonnées x et y de l'écran. Alors oui, selon la résolution de l'écran, les même coordonnées peuvent pointer des objets différents, mais je ne vais pas m'attarder sur ce problème qui peut facilement être contourner. La question à se poser est: comment savoir sur quel objet, ou emplacement du terrain est ce que je viens de cliquer ? Si on envois les cordonnées du pointeur de la souris, c'est au serveur de répondre à cette question. Pour y répondre, il y a plusieurs solutions. Je n'ai jamais travaillé avec DirectX, mais je sais qu'en OpenGL, il n'existe pas de solution native facile à utiliser. Il est possible d'utiliser une seconde image (que l'on n'affiche jamais), où chaque couleur représente un objet (chaque objet à une couleur unique donc). Il suffit de savoir quel est la couleur du pixel pour connaître l'objet cliqué. Cette solution peut être utilisé pour sélection un objet (un drop, un joueur etc...), mais pas à connaître les coordonnées d'un terrain. Là encore, il existe plusieurs solution. La plus simple est de tracer un rayon invisible partant du point de vue de la caméra et se trouvant sous le curseur de la souris. On calcul alors les points de collisions avec les objets rencontrés. Ces techniques demandent donc de connaître l'environnement 3D du joueur. C'est pourquoi il est plus simple de faire le calcul du coté client qui n'enverra que le point de collision sur la carte au serveur, plutôt que d'envoyer toute la scène pour que ce soit le serveur qui face ce calcul. J'espère que je me suis mieux expliqué
|
|
23/01/2007, 12h39
|
| Suivre |
Connectés sur ce fil1 connecté (0 membre et 1 invité)
Afficher la liste détaillée des connectés
|