Etudier de près le source code "physic across network" dans les sources en base de cette page. http://www.gaffer.org/articles/
Le code contient tout : "proxy, historique, client side prédication, important moves, serveur de simulation avec perte et lag, etc..."
(l'auteur est celui qui a codé la physique et du réseau dans "Tribes")
- Pas de robustesse de protocole. pas de sequencement. juste un timestamp par paquet, qui permet de décider ce que l'on en fait au niveau du jeu.
- position chassis/roues + quaternion chassis plus roues (roues peut-etre en option et simulé du coté client très simplement). Vitesse et autres données physique si "client side prédiction"
- UDP (une très bonne librairies UDP est ENET utilisé dans cube, sauerbraten) Attention au pièges des librairies (opentnl, hawkNL raknet, etc..). A part gérer les sockets et les threads elle ne sont pas forcement d'une grande aide, notemment pour le lag.
- format binaire, voire compressé. (lzma) Chaque octets conmpte. (pas tellement pour la bande passante, c'est plus pour la surcharge du serveur et/ou la vitesse de traitement des paquets (au niveau OS))
- Chaque envoir "input + dernier changements d'input" + timestamp ("important move") c'est contre les pertes de paquets. (tres frequent sur internet)
- client side predication => il faut pouvoir retourner dans le passer et recommencer à partir de la première divergence avec le serveur. (pour le Lag)
- 20-25Hz maximum pour les envoi réseau depuis le serveur.
- Avoir un serveur de simulation pour les test (qui permet %perte de paquets, lag en ms. le source listé au-dessus a ca aussi.) et qui permet de differencier les erreurs de protocole, socket, os, des erreurs de design.
- Du LOD sur le réseau. N'envoyer les position+quaternions que des voitures dans un champ rapproché limité (plus que la vision). Les autres seront justes un X,Y sur une map 2D de l'utlisateur qui peut se coder sur 16bits.
- plusieurs type de paquet des lents () et des rapides (score, nouveau client, joueurs hors du champ rapproché, etc...). utiliser TCP pour les lents est une option
- si client side prediction, beaucoup de boulot pour etre sur que les résultats seront les memes sur tous les ordis (ne pas oublier un appel à "srand()" par exemple). La mailing liste ODE a des archives complete sur ce sujet.
- Pour le NAT voir la libNAT de john Wattte (le meme que sur la liste ode) et surtout toujours utiliser le meme port.
- Reserver l'ajout des threads après le codage complet du client et serveur (pour debogger tranquille), ou mieux pouvoir le désactiver facilement (#define). les threads sont utiles dès que le nombre de clients devient important (>4) mais rende le deboggage bien plus complexe.
-etc..
# C'est le probleme le plus complexe...
Posté par tuan kuranes (site web personnel) . En réponse au journal Rendre un jeu jouable en réseau. Évalué à 10.
http://www.gaffer.org/articles/
Le code contient tout : "proxy, historique, client side prédication, important moves, serveur de simulation avec perte et lag, etc..."
(l'auteur est celui qui a codé la physique et du réseau dans "Tribes")
Si tu es anglophone, il faut lire absolument tout ces articles :
http://www.ogre3d.org/wiki/index.php/External_Links#Articles
(Sinon ca va vraiment être dur)
Sinon, en gros:
- Pas de robustesse de protocole. pas de sequencement. juste un timestamp par paquet, qui permet de décider ce que l'on en fait au niveau du jeu.
- position chassis/roues + quaternion chassis plus roues (roues peut-etre en option et simulé du coté client très simplement). Vitesse et autres données physique si "client side prédiction"
- UDP (une très bonne librairies UDP est ENET utilisé dans cube, sauerbraten) Attention au pièges des librairies (opentnl, hawkNL raknet, etc..). A part gérer les sockets et les threads elle ne sont pas forcement d'une grande aide, notemment pour le lag.
- format binaire, voire compressé. (lzma) Chaque octets conmpte. (pas tellement pour la bande passante, c'est plus pour la surcharge du serveur et/ou la vitesse de traitement des paquets (au niveau OS))
- Chaque envoir "input + dernier changements d'input" + timestamp ("important move") c'est contre les pertes de paquets. (tres frequent sur internet)
- client side predication => il faut pouvoir retourner dans le passer et recommencer à partir de la première divergence avec le serveur. (pour le Lag)
- 20-25Hz maximum pour les envoi réseau depuis le serveur.
- Avoir un serveur de simulation pour les test (qui permet %perte de paquets, lag en ms. le source listé au-dessus a ca aussi.) et qui permet de differencier les erreurs de protocole, socket, os, des erreurs de design.
- Du LOD sur le réseau. N'envoyer les position+quaternions que des voitures dans un champ rapproché limité (plus que la vision). Les autres seront justes un X,Y sur une map 2D de l'utlisateur qui peut se coder sur 16bits.
- plusieurs type de paquet des lents () et des rapides (score, nouveau client, joueurs hors du champ rapproché, etc...). utiliser TCP pour les lents est une option
- si client side prediction, beaucoup de boulot pour etre sur que les résultats seront les memes sur tous les ordis (ne pas oublier un appel à "srand()" par exemple). La mailing liste ODE a des archives complete sur ce sujet.
- Pour le NAT voir la libNAT de john Wattte (le meme que sur la liste ode) et surtout toujours utiliser le meme port.
- Reserver l'ajout des threads après le codage complet du client et serveur (pour debogger tranquille), ou mieux pouvoir le désactiver facilement (#define). les threads sont utiles dès que le nombre de clients devient important (>4) mais rende le deboggage bien plus complexe.
-etc..