salut
Je me permets de lancer ce sujet afin de recueillir des informations sur le sujet "online" (jeux type aventure, RPG, mais aussi pour d'autres jeux bien sûr).
N'hésitez pas à poster vos questions, ou les techniques que vous connaissez, utilisez, etc..
Si vous pensez qu'il faut mieux organiser ce sujet, n'hésitez pas à poster, j'essaierai de le mettre à jour dès que possible.
1. Introduction au jeu online1.1. Les mécanismes généraux du onlineJe ne vais pas détailler, mais si vous le voulez et si vous le faites, je le rajouterai
.
Pour faire simple, on peut dire ceci :
- un jeu multijoueur est un jeu où plusieurs joueurs peuvent jouer ensemble, sur la même carte (ou room dans GM);
- actions : les actions des joueurs présents sur la room et des actions "générales" (création dun monstre par exemple) peuvent être vues des autres joueurs présents sur cette room. les joueurs peuvent aussi dans certains cas effectuer des actions les uns avec les autres (combats, commerce, message)
Fonctionnement global :
- le joueur dispose d'un exe "client", qu'il lance.
- il se connecte à un serveur pour jouer
- le serveur reçoit et envoie des informations aux joueurs concernés (même room par exemple : déplacement des autres joueurs, texte du tchat, ...)
- en règle générale, les informations sont stockées et gérées sur le serveur. Le client se contente d'afficher uniquement ce qu'il reçoit, et d'envoyer des évènements de type clic de souris ou keyboard_check au serveur qui sera chargé de les "interpréter" et de renvoyer, le cas échéant, le résultat aux autres joueurs concernés (sur la même map, dans le même groupe, proche d'un joueur ou d'un lieu, etc..).
Si vous voyez d'autres choses, n'hésitez pas
.
Je n'ai pas plus détaillé, car je pense que presque tout le monde connait les mécanismes d'un jeu multijoueurs.
1. 2. Game maker et le OnlineIl est possible de réaliser des jeux multijoueurs avec Game Maker.
Plusieurs techniques :
- en passant par mplay >voir le tutoriel du cbna :
http://www.lecbna.org/pages/tuto/Multi/Multi.html- en passant par une dll : 39dll ou soc.dll > voir les 2 tutoriaux du cbna (un peu plus bas)
Protocoles :
- sans trop détailler, on peut dire que GM propose plusieurs protocoles de connexions (IPX, TCP/IP, Modem, et Série). Dans la majorité des cas, on va passer par TCP/IP, mais bien entendu on fait ce qu'on veut.
Question :
- quelle est la dll la plus intéressante et le protocole à utiliser ? (vous pouvez détailler et donner des arguments objectifs)L'utilisation de 39dll est assez simple une fois que l'on a compris son fonctionnement global.
Pour cela, au moins 2 tutoriaux sont disponibles :
https://cbna.forumactif.com/t8131-tutoriel-39dll-jeux-multijoueurs-sur-internethttps://cbna.forumactif.com/t10078-tutoriel-39dll-en-detailsJe ne détaille pas beaucoup plus, car pour plus de détails, il suffit de bien lire et comprendre les 2 tutoriaux
.
Si vous avez des informations complémentaires, n'hésitez pas et je les rajouterai à cette partie.
1.3 enregistrement des donnéesIl existe plusieurs techniques pour sauvegarder les données du joueurs :
- fichier ini (ou texte) sauvegardés sur le serveur : tutoriel >
http://www.lecbna.org/pages/tuto/Ini_Tutorial/index.html- base de données sauvegardées sur le serveur (avec GMsql par exemple)
Si vous disposez d'un tutoriel pour Gmsql, n'hésitez pas à donner le lien (car personnellement, je n'y connais rien à ce niveau-là, et ça m'intéresse).
2. Mécanisme et réflexion sur le jeu onlineLà, je pense qu'il est utile de détailler.
Si vous avez des techniques ou des idées sur certains mécanismes,vous pouvez les poster dans un message.
2.1. ConnexionPour jouer à un jeu multi-joueur, il faut se connecter au serveur.
Avant cela, il faut s'enregistrer ou avoir un login/mot de pass.
2.2 Déplacement du joueurOn peut déplacer le joueur au clavier, ou à la souris, en lui indiquant où il doit se rendre.
Il vaut mieux de toute manière que le déplacement se fasse au niveau du serveur : on envoie les events clavier ou souris au seveur et il se charge de renvoyer le résultat aux clients chez qui ce la est nécessaire (par exemple, sur la même map et proche du joueur).
Cas particulier :
Intéressons-nous au cas de la 3D isométrique (moteur 2D, pas 3D, hein).
En général, on utilise un système de pathfinding.
Gm dispose de fonction pré-établies qui peuvent aider un peu à obtenir des résultats corrects :
- fonctions simple : move_toward_point()
- fonction plus compliquée, mais aussi beaucoup plus puissante : utiliser les ds_grid
[exemples à fournir et explication à continuer]
Envoi des données de déplacement vers le serveur :Existe-t-il une méthode plus performante, moins gourmande en ressource, etc ?
Exemple : maginons que le joueur A clique pour déplacer son personnage
- le joueur A envoie au serveur le clic de souris et la position (mouse_x, mouse_y)
- le serveur calcule le pathfinding (avec une ds_grid par exemple)
- le serveur renvoie aux joueurs concernés le résultat (joueurs présents sur la même map et à un endroit proche du joueur la case ou la position du clic du joueur A par exemple).
Vous connaissez une meilleure méthode ? N'hésitez pas à poster.On peut, je pense, généraliser cette méthode pour l'ensemble des données transférées du joueur A vers le serveur et du serveur vers les autres joueurs concernés (combat, apparition d'objet, etc..).
2.3 Apparition de mob, de créatures, ou d'objetLà, on peut envisager au moins 2 Cas de figures :
- tous les joueurs concernés doivent recevoir l'information (même map, même zone, etc..)
- seuls certains joueurs doivent recevoir l'information, même s'ils sont sur la map , les uns à coté des autres : cas particulier d'un pouvoir (voir certains objets), possibilité d'entrer dans une zone (clef), etc..
Cependant, la technique est à peu près la même que l'envoi des autres données, avec quelques évènements en plus.
Un exemple de plop de mob (apparition de créature) :
- game_start() : on crée un tableau de variable par rapport aux map (room), par exemple map_mob[7,1]=20.
C'est le nombre de mob de type "1" qu'on va créer sur la map "7". On sait qu'on aura toujours maximum 20 mobs de ce type sur cette map.
- on lance une alarme qui vérifie toutes les 2 minutes si le nombre est correct.
event alarm[0]
- Code:
-
if map_mob[7,1]<20
{
//creation du mob, avec les coordonnées et la map par exemple
};
alarm[0]=60*30/fps; //pour un fps réglé sur 30 par exemple, mais on met ce qu'on veut
Vous avez une autre idée, une meilleure méthode pour faire ce genre de chose ? Si oui, n'hésitez à donner vos idées
.
2.4 CombatLe combat est sans doute l'une des partie les plus délicate.
On peut évidemment gérer plusieurs types de combats :
- action
- tour par tour
- tactique
- mixe
- etc..
Imaginons un type de combat qui soit une sorte de mixe : un peu d'actions, un peu de tactique (poser des pièges par exemple), des concepts empruntés au tour par tour (avec des temps de recharge pour les sorts, des sorts qui nous "gèlent" (on ne peut plus bouger), etc..
La question que l'on peut se poser est la suivante :
- comment réaliser un combat en multijoueur qui prennent le moins d'envoi/réception de données possible.Une des solutions est celle que l'on a dans beaucoup de jeu de type tour par tour ou tactical :
- on crée une nouvelle map (de combat) et seuls les joueurs concernés y ont accès (équipe, guildes, groupes, ou autres donjons)
2.5 Apparition d'objets de type drople Drop est un objet qui apparait quand on a combattu un mob.
Pour ça, il y a plusieurs avis/solutions/méthodes.. :
- soit les objets apparaissent uniquement chez les joueurs (chaque objet récompense pour chaque joueur et les autres joueurs ne les voient pas)
- soit on fait apparaitre les objets pour tout le monde, même les autres joueurs.
- soit on les ajoute directement dans l'inventaire
- etc...
Mais la technique reste la même que la création des mobs, ou le déplacement des personnages :
- le serveur reçoit les données du /des joueurs lors du combat
- il renvoie les calculs qu'il a effectué (dégâts, vie enlevée..)
- à la fin, lorsque le mob n'a plus de vie, le serveur envoie un message qui supprime l'instance de l'obj mob
- puis il envoie aux joueurs concernés les drop/récompenses
- si le joueur clique par exemple à l'endroit où se trouvent les récompenses/objets> cela envoie à nouveau un message au serveur
- à ce moment le serveur envoie un autre message : suppression de l'obj drop
- le serveur sauvegarde la valeur de l'obj drop.
Tout ou presque est donc resté du coté du serveur, normalement.
Ainsi, cela évite et empêche toute triche.
Autres mécanismes à compléter :
- quêtes
- commerce
- trésor/clef - porte/clef..
- élevage
- métier : craft/plantation
- guilde
3. Ce qui est du coté du client (du online qui serait un peu offline)Il y a certaines informations qui ne sont envoyées qu'à un seul client :
- lorsqu'un joueur regarde un de ses menus : inventaire, compétence, xp..
- lorsqu'il effectue une quête : certains dialogues de quêtes (les solutions)
- commerce avec un marchand
- les changements de levels peuvent aussi être chez un joueur seul, aisni que d'autres informations du même genre.
Il y a d'autres informations qui sont même "offline", c'est à dire directement dans un dossier du client :
- certains textes explicatifs, informations : sans info sérieuses ou qui permettent de résoudre une quête par exemple
- les descriptions d'objets
- certains dialogues de quêtes (les bases)
Concernant les blocs collisions, je ne sais pas trop s'il vaut mieux qu'ils soient sur le serveur ou chez le client.
[à continuer]