Hello !
Après la demande de plusieurs membres du forum, je vais ici poster le développement du serveur de KNIGHT (pour ceux qui n'ont pas vue le projet: http://www.indiedb.com/games/fr-en-knight)

Le développement du serveur est déjà pas mal avancer, je vais donc essayer de vous faire un récapitulatif du développement actuel (en gros 3 jours de boulot)

Moteur de jeu: Unity 3D 5.3
Langage: C#
Moteur du serveur: Aucun, tout est fait maison
Librairie du serveur: .Net socket
Langage du serveur: C#

Le serveur est pour l'instant en 2 applications (non couplés)

1. Le serveur de jeu
2. Le serveur de position
3. (En prévision) Serveur de login

Voici ce qui c'est passé:
Serveur de jeu:

1. Recherche de la meilleur méthode de connexion sous C#
2. Choix de l'utilisation de Socket et début d'écriture du Serveur
3. Testes avec un Client pour la connexion et choix du port utilisé
4. Ajout d'une interface sur le jeu afin de permettre le login, la création de perso etc
5. Mise en place d'une Database sous MySql (et choix de la librairie MySql.Data pour le serveur)
6. Mise en place d'un stockage local sur le serveur
7. Ajout des features (connexion, creation de perso, sauvegarde des données (database + local)

Désolé si je ne fait pas de grande précision, sachant que je n'ai pas pris de screens (n'ayant pas eu de demande avant pour ça) je vous est fait un jolie dessin de comment fonctionne les serveurs

Voilà, donc maintenant je vais mettre les trucs que je fait au fur et a mesure sur le serveur (Essayant d'éviter des doubles postes, mais si personne ne parle ça voudrait dire que je ne peux plus rien mettre...)

Dite moi si vous voulez quelque chose de beaucoup plus technique

Que c'est beau un DevDiary sur le fofo
Ton image est sympa et permet effectivement de mieux comprendre le concept, perso j'ai pas trop de conseils à te donner parceque j'ai jamais fait de techno serveur ^^
(Attention aux fautes d'orthographes y'en a qui font mal au yeux )

Dite moi si vous voulez quelque chose de beaucoup plus technique

Perso comme je l'ai dit j'y connais trop rien en serveur donc le niveau de complexité actuel me conviens, mais si tu fais un truc bien expliqué ça peut être intéressant

Pour moi aller trop dans le technique sur les réseaux sera pas utile : soit on aura assez de connaissance en progra pour se débrouiller ailleurs comme tu l'as fait ; soit on aura plus besoin d'un tuto que d'un diary.

Du pseudo langage sur comment t'utilises les appels au socket pour un jeu ce serait cool par contre.

(repost )

Oui c'est ce que je vais faire vue vos avis ;)
Rester assez simple, pour quelqu'un sans forcément trop de connaissances

Pour les socket c'est le nom que ça porte en réseau, c'est le socket logique, en gros celui qui envois et reçois les données, je vois pas trop comment faire du pseudo code la dessus

Et voilà, la position est envoyer a la base de donnée en temps réel ;)
Là il va falloir que je check si la position est pas la même que l'ancienne, pour éviter les mises a jour de position inutiles

Un point concernant la securite : le client ne peut PAS dire "j'ai bouge, voila ma nouvelle position". Si la logique du client est modifiee (hack) ca peut donner n'importe quoi (je me teleporte, je vole, je marche a travers les murs, etc.)

La bonne facon de proceder est la suivante :

(t) client > je *veux* effectuer une action : un deplacement
(t+1) serveur > verifie que l'action est valide, resoud tous les conflits eventuels (precedence, collisions, etc.), met a jour l'etat du jeu
(t+2) serveur > propage le nouvel etat du jeu aux clients
(t+3) client > met a jour la simu locale en fonction de l'update du serveur

entre (t) et (t+3) le client doit effectuer de la prediction sur la simu locale, et a (t+3) appliquer un facteur correctif (avec une logique d'interpolation pour garder l'experience de continuite).
a (t+1) le serveur doit reconstruire les timelines respectives de paquets et events, pour savoir quel joueur a la precedence des actions, et pour savoir si les actions sont valides du point de vue du joueur au moment ou il en fait la demande (ex. un joueur se protege apres une attaque d'un autre, mais sa latence est plus importante, apres reconstruction les timings coincident et la parade est valide)

Pour un jeu temps reel comme ici, il faut cet ensemble de prediction/correction/reconstruction pour obtenir une experience de jeu correcte.

Oui, je suis bien d'accord, sauf que là c'est un serveur brute, il n'y a pas de simulation, donc pas de collisions, pas de map, rien de tout ça, donc a la limite pour éviter le hack je metterait un système de ticket crypter et puis voilà

EDIT: Et en plus de ça, la position est gérer par le client, étant donner que c'est lui qui a la simulation
Mais ce système n'est pas plus différent que le tien, les vieux mmorpg tel que FLYFF, utilisait ce système, c'est le client qui avait tout la simulation, le serveur uniquement la position pour la partager au autres joueurs (même pas au joueur même, seulement au autres), avec un système de ticket de validation, et voilà

Ce n'est pas le but du topic (avancement de ton projet) donc je ne vais pas m'etaler - des debats paralleles auront lieu si necessaires.

Si chaque client doit avoir une copie (partielle) de la simulation, pour la representation (partielle) du monde au joueur, toute modification de LA simulation ne peut etre geree que par une autorite unique.
Sans quoi on est necessairement confronte a des inconsistances notables ; au-dela de la "simple" securite, l'experience de jeu elle-meme devient incoherente (l'action d'un joueur n'a pas le resultat attendu de maniere deterministe).
Tu te retrouves egalement avec des dilemnes conceptuels - si chaque client gere ses donnees propres, a quel niveau place-t-on le code qui gere les interactions entre joueurs ? Etc.

Etant aux commencements, je ne peux que t'encourager a reconsiderer soit ton architecture soit les contraintes de ton projet de maniere a avoir une adequation entre les exigences gameplay et la solution technique proposee. Une infrasctucture non viable donne lieu a des situations non desirees qu'on ne peut pas corriger a posteriori (le cryptage par ex. n'apporte rien dans la mesure ou on ne peut "croire" les infos des clients) car la technique est fondamentalement "defectueuse" a la base.

Le multijoueur temps reel est une problematique connue ; les solutions aussi, et ne pas s'y conformer mene a des implementations non-viables (ce qui encore a l'heure actuelle force des projets a sacrifier leur composante multi car mal pensee en amont, e.g. Subnautica).

En dehors de ces reserves, bonne contination a toi !

Ne t'en fait pas, si j'ai pris la décision d'utiliser cette méthode ce n'est pas en vain
Cette méthode fonctionne bien, elle a été utiliser dans pas mal de mmo de l'époque, et fonctionne toujours a l'heure actuelle

Eh, je veux pas te faire peur mais on peut lire dans ton jeu comme dans un livre ouvert

Si je veux, avec un peu d'efforts , je peux même en faire un projet Visual Studio pour pouvoir compiler comme il me plait

Je suis une brêle en réseaux, mais l'encryption sert à rien, je peux très bien modifier le code afin d'envoyer ce qui me plait en utilisant ton encryptage

Oui, sous un décompiler en reflector tu peux pour l'instant
Mais ça, avec n'importe quel jeu unity, qui n'est pas encrypter
La je suis en dev, je vais pas vraiment me casser les fesses a ça, surtout que t'a beau envoyer ce qu'il te plait ça ne fonctionnera pas autrement que comme je l'ai dit, que ce soit si tu envois des requêtes sql ou autre sachant que le client ne peux pas en envoyer ...

Les seuls commandes que tu pourra envoyer c'est "connect", "disconnect", et "create_char", pour l'instant sans clé, donc si ça t'éclate de créer des dizaines de perso sachant que là tu peux, va y

C'est le serveur qui gère tout, le client il gère juste sa position (sans cryptage pour l'instant)

