Discussion :

[Fraggy]

J'ai du mal à voir comment tu peux t'assurer de la non modification du client en cryptant. Tu peux détailler ?

tu assures la non modification du client en signant, pas en cryptant. Le cryptage permet d'eviter le hacking a la volée.

Par contre, je ne comprend pas pourquoi tu dis qu'elles explosaient 'en retard'. Parles-tu du feedback visuel dans le jeu (question ouverte: je ne connais pas le jeu) ?
Parce que logiquement (si c'est une grenade à explosion à T+x secondes après l'avoir lancée, x constant) le client peut déterminer dès le lancer de la grenade à quelle date exacte l'explosion doit avoir lieu, et jouer l'animation d'explosion au bon moment, quitte a ne répercuter les 'morts' et pertes de points de vie qu'après. Ce que fait Counter Strike par exemple.

tu connais quand, mais tu ne sais pas ou elle explose et ou se trouve les cibles...

Tout dépend si ton stream réseau est fiable ou non: s'il n'est pas fiable (UDP), tu es obligé d'envoyer des valeurs absolues ;

mais ca marchera pas via internet. les moteurs reseau moderne sont en tcp.

s'il est fiable (TCP), là tu peux te permettre de n'envoyer que des deltas. De toute façon, envoyer une trame de quelques vecteurs une vingtaine de fois par seconde reste largement en dessous des capacités des lignes actuelles. C'était surtout vrai du temps du modem RTC 56k.

