[Tuto] Poids des cartes en Forge

[Zaelkyria]

Salut à tous les forgerons !

Avant de commencer ceci, je tiens à préciser que tout ceci ne vient pas de moi, mais d'un forgeron que je connais, Buddy Jumps, un anglophone.

Vous savez cette situation dans H2A quand vous faites une carte dont vous êtes vraiment fier, mais elle plante toujours au moment du chargement quand vous voulez la tester ? Eh bien, voici la raison.

Vous avez sûrement remarqué que les cartes que vous créez ont une certaine capacité de bytes. Si cette capacité est dépassée la carte ne chargera pas avec un certain nombre de joueurs.

Explication :

Spoiler sur "{TEXT1}": 

Le poids minimum d'un canevas de Forge ( Toujours Plus Haut, Nébuleuse, Inondation ) est de 793 bytes avec aucun objet placé dessus. Les trois canevas n'ont aucune différence au niveau des poids. Pour toutes les addition dans le nom ( ou la description ) de votre carte, tous les caractères, même les espaces, ajoutent 1 ou 2 bytes.

Voici la liste des bytes pour chaque objet de forge :

Spoiler sur "{TEXT1}": 

Structures : 23 bytes

Naturels : 23 bytes

Paysages : 23 bytes

Objectifs : Tous les objectifs valent 30 bytes, sauf les boucliers d'Infection qui valent 23 bytes.

Apparitions : Les apparitions initiales valent 23 bytes, les caméras initiales valent 30 bytes, les zones de réapparition valent 30 bytes et les limites de zone sécurisées / de frag valent 29 bytes.

Scripts : Les interrupteurs / retardateurs valent 24 bytes, tous les déclencheurs valent 30 bytes sauf le déclencheur activé si destruction qui vaut 26 bytes.

Gadgets : Les explosifs valent 24 bytes, les canons ( humains ) et volumes de gravité valent 23 bytes, les caract. zones valent 32 bytes, les télé-porteurs en valent 33, les boucliers / effets spéciaux / jouets valent 27 bytes, et les lumières valent 28 bytes.

Gadgets de carte : 24 bytes

Power-ups : 27 bytes

Véhicules : 27 bytes

Armes : 27 bytes

Test : Nom de la carte : TEST, description : TEST.

Objets placés : une grille, un télé-porteur, un interrupteur de console, un interrupteur, une porte de garage ( les trois connectés ).

In-game : 933 bytes

Prédiction : 931 bytes

Notons que les bytes n'ont rien à voir avec le problème de framerate.

Maintenant que vous savez les bases, passons à quelque chose d'important :

La partie suivante contient des exemples et des spéculations importantes. À la sortie de la MCC, Buddy a créé une carte avec uniquement des grandes falaises, la carte avait des problèmes de framerate, mais marchait bien à 14 joueurs. La carte atteignait environ 6 000 bytes.

Il a donc conclu que les bytes étaient en rapport avec le nombre de joueurs.

- Pour créer une carte qui fonctionne pour 14-16 joueurs, il faudrait moins de 5 000 / 6 000 bytes.

- Pour une carte de 10-12 joueurs, il faudrait moins de 7 000 / 8 000 bytes.

- Pour une carte de 8 joueurs, il faudrait 8 000 / 10 000 bytes pour une carte à plusieurs rounds, et 9 000 / 11 000 pour une carte à round unique.

- Pour un ou deux joueurs il n'y a pas de restriction, mais pour 3 joueurs il faudrait que ce soit moins de 13 000 bytes.

Spoiler sur "{TEXT1}": 

• Une carte avec une moyenne de 28 bytes par objets et 200 objets : 5 600 bytes

• Une carte avec une moyenne de 28 bytes par objets et 400 objets : 11 200 bytes

• Une carte avec une moyenne de 28 bytes par objets et 600 objets : 16 800 bytes

Gardez à l'esprit que ces résultats ne sont pas officiels. Comprenez qu'il est difficile de tester tout ceci avec tous les problèmes de la MCC.

PS : Lorsque vous regardez le poids d'une carte dans un Partage de Fichiers, ce n'est pas le réel nombre de bytes qui est affiché. Le nombre affiché dans le Partage est toujours largement supérieur.

Encore un énorme merci à Buddy Jumps pour ce topic.

Bonne Forge !

[Lethal Projekt]

Merci à toi pour ce partage ! Je pense que ça aidera beaucoup de forgerons à optimiser leurs cartes en attendant une MAJ qui corrigera les problèmes liés à la forge.

Je l'épingle

[Aug45]

C'est vrai qu'un tel topic est très intéressant, du moins si aucune mise à jour n'est prévu pour corriger les problèmes de stabilité. Pour ma prochaine forge, je viellerai à ne pas dépasser les 5 000 / 6 000 bytes afin d'être sur que 16 joueurs puissent jouer en même temps sur la map.

Merci du partage !

[King Friendzone]