Donc merci de t'amuser a chercher les failles c'est très utile, mais celle ci je la savait déjà

Bah j'espère que t'as raison, je testerais vite fait ce qui est possible ou pas coté hack fait quand il y aura du online :'p

Quand j'aurais mis en place la sécurité serveur, il faudra obligatoirement une clé unique (reçu en connexion chiffré), et je mettrais en place un système d'anti cheat (TP etc) donc ça devrait allez,

Mais pour l'instant je m'occupe de la synchro, de l'updater (modification vers du tar.gz au lieu d'es fichier sources directe)

Flyff c'est pas le jeu où il n'y a que des hackers justement ?
C'est intéressant quand même, mais je suis d'accord avec LGV sur sa méthode, question de sécurité
Je vais suivre ça

Non justement ^^

A suivre alors

Ps: c'est trop cool de coder son propre serveur

Actuellement, je suis entrain de corriger l'updateur (et le réécrit partiellement)

En fait, maintenant les fichiers sont upload en plusieurs parties (de 10 MO maximum chacune), et donc je doit les merges en arrivant et télécharger toutes les parties avant de merge le fichier final automatiquement via l'updateur

Ce qui fait que la vitesse de téléchargement est améliorée, et que mon FTP ne supprime pas tout seul les fichiers de plus de 10 mo

En plus j'ai réduit la taille de toutes les textures a 256 (sauf cas spéciaux), pour réduire les fichiers de resources de +300 mo a -90 mo

Voilà, l'updateur est fini, il va donc télécharger les fichiers par tranche de 10mo, ensuite les merge pour avoir le fichier final

J'ai aussi commencer a bosser sur l'anticheat

Mais avec le système d'LGV tu n'a même pas besoin d'anticheat non ? C'est en quelque sorte intégré au système. Donc au final en utilisant ton système à toi tu te rajoute du boulot parce que tu dois en plus développer un anti cheat

Si son système (utiliser par la plupart des jeux) ne permettais pas de cheaté, comment tu explique qu'il y a autant de cheater dans les jeux ? Comment tu explique que par exemple GTA (qui utilise ce système) a autant de mecs qui ce téléportent ?
Et pourquoi il doivent justement développé des anti cheat pour contrer ça ?

Parce que ce système est cheatable ni plus ni moins, perso dans les vieux mmorpg utilisant ce système, j'ai jamais vue personne ce téléporter