Willikus Ecris:

Donc pour éviter la surcharge du serveur, il y a interet a repartir plusieurs serveurs, performant pour les flux rapide (combat, deplacement) et plus lent pour l'inventaire et le stockage d'info divers ?
Ya t'il possibilité qu'un client active plusieurs serveurs selon désire ?

techniquement c'est possible, en pratique c'est extremement compliqué, ca constitue un projet rien que de concevoir une telle architecture, (les systèmes répartis sont mon domaine en fait) tu as des problèmes de synchronisation, de cohérence, etc ..

Willikus Ecris:

Ensuite, dans un FPS (mon choix), une balle = forcément 1 paquets.
Etant données que si on file 1 coup d'epee, 1 seul dégat doit etres comptabilisé...

ah nontu peux encapsuler tes informations dans 1 meme paquet, sans avoir a les générer de facon directement indépendante, l'idée, c'est que tu va envoyer souvent des information de position par exemple, et quand tu va tirer/frapper, tu ajoute ou rempli un champ a ton paquet, tu n'en génére pas un en plus, ce que je veux expliquer, c'est qu'il faut tout envoyer dans le meme pas paquet,


C'est a dire que tu va avoir 1 frame par seconde graphique, un frame par seconde dans le coeur de ton appli, et un frame par seconde de mise a jour réseau, (les 3 sont indépendants dans mon idée de la conception)
apres, tu peut toujours faire de l'interpolation pour mieux gérer les transitions, mais ca a ses limites

Willikus Ecris:

Pour finir, "30 personnes font laguer", qu'en est t'il des serveurs Ennemy Territory qui gère 32 (voir 64) personnes au dégat, balles par balles avec un multitude d'action compliqué (médic, ingénieur, ...) ?

Ennemy territory c'est un MMORPG ? les perfs sont un peu meilleures pour les jeux FPS, et les serveurs sont monstrueux
les actions compliqués n'ont pas de vrai influence sur la charge du traffic réseau,
Mais je persiste dans mon analyse, tant que l'industrie restera sur les modeles actuels de client-serveur, ont aura des performances tout juste passables

Willikus Ecris:

Merci tout de même pour "tu ne concoit pas ton application autour du réseau, mais tu choisi les structures de données que tu va partager"
Qui fait que je vais poursuivre ma programmation du jeu

ce que je veux dire c'est : crée ton application, et voit le données que tu partage entre deux joueurs, ca implique bien sur que ta conception facilite la récupération/la réception cohérentes de ces données, (faut pas que ya des bouts de données partout a charger/mettre a jour)

Willikus Ecris:

Donc pour éviter la surcharge du serveur, il y a interet a repartir plusieurs serveurs, performant pour les flux rapide (combat, deplacement) et plus lent pour l'inventaire et le stockage d'info divers ?
Ya t'il possibilité qu'un client active plusieurs serveurs selon désire ?

techniquement c'est possible, en pratique c'est extremement compliqué, ca constitue un projet rien que de concevoir une telle architecture, (les systèmes répartis sont mon domaine en fait) tu as des problèmes de synchronisation, de cohérence, etc ..

Willikus Ecris:

Ensuite, dans un FPS (mon choix), une balle = forcément 1 paquets.
Etant données que si on file 1 coup d'epee, 1 seul dégat doit etres comptabilisé...

ah nontu peux encapsuler tes informations dans 1 meme paquet, sans avoir a les générer de facon directement indépendante, l'idée, c'est que tu va envoyer souvent des information de position par exemple, et quand tu va tirer/frapper, tu ajoute ou rempli un champ a ton paquet, tu n'en génére pas un en plus, ce que je veux expliquer, c'est qu'il faut tout envoyer dans le meme pas paquet,


C'est a dire que tu va avoir 1 frame par seconde graphique, un frame par seconde dans le coeur de ton appli, et un frame par seconde de mise a jour réseau, (les 3 sont indépendants dans mon idée de la conception)
apres, tu peut toujours faire de l'interpolation pour mieux gérer les transitions, mais ca a ses limites

Willikus Ecris:

Pour finir, "30 personnes font laguer", qu'en est t'il des serveurs Ennemy Territory qui gère 32 (voir 64) personnes au dégat, balles par balles avec un multitude d'action compliqué (médic, ingénieur, ...) ?

Ennemy territory c'est un MMORPG ? les perfs sont un peu meilleures pour les jeux FPS, et les serveurs sont monstrueux
les actions compliqués n'ont pas de vrai influence sur la charge du traffic réseau,
Mais je persiste dans mon analyse, tant que l'industrie restera sur les modeles actuels de client-serveur, ont aura des performances tout juste passables

Willikus Ecris:

Merci tout de même pour "tu ne concoit pas ton application autour du réseau, mais tu choisi les structures de données que tu va partager"
Qui fait que je vais poursuivre ma programmation du jeu

ce que je veux dire c'est : crée ton application, et voit le données que tu partage entre deux joueurs, ca implique bien sur que ta conception facilite la récupération/la réception cohérentes de ces données, (faut pas que ya des bouts de données partout a charger/mettre a jour)