Comme sur HCrea

Merci du partage !

Bien que je n'ai pas la MCC

[Tero]

Désolé de détruire ta théorie mais en tant que game dev des conclusions aussi hâtive me fâche un peu ^^

Déjà les bytes, c'est ricain, on dit "octet" chez nous !

dans les 793 octets il y a principalement des variables (pointeurs ou références aux textures, et autres fichiers ressources du jeu nécessaires au chargement du niveau)

C'est pas un hasard si un char ajoute 1 octet, c'est 8 bits de donnée, tout dépend de l'encodage derrière (et oui, même les espaces sont encodés).

Après, les blocs ce sont là encore des variables, leur valeur en bytes ne nous aide pas beaucoup, c'est là encore références aux fichiers ressources au chargement du mesh et sa configuration. plus il y a de variable plus l'objet (c'est le terme technique pour le coup) prendra de place en mémoire.

Tu dis ensuite que la baisse de framerate sur une map serait dû au nombre de joueur, or c'est pas vraiment le cas, le fait est qu'aujourd'hui les moteurs de jeu sont bien foutu et minimise tellement cette baisse de framerate qu'elle devient négligeable.

ici le plus important ce sont les mesh des falaises. Qu'est-ce qu'ils d'embêtant ? Leur taille pardis ! Le vrai problème aujourd'hui ce sont les grand mesh, plus ils sont grand et en grand nombre, plus il tue le framerate. cet perte est proportionnelle au nombre de joueurs in-game du fait que le nombre de paquet réseau et leur taille augmente, encombrant un peu le trafic. pourquoi me direz-vous ? un grand mesh c'est encore plus de calculs à faire, juste pour les collisions c'est énorme, et ça vient du fait que la map est été faite via un mode sandbox, le fichier de sauvegarde à l'air assez maigre et je ne pense pas qu'il contienne de traces de pré-calcul pour réduire le nombre de vérifications par rafraîchissement, d'où les lags.

Bon après bien entendu, plus y'a de joueurs, plus il faut être économe et ne pas surcharger la map sinon on arrive assez vite au lag.

un autre conseil que je pourrais donner c'est de ne pas trop mettre de mesh au même endroit, les collisions étant géré avec un système de spatial partionning, quand le joueur passera dans une zone surchargé il laguera un peu, parce que sa console fera pleins de calculs inutiles pour voir s'il ne rentre pas en collision avec ces items, même s'il ne sont pas directement en contact (c'est là la limite du système de gestion d'entité).

En espérant vous avoir aidé un peu ?

[Lethal Projekt]

Déjà les bytes, c'est ricain, on dit "octet" chez nous !

Il a dit à la fin de son post que cette trouvaille venait d'un de ses amis anglophone, il ne s'agit donc que d'une erreur de traduction, rien de bien méchant ^^.

Et je ne pense pas qu'il cherchait à dire que le problème venait du nombre de joueurs, mais plutôt que plus une carte et les zones dans lesquelles les joueurs passent sont lourdes à charger (ce que tu expliquais en terme technique en disant ça [spoil=]un autre conseil que je pourrais donner c'est de ne pas trop mettre de mesh au même endroit, les collisions étant géré avec un système de spatial partionning, quand le joueur passera dans une zone surchargé il laguera un peu, parce que sa console fera pleins de calculs inutiles pour voir s'il ne rentre pas en collision avec ces items, même s'il ne sont pas directement en contact (c'est là la limite du système de gestion d'entité).[/spoil]) plus le fait qu'il y a ait plus de joueurs amène au lag de la partie.

Pourquoi ? Parce que nous ne sommes pas sur un système de serveur dédié mais d'hébergement de partie par un hôte. Hors, si l'hôte est dans une zone chargée et que beaucoup d'autres joueurs sont dans des zones chargées, leurs consoles vont ramer et cela aura un impact sur la fluidité globale de la game.

Tu dis ensuite que la baisse de framerate sur une map serait dû au nombre de joueur, or c'est pas vraiment le cas, le fait est qu'aujourd'hui les moteurs de jeu sont bien foutu et minimise tellement cette baisse de framerate qu'elle devient négligeable.

Certes, mais même si on trouve un moteur récent, il y aussi un vieux netcode de l'époque de Halo 2 pour le multi. Or, on est plus sur les mêmes plateformes (consoles avec hardware différent, etc) et en plus c'était une époque ou tout étais beaucoup moins optimisé ^^

Attention, je suis d'accord avec tout ce que tu dis au niveau technique, mais parfois, des observations sur certains détails donnent des résultats théoriquement improbables (illogisme d'une technique par rapport au résultat obtenu) mais tant que ça marche ou que ça aide, les gens se sentent prêts à bidouiller pour trouver un peu de réconfort, surtout quand on adore forger et qu'on se retrouve complètement dans l'incapacité de faire fonctionner ses créations à cause d'un problème d'optimisation au niveau dev