Battlefield 4 [PART 2]

Si t’es retenu :wink:

Ouvre un post sur le forum de EA. Même si c’est un peu pisser dans un violons, ça fera encore un poste de plus qui montre que le jeu n’est toujours pas fonctionnel.

Je suspècte qu’en fait le bug du son n’a jamais été réglé et qu’il était déjà la sous bf3. Du coup ce qu’ils ont fait c’est qu’ils ont du forcer un rechargement du son genre 30 secondes après le début du round.

Chez moi au début du round, j’ai ni son et tous les modèles sont en low.

Faut aller whine sur le forum les mecs sérieusement.

A chaque news de leur part il y a toujours la masse de “fix the game” mais il y a de plus en plus de teubés qui disent que tout va bien ( car juste tout va bien à peut prêts chez eux ). Mais ont est encore beaucoup à avoir des couilles sur le jeu.

[quote="[sz]gazton"]bien content de ne pas l’avoir acheté mais bien frustrant de n’avoir aucune fps multi à se mettre sous la dent :frown:
[/quote]

Me suis remis à left 4 dead 2, bf4 me sort par les yeux. Si tu le possède rajoute moi dans steam, ce jeu est vraiment génial. Et franchement il est vraiment, vraiment beau. Limite quand je retourne sur bf4 même en ultra je le trouve moche.

L4D2 vraiment beau… faut pas pousser le bouchon trop loin. Il est même en deçà de HL² + CM :ane:

titan mode confirmé pour un des DLC. Pas que cela soit réellement intéressant en ce qui me concerne car avec ces problèmes de lag faut pas trop que DICE s’attende à voir mes thunes pour les acheter :slight_smile:

je me suis inscrit à la Beta. :jap: et la vidéo de présentation gameplay est prometteuse

Sinon, je ne crois pas l’avoir vu ici : battlefield-4-un-train-tout-bonnement-indestructible
www.journaldugamer.com…
y a une vidéo dans leur news :smiley:

edit : mauvais topic bordel :smiley:
Edité le 14/02/2014 à 11:02

Ho si je t’assure ! Déja je peut mettre le jeux tout à fond, même les truc “useless” du style AA 16x et j’ai encore facile 200 fps. Du coup le jeu est super fluide et super lisse. Ensuite les textures sont très détaillées et l’éclairage super bien léché. C’est vraiment un exemple d’optimisation.

Bon sinon j’ai finit par régler mes problème de framerate. Grosse poussiède dans le ventilo du cpu, du coup ça chauffait et automatiquement le cpu d’undercloockait pour reprendre une chaleur correcte, et ainsi de suite. Je vais surement passer au watercooling kit, j’en ai marre des ventilo.

Optimisation ? Non.
C’est juste qu’ils n’utilisent pas des effets plus ou moins inutiles qui bouffent un max de ressource (whaooouuu ! Un nouage de poussière en 3D avec particules pour sa géométrie qui respectent les lois de la physique, mettons le en avant ! Ah tiens une texture tournante donne le même aspect graphique… tant pis on reste quand même sur le premier choix histoire d’aider les marketeux :nexath ) et la géométrie de l’environnement est ni modifiable, ni transformable.

Bah c’est de l’optimisation de faire des choix techniques qui ne compromettent pas l’aspect artistique hein :wink:

Ce n’est pas l’optimisation qui compromet l’aspect artistique dans un projet bien géré :wink:

Tu peux optimiser le CryEngine ou le Frostbyte autant que tu veux, tu ne feras pas marcher de telles usines à gaz sur un smartphone android. Un jeu AAA ce n’est pas la même dimension qu’une demo.
Edité le 14/02/2014 à 17:16

Wep, surtout que leur moteur est “à chier” niveau possibilités. Va demander au moteur source de conduire une voiture par exemple, c’est la rigolade. Tu rigole aussi quand tu voit que certains truc comme l’herbe sont des sprites animés. Mais au final ingame tu t’en rend vraiment pas compte, même en regardant lentement.

Tu rigole ?

Le jeu est basé sur de la coop pure avec du 4vs4. De base tu peut détruire toutes les fenêtres et les portes. Tu peut ouvrir toutes les portes, alors que sous bf tu ne peut pas ( c’est risible ). T’a pleins de panic event, avec une modification de l’environnement, du genre une grue qui bouge pour ouvrir le passage.

Et sous bf faut pas ce leurrer, les destruction de batiments c’est pas du dynamique, c’est juste des anims préenregistrés et en plus c’est toujours les même. D’autant plus risible que ça du être précalculé dans des soft 3d qui utilise de la physique. Du coup ils auraient largement pu enregistrer plusieurs anims et les jouer au hasard, ou part rapport au dernier mur qui tiens.

Le lévolution, des vagues qui monte et de la pluie qui ce ramène, c’est pareil que des vague de base dans left 2 avec de la pluie. Sauf que sous left ta de belle éclaboussures d’eau au sol alors que sous bf quedal. Les autres lévolutions c’est pareil, ça va pas chercher bien loin.