le goulet d'etranglement ce n'est pas seulement un pb reseau, mais plutot la combinaison de la gestion lag compensation au niveau serveur, au niveau client et le reseau.
La gestion du lag en lui même génère pas mal de traffic (je te dis ce que je fais, je te valide ce que tu fais, je dis au autre ce que tu fais, il me valide qu'ils ont compris) la plupart de ces traffics servent aussi a se premunir des hackers...

[Mat.M]

Prenons l'exemple d'un petit jeu de voitures arcade genre micro-machines

Je l'ai testé merci pour le lien c'est bien fait mais on sort du circuit trop facilement il n'ya pas de détection de collisions avec les bornes qui bordent le circuit
si c'était le cas donc un algo de collision plus perfectionné il y aurait peut-être plus de latences réseau
En tout cas cela m'a donné l'idée de faire ce genre de jeu.

[deadalnix]

tu assures la non modification du client en signant, pas en cryptant. Le cryptage permet d'eviter le hacking a la volée.

Ça n'est en aucun cas une garantie de sécurité.

[IrmatDen]

mais ca marchera pas via internet. les moteurs reseau moderne sont en tcp.

Pardon ? Tu devrais préciser de quels catégories de jeux tu parles parce que dans l'absolu c'est faux.

Edit: pour exemple (tu penses peut-être que les moteurs réseaux employés par Valve dans TF2 ou même L4D date un peu trop...), Dawn Of War 2 utilise de l'UDP.

[nouknouk]

Je l'ai testé merci pour le lien c'est bien fait mais on sort du circuit trop facilement il n'ya pas de détection de collisions avec les bornes qui bordent le circuit

Effectivement, le jeu en lui-même est largement perfectible, et n'est même pas en résau. Mon lien n'était juste là que poru donner un concept de jeu, pour parler de la même chose. Si tu veux un 'vrai' jeu de petites voitures en réseau, regarde du côté de turbo sliders.

si c'était le cas donc un algo de collision plus perfectionné il y aurait peut-être plus de latences réseau

Etant donné que les tests de collisions performants fonctionnaient très bien sur Amstrad CPC (proc. Z80 à 4MHz) il y a vingt ans, ça laisse de la marge

En tout cas cela m'a donné l'idée de faire ce genre de jeu.

Ho, pique pas mon idée, toi hein

mais ca marchera pas via internet. les moteurs reseau moderne sont en tcp.

Non, pour les jeux à très fortes contraintes temps réel (FPS notamment), l'UDP reste la seule alternative. Et ça passe très bien sur le net, même de plus en plus souvent derrière un NAT sans configuration spécifique (cf. ce post).

La gestion du lag en lui même génère pas mal de traffic (je te dis ce que je fais, je te valide ce que tu fais, je dis au autre ce que tu fais, il me valide qu'ils ont compris) la plupart de ces traffics servent aussi a se premunir des hackers...

Non: le serveur:
- dis ce que font les autres et (trèèès) rarement corrige ce que j'ai fait moi-même
- pas de validation pour 99% du traffic (sauf les événements importants, cf. la perte de vie, la mort, ...).
- la lutte contre le hacking se fait via des algo, pas en multipliant le traffic réseau.
Pour t'en convaincre, regarde du côté du moteur Valve Source (Counter Strike Source, ...) et teste par toi-même pour voir combien de bande passante une partie occupe.

tu assures la non modification du client en signant, pas en cryptant. Le cryptage permet d'eviter le hacking a la volée.

+1 avec deadalnix: le chiffrement (et non pas 'cryptage' vu que tu sembles à cheval sur les termes) ne garantira jamais que ton programme n'est pas hacké où que tu as des soucis de 'man in the middle'. Sinon pourquoi les hacks persistent sur des jeux comme CS source, malgré des techniques avancées de protection ? La protection absolue n'existe pas.

[Fraggy]

Ça n'est en aucun cas une garantie de sécurité.

on est d'accord y a des solutions antitriche professionnelle qui peuvent aider (a gagner du temps de dev)

[Fraggy]

Pardon ? Tu devrais préciser de quels catégories de jeux tu parles parce que dans l'absolu c'est faux.
Edit: pour exemple (tu penses peut-être que les moteurs réseaux employés par Valve dans TF2 ou même L4D date un peu trop...), Dawn Of War 2 utilise de l'UDP.

ne jamais dire TOUS les jeux...
:p

[deadalnix]

Et même. Le plus pars des jeux sont en UDP. Et ce depuis des années.

[Fraggy]

J'avoue que je m'interessais plutot au jeu type MMORPG, c'est l'impression qu'on a retiré quand on a regardé l'existant pour le developpement d'un de nos projets

et au final, on a decidé d'utiliser... un system multicast (et donc UDP) j'ai décidément parler trop vite.

on a du mettre en place un systeme de recuperation de paquet, le protocole UDP étant un poil dangereux.

Vincent:p, ok je me tais.

[IrmatDen]

ok je me tais.

Pas forcément non plus, tout le monde peut se tromper faut juste s'assurer de ce que tu écris si tu as le moindre doute.

[Fraggy]

Pas forcément non plus, tout le monde peut se tromper faut juste s'assurer de ce que tu écris si tu as le moindre doute.

j'aurais du verifier :
UDP: Everquest, City of Heroes, Star Wars Galaxies, Ultima Online, Asheron’s Call, Final Fantasy XI
TCP: World of Warcraft, Lineage I/II, Guild Wars, Ragnarok Online, Anarchy Online, Mabinogi, Age of Conan
TCP + UDP: Dark Age of Camelot (and I’m going to assume Warhammer Online as well, due to being the same engine and company.).

voir ce lien : http://gafferongames.com/networking-...rs/udp-vs-tcp/

donc mon TOUS etait bien de trop.

[nouknouk]

A noter également que pour les consoles de jeux (Wii, PS3, Xbox 360), il me semblait que tout fonctionnait très bien sans avoir à rediriger de port. Je me demandais alors is par hasard ils faisaient systématiquement tout passer par du TCP.

En fait, après quelques recherches, il s'avère qu'elles sont capables de gérer les différents cas en fonction de la configuration réseau du client:

- soit l'UDP passe dans les deux sens et dans ce cas la console utilise ce mode (la XBox appelle ça le mode 'ouvert')

- soit l'UDP ne passe pas en flux sortant et/ou entrant et dans ce cas la console utilise uniquement du TCP, voire un mix des deux (UDP sortant, TCP entrant). Ca correspond aux modes dits 'modérés' et 'strict' sur la XBox 360.
Dans le deuxième cas, le gameplay est alors dégradé, le téléchargement de démos est plus lent (utilisation de P2P ?) et on 'voit' moins de parties d'après les retours des utilisateurs.

[nouknouk]

voir ce lien : http://gafferongames.com/networking-...rs/udp-vs-tcp/

Attention à cet article: certains raccourcis qui y sont faits peuvent induire le lecteur en erreur. Il faut bien prendre le temps de lire l'ensemble des commentaires qui lui sont associé et qui apportent des points de critique constructive. Deux exemples:

- le titre d'un paragraphe qui annonce bien en évidence "Why you should never use TCP to network a multiplayer game": C'est vrai dans le contexte d'un FPS mais quasi totalement faux pour des jeux un poil moins exigeants en 'temps réel' (du jeu en tour par tour au tetrinet, voire même un RTS ou un MMORPG). L'auteur explique qu'il parle uniquement des FPS dans une réponse à un commentaire, mais rien n'est mentionné dans l'article.

- le paragraphe "Wait? Why can’t I use both UDP and TCP?" est également erroné: Il se base sur un étude de l'influence qu'ont des flux TCP sur de la perte de paquet d'un flux UDP qui fonctionne en même temps. Or cette étude prend comme hypothèse qu'on a des flux TCP qui vont utiliser le maximum de la bande passante disponible. Entre temps (le papier semble dater de 1997, l'époque du modem 56k et celle où une ligne T1 était réservée à l'élite et aux entreprises), les choses ont bien changé: la bande passante du lien vers le net a explosé avec l'avènement de l'ADSL tandis que le besoin en bande passante pour un jeu n'a pas évolué et n'excède pas quelques dizaines de kbits/sec. On tombe alors très rarement sur ce cas de figure en pratique (ie. la saturation du lien).

[IrmatDen]

L'auteur explique qu'il parle uniquement des FPS dans une réponse à un commentaire, mais rien n'est mentionné dans l'article.

Si si
3ème paragraphe:

The choice you make depends entirely on what sort of game you want to network. So from this point on, and for the rest of this article series, I’m going to assume you want to network an action game. You know games like Halo, Battlefield 1942, Quake, Unreal, CounterStrke, Team Fortress and so on.

[nouknouk]

Si si
3ème paragraphe:

Arf, j'avais mal interprété la notion d"action game" qu'il faut entendre ici comme "FPS". C'est effectivement logique après examen de la liste d'exemples qu'il donne. Pour moi la notion d"action game" (lue un peu trop vite) regroupait plus que la simple catégorie des FPS.

Mes plus plates excuses

(EDIT) IrmatDen: encore levé à cette heure-ci ?!

[Fraggy]

(le papier semble dater de 1997, l'époque du modem 56k et celle où une ligne T1 était réservée à l'élite et aux entreprises)

le premier commentaire date d'octobre 2008, comment tu sais que le papier a été écrit en 97 ?

[nouknouk]

le premier commentaire date d'octobre 2008, comment tu sais que le papier a été écrit en 97 ?

Je ne parle pas de l'article en entier qui lui semble effectivement écrit en 2008.

Je parle de la publication référencée dans le paragraphe "Wait? Why can’t I use both UDP and TCP?" et sur lequel est basé l'argumentaire de ce paragraphe en particulier. Les propriété de la page indiquent une dernière modification en juin 1997 et aucune des références ne date d'après 1996.

[Mat.M]

Ho, pique pas mon idée, toi hein

hum tu veux faire un jeu de course multijoueurs en réseau alors
on a hate de voir cela

[nouknouk]

hum tu veux faire un jeu de course multijoueurs en réseau alors
on a hate de voir cela

[my life]

Ben l'idée n'était pas vraiment de moi en fait: le point de départ était juste une question d'un ami à propos des techniques de compensation de lag pour justement faire un petit jeu de voitures en ligne.
N'y connaissant à priori pas grand chose (j'ai plus d'expérience pour les problématiques réseau avec moins de contraintes temps réel), j'ai commencé à me documenter, pour lui répondre (et aussi pour ma culture générale de geek ).

Entre temps son projet est tombé dans l'oubli.

Mais c'est vrai qu'à force de lire des articles sur ce genre de problématiques que je trouve personnellement super intéressantes, ça risque de me donner envie de me confronter à la réalité du développement d'un petit proof-of-concept rapide à faire, dans ce style (jeu 2D 'simple à développer', genre micromachines, bomberman online, ...)

[/my life]

[Davidlouiz]

J'avais pensé à une astuce qui ne devrait pas être très difficile à mettre en oeuvre.

L'idée est la suivante.

Lorsque le joueur appuie sur la touche "avancer", il envois un message au serveur puis fait avancer le personnage côté client à une vitesse faible. Lorsque le serveur reçois le message, il informe le client par message du départ du personnage à vitesse constante. Lorsque le client reçois le message, il en déduit l'heure à laquelle il doit arriver au point de synchronisation avant de poursuivre à vitesse normale.



Pouvez-vous me dire si l'astuce tiens la route et si elle a déjà été implémenté dans un FPS ?

Merci.