[Scrooge McDuck]

Citation :

Publié par Epic

...

Ce post est fidèle à ton pseudo

[Dif']

Concernant Andrew Meggs, je viens de tomber sur son site perso.

[Electre]

[Message édité par Agahnon.]

En effet le nombre de polygone n' a rien à voir avec la charge réseau, vu que via le réseau on envoit uniquement les coordonnée et l'identifiant de l'objet à afficher.

La il font une démo d'un client sans serveur. En gros ils nous montrent que sur un décort vide, avec des personnage qui ne font que bouger lentement, donc pas d'action hyper rapide PVP, et avec des mouvement scripté, c'est à dire que le serveur n' a pas à géré les commandes des joueurs derrière les personnage, leur truc ne RAME pas.

On va dire que c'est un premier pas, mais c'est grandement insuffisant.

Il faut pouvoir afficher les décort, les texture, des personnage en pleine action et pas seulement des personnages qui marchent. La on parle de RAMER ou pas RAMER. C'est lié à la qualité du moteur et à la puissance du PC client. Sont ils capable de faire un compromis entre ressources nécessaires et performance du moteur ? Mystère, c'est clairement pas sur ces vidéos qu'on peut le voir.

Après par dessus il y a tout l'aspect client-serveur qui lui peut faire "laggué" si l'aspect réseau est mal géré, la dessus ils sont à 0.

Et après il y a l'aspect serveur, même si il n' a aucun graphismes à gérer il peut facilement RAMER si c 'est mal fichu ou insuffisant pour la "charge" demandée.

Bref avec leur vidéo ils n'ont même pas 1/10 eme des traitements à faire pour affiché leur jeu.

C'est bien que ça rame pas maintenant, mais c'est clairement complètement insuffisant pour se faire une idée sur les qualités du jeu.

Leur vidéo c'est comme si ils nous avaient rien montré. Pour l'instant tout leur blabla ça reste des promesses.

[gRegz-]

Pour rejoindre Electre, je m’interroge sur un point, comment gérer la partie réseau.
J'imagine qu'ils doivent, comme pour tout autre jeux, envoyer plusieurs informations, typiquement tout ce qui doit être affichable par un joueur :

- Position de chaque joueurs.
- Mouvement/Action en cours pour chaque joueurs.
- Vie de chaque joueurs.
- Effet sur chaque joueurs (mezz etc...)

Bref, comment font les autres jeux ?
C'est surtout le nombre qui me fait flipper, imaginons qu'on ait 10K personnes sur le serveur, j'imagine que chaque client n'a pas connaissance de chaque joueurs et que toutes les informations pour les 10K joueurs ne sont pas à chaque instant envoyé à chaque client, le serveur peut très bien envoyé la position de tout les joueurs étant "assez proche" du client. On peut très bien imaginer un découpage logique sur le serveur, on chaque client appartient à une zone et uniquement la position de ces joueurs dans la zone est envoyée.
Bref, passons, si on à 1000 personnages à l'écran et qu'il faut envoyer toute cette informations sans lag, est-ce faisable ? Des jeux le font ? La limitation du réseau tu peux juste rien faire, si y'a trop d'informations, ça lag point barre. Non?

[Electre]

Ca marche un peu comme tu le dis, Les développeurs de WoW avaient un peu approfondit la chose lors de la sortie de WOLK avec le DK.

Ils ont expliquées que de rajouter un buff ou un debuff d'un type différent ça générait une charge réseau monstrueuse car il fallait envoyé l'état du buff/debuff à chacun des joueurs pour chacun des joueurs. C'est des math combinatoire pour trouver le nombre de possibilité, et ça augmente très très vite avec le nombre de joueur. Ca n'augmente pas de façon linéaire. Ils avaient poster les calculs de charges réseaux supplémentaire pour un seul buff/debuff supplémentaire en fonction du nombre de joueurs impactés. Et ils expliquaient que c'étaient très très facile de saturer la capacité de traitement du serveur.

[Scrooge McDuck]

Il y a eu une explication concernant les pbae et les ae de Warhammer par MJ ou Andrew aussi, et il expliquait comment ils allaient travailler sur CU pour rendre le système plus simple et éviter les multiples emmerdes qu'ils avaient eues avec War avec ça

Idem concernant les buff: MJ en a gardé un très mauvais souvenir concernant la gestion réseau du bordel que ça engendrait sur Daoc

[Dif']

Citation :

Publié par Ezorra

Je suis dans le développement aussi, et je peux vous dire, que ce qui ne sera pas du contenu de masse (à savoir RvR et autre) ça va quand même paraître super sale. Oui leur test de charge est convaincant, mais il y a ni ombre, ni animations différentes, ni animations complexes.

Concernant les ombres et les lumières, c'est typiquement le genre de chose que tu peux te permettre ne pas avoir de façon complètement dynamique sans que ce soit trop visible.

Pour ce qui est de l'animation, Andrew a parlé d'utiliser des computes shader pour faire le gros du travail sur la carte graphique.

Citation :

Publié par Ezorra

Je comprends bien qu'on doive sacrifier le nombre de polygônes et les textures pour rendre le jeu fluide avec de nombreux modèles présents à l'écran. Mais à ce niveau c'est vraiment abuser (ce n'est que mon avis après) on a des animations et des particules qui datent des premiers shaders 2.0, c'est vraiment décevant...

Il faut plutôt voir les démos actuelles comme des proof of concept. Les assets sont des placeholders et le code doit être assez spécifique à la démo je pense.

Citation :

Publié par Terckan

Merci pour les vidéos. Je n'avais pas pu voir la deuxième partie de la présentation du moteur hier soir. En effet ils ont rencontré un sacré bug durant le live et le stream est passé off pendant un bout de temps.

Je crois que le problème c'est que l'ordi portable de Andrew surchauffe et du coup il a du attendre d'être revenu à une température correct pour relancer le tout.

Citation :

Publié par Hellraise

Les persos sont a 12000 polygones, selon la distance le moteur peut n'en afficher que 1000, mais de près on voit bien 12k polygones ce qui est pas mal du tout.

Afficher 12k ou 1k poly pour un perso qui est très éloigné sur la scène c'est du pareil au même pour le rendu visuel, par contre c'est beaucoup plus performant dans le deuxième cas.

Pour les 12k polygones, si on veut donner un exemple, les personnages de Guild Wars 2 doivent être un peu près dans la même fourchette. (De mémoire hein, si quelqu'un à des chiffres plus précis).

Concernant la partie réseau, je suppose que le serveur envoie l'état du jeu à tout les clients toutes les X millisecondes. Le client va calculer la scène dans le passée avec les infos qu'il reçoit du serveur un poil en retard à cause du transfert.

Au niveau du client, il va aussi y avoir des prédictions. Quand un joueur bouge ou lance un sort, le client va calculer directement les prochaines images en prenant en compte ces modifications (pour éviter d'avoir une impression de lag) en même temps qu'il envoie les données au serveur. Le serveur va donc lui aussi calculer de son côté avec les infos de tout le monde avant de répondre . Une fois la réponse arrivé chez le client, ce dernier transite de façon "régulière" de ce qu'il avait calculé vers ce qu'il a reçu.

Tout cela n'est pas gratuit au niveau charge sur le processeur, c'est pourquoi Andrew tentes de mettre le maximum de calcul sur la carte graphique pour libérer du temps CPU pour le réseau.

Pour le serveur, il doit aussi garder les différentes positions des personnages en mémoire sur un cour laps de temps (par exemple une seconde) pour pouvoir vérifier que tel ou tel coup à bien touché quand il reçoit les données des joueurs qui peuvent avoir mis du temps à arriver.

Après oui ça veut dire que pour faire de la prédiction, le client doit être au courant de l'état des perso, des buffs, etc. Après jusque là ils ont pas été avares en commentaire quand on leur pose directement des questions techniques (sur reddit par exemple) donc je serais pas étonné d'avoir plus de détails à ce sujet quand ils feront la démo avec le network intégré.

Concernant les sorts à zone d'effet, une bonne structure de donnée aide à beaucoup réduire le nombre de calcul nécessaire. Si tu fait tir la liste des joueurs en fonction de leur position dans l'espace, tu peux très vite éliminer des calculs les joueurs trop éloignés.

[Mescalito le retour]

Pourquoi Andrew dit qu'il n'y a pas de shaders alors qu'il y a du bump mapping et surement du phong?
Le rendu de feu est probablement un shader appliqué sur des particules d’ailleurs :/

[yuna et moi]

Les collisions seront gérées!!!

La preuve dans cette dernière démonstration du moteur du jeu!
c'est très prometteur! le nombre de "joueurs" n'est pas affiché mais semble plutôt élevé!


http://www.youtube.com/watch?v=Qqx9IgBqc3Y

Spoiler : Cliquez ce bouton ou survolez le contenu pour afficher le spoiler

C'est, de loin, mon meilleur post sur JOL depuis trèèèèès longtemps! ^^ (désolé! ce sont les nerfs qui lachent!)

[Jion]

Citation :

Publié par yuna et moi

Les collisions seront gérées!!!

lol

De toute façon, les collisions seront obligatoirement gérés comme pour tous les jeux. Maintenant reste à voir si cela prendra en compte la partie "Joueur vs Joueur".