Je sait pas si tu sait mapper, mais de mon côté je doit avoir quelques centaines d’heures sous build l’éditeur de duke 3D. A l’époque il y avait déja de la lévolution… Tu pouvais aussi faire des trous dans tous les mur si ça te chantais il fallait juste le prévoir à l’avance. Tu designai ton mur déja explosé, tu rajoutait une balise spécial dedans et il y avait remplissage auto.

Faut pas confondre moteur d’un jeu et moteur graphique hein ! :wink:
Rien n’empêcherait d’avoir un jeu hyper réaliste sous le Source Engine avec un enrobage qui va bien.
Dans un jeu le moteur graphique et le moteur du jeu doivent se partager des ressources limitées.

Détruire une fenêtre ou une porte c’est un événement alacon. Dans BF4 je pense que c’est un choix si c’est impossible. ça permet de limiter le nombre de glitchs possibles (et donc de tests parce qu’ils n’ont pas mis de mécanique permettant de l’éviter à l’avance). ça permet aussi d’éviter que les joueurs se prennent la tête pour déloger un seul type qui se cache de maison en maison.

Les résultats initiaux et finaux et les gros blocs sont préenregistrés, oui. Mais les effets cosmétiques autour non je ne pense pas. Vu la gueule des blocs dans BF4 a vrai dire se serait calculable en temps réel s’il y en a peu, mais il est obligatoire que le résultat soit le même chez tous les joueurs.

Le coup de la flotte je pense que c’est un choix (ou une absence d’idée ce qui est tout à fait possible), pas une limitation technique.

Dans tous les cas on est d’accord sur quelque chose, le moteur de BF4 c’est une usine à gaz. :nexath

Oui je sais, mais avec l’expérience ont arrive vite à savoir quel jeu est fait avec quel moteur. Par exemple du moteur unreal ça ce remarque assez vite, avec du bump et textures un peu metal et réfléchissant.

Le moteur influe le graphisme de part ces capacités. Si ça ce trouve tu file le frosbite à valve et il te feront pas un jeu optimisé. D’ailleurs pour ça que leur jeu est autant opitmisé car leur moteur est viellot. Après il en a quand même sous le capot.

D’ailleurs le dernier titanfall tourne sous source.

Pas d’accord. Le temps réèl ne veut pas dire “purement aléatoire”.

Exemple à la con : T’envoit une roquette sur un mur et il explose avec pleins de débris. Moi j’envoit au serveur 3 infos. Le temps ( quand j’ai tiré ) et l’axe X et Y. Les infos sont ensuite dispatchés via le serveurs au autres joueurs.

Du coup toi tu va recevoir ces 3 infos et ta machine va calculer le reste. Vu que le moteur physique est identique sur toutes les machines le calcul de destruction sera aussi le même.

Par contre on est d’accord que quelqu’un qui sera à l’autre bout de la map, devra aussi faire le calcul. Sauf si il y a un système de P2P qui permet de renvoyer plusieurs étapes ou le résultat au serveurs et / ou au autres joueurs. Je pense pas que le jeu intègre ce genre de techno.

Peut être, mais par rapport à tous leur batage médiatique c’est pas terrible par rapport au possibilités qu’ils ont.

C’est surtout la partie netcode qui est à revoir et qui influe beaucoup trop sur le moteur physique. Faudrai tester par exemple, 32 mec à l’autre bout de la map en train de rpg un building, et dans l’autre camp être iddle et regarder les chutes de perfs.

Pour ce qui est du netcode, regarder cette vidéos : www.youtube.com…

C’est vraiment très explicatif. Le seul truc de dommage, c’est qu’il prend aucun jeu pour comparer. J’aurai bien aimer voir la même sous cs par ex.

encore un bug :arf: ça m’arrive de pas pouvoir tirer dans un tank ou VCI en co-pilote :neutre:

Temps réel veut forcément dire résultat différent. C’est inhérent à l’informatique et aux mathématiques en général. Seul les probabilités permettent de prédire la différence avec le résultat espéré (cf. chaos theory, d’ailleurs cette discipline a débuté quand qqun a remarqué qu’un calcul donnait à chaque fois un résultat légèrement différent à chaque exécution sur un PC si je me rappelle bien) :wink:
Si tu prends en compte les variations de performance de réseau et en plus les différences avec les divers arrondis tu peux être sûr que t’auras une explosion différente chez tous les types.
Le pré-calculé permet d’attendre le même résultat chez tous et de ne pas trop charger le client avec des calculs assez complexes.
Je pense que le choix de Dice c’est de laisser le serveur gérer et décider sur les événements effectués par le jour contrairement à un simple flood d’un end user à tous les autres. Ceci permet d’être sûr que les mêmes event soient transmis à tous mais en contrepartie la charge de travail du serveur est augmentée et certains peuvent profiter de leur low ping.
Faut pas confondre la partie netcode d’un programme, le moteur physique et le moteur d’un jeu. Un moteur physique ne te permet que d’estimer la position d’un objet à un temps t+epsilon. Et je pense même qu’il y a une synchro de la position des objets effectuée par le serveur (par exemple la juste d’un hélico n’est pas précalculée contrairement à un tas de feuille qui explose).
Il ne faut pas oublier qu’un designer de jeu n’a accès qu’à des outils. Il n’est pas sensé avoir besoin de savoir ce qu’il se passe dessous. T’as peut être besoin d’envoyer un timer et une coordonnée, ça m’étonnerait grandement que le dialogue entre les applis se résume à ça :wink: Est-ce qu’il y a du superflu même côté netcode avec le FrostByte ? Sûrement, c’est le moteur “général” d’EA. On peut voir ça comme les divers couche d’abstraction sur un PC, plus user friendly mais de plus en plus loin du matériel, d’ailleurs il fut une époque où il pouvait arriver qu’il faille coder en binaire directement car l’hexadécimal prenait trop de place.
J ene pense pas que le moteur graphique dans un jeu soit le facteur limitant en terme de graphisme. Des gens sont spécialisés dans l’optimisation de moteurs graphiques en fonction du matériel et sont capable de sortir un moteur gérant pas mal d’effets sans pour autant bouffer beaucoup sur la CG. C’est ce qu’il y autour qui bouffe énormément. Et vu que ce qu’il y a autour est bien plus complexe (plusieurs services avec des priorités devant tourner sur un parc de CPU très variable…) normal que ça rame quand c’est une usine à gaz. C’est un peu comme FSX, pas mal de paramètres, des graphismes assez moches, et 20fps constants. Est-ce que c’était dû à une mauvaise optimisation ? Peut être, même sur Microsoft Flight n’était pas extra en terme de framerate non plus. Est-ce que c’est dû à un chef de projet qui a eu les yeux plus gros que la tête en faisant les choix technologique pour le rendu du terrain par rapport au matos et aux APIs disponibles ? Sûrement.

Alors j’ai carrément du mal avec ce concept de temps réel.

Donc si je suis ta démarche, cela veut dire que le timer et la coordonnée avant d’être envoyés au serveur sont d’abord arrondis ce qui procure l’effet chaos ? Pourtant j’ai remarqué que des fois sur des gros serveurs à lag ma roquette contre un mur ( conservons cet exemple ) elle explose elle aussi avec un lag ?

Cela veut dire que l’explosion attend la réponse du serveur, et donc je reçoit le résultat de mon propre arrondis / chaos ?

Toujours en suivant ton explication, cela veut dire qu’un jeu comme cs à lui aussi du chaos, mais qui est “lissé / optimisé” via le tickrate tu serveur ?

Ça en reviens presque à dire que pour bf4 c’est foutu, car vraiment l’impression que le serveurs crachent déja leur trippes…

toutes les animations sont pré rendues bien entendues, et pour le reste en effet cela s’affiche probablement pas de la même façon chez tout le monde. Encore qu’il faudrait tester en détruisant un hélico.

Ceci étant l’approximation est suffisante je pense, ce n’est pas essentiel qu’un hélico en flammes tournoie de la même façon chez toi et chez moi à partir du moment où le client affiche bien où il est et surtout où il va… ie : je veux pas le prendre dans la gueule.

Pour les rockettes il est fréquent d’avoir un obus ou un missile encore affiché alors qu’on a pris le hit par exemple. Ca c’est le netcode qui est à la faute. Et oui un tickrate supérieur lisse ce problème.

Non.

J’ai mis en avant la notion de chaos pour mettre en évidence la nécessité d’avoir des garde-fous permettant d’avoir le même résultat chez tous les joueurs. Envoyer time+coordonnates et laisser le moteur physique faire les calculs aurait un effet chaotique sur la partie. Le moteur physique ne rendrait pas forcément les mêmes résultats suivant les machines des joueurs (les dev ne contrôlent pas le déterminisme de l’ordre d’exécution des instructions exécutées par le CPU, idem pour ce qui est transfert mémoire etc). Tu pourrais très bien avoir ta roquette qui atterrit à deux endroits légèrement différents suivant deux PCs. Le rôle du serveur est de “discuter” avec les PCs des joueurs pour décider quelle est la position “vraie”.
Ceci n’est valable que pour les objets en mouvement. Pour les événements statiques comme les explosions il n’y a pas besoin.

Je pense qu’ils font en sorte qu’il tombe de la même manière au même endroit. Sinon ça serait un peu embêtant pour les roadkills des types qui sautent de l’hélico :ane:

Après je me demande si sur BF4 c’est la trajectoire qui est décidée par le serveur ou l’effet. Parce que le coup des obus de tank qui touchent un hélico et font 0 dmg… :paf:

C’est un autre soucis ca, c’est les hitbox qui sont foirées sur certains angles. C’est pareil quand tu es gunner sur l’hélico d’attaque. Tu peux vider ton chargeur complet sans faire de dégâts.

Comment on peut faire un sorte qu’une hitbox soit foiré suivant un certain angle ? :paf: