60

Et c'est reparti !

La base de code commence à se stabiliser et mine de rien, le jeu est mieux qu'avant. Ça serait con de n'en faire profiter que les geeks qui le recompile depuis le dépôt github. Donc voilà, petit message pour annoncer qu'on relance le cycle ALPHA -> BETA -> release. Avec cette première ALPHA, toujours disponible gratuitement ici : https://sgadrat.itch.io/super-tilt-bro.

Ce que j'entends par ALPHA, c'est que le jeu est toujours en gros chantier. Il est jouable, mais il y a plein de choses qui devrait arriver au fur et à mesure des ALPHAs : le support du réseau, plus de musiques, de meilleurs bruitages,... En fait, à peu près tout ce qui me semblera cool, qui vivra verra smile



Changements notables par rapport à la version 1.1 (celle sur les cartouches):

* Un nouveau perso jouable
* Nouveaux graphismes par Martin Le Borgne, qui a bossé sur Twin Dragons (ce mec est super cool !)
* On peut descendre des plateformes en appuyant brièvement sur bas
* On peut sortir de l'écran sans mourir, les limites sont juste un peu plus loin
* L'IA est un peu moins conne (elle arrive enfin à nous frapper si on ne bouge pas)
avatar

61

king
avatar
@originalfei
In pixels we trust.
ORE WO DARE DA TO OMOTTE YAGARU !

62

Hop, une jolie petite nouvelle à propos du projet : le prototype online.

Il y a bien longtemps j'avais fait quelques premières expérimentations qui s'étaient bien déroulées. Là j'ai l'ambition d'enfin intégrer ça correctement. Depuis le netcode a été amélioré et on a réussi à le faire tourner sur une vraie NES.

Avant d'intégrer ça à l'alpha de Super Tilt Bro. J'aurais besoin de savoir à quel point ça marche vraiment en conditions réelles. Donc voilà un prototype suffisamment stable pour être utilisé sans avoir l'impression d'être Anakin Skywalker dans une course de pods. Le prototype vient avec un émulateur, la ROM et des scripts pour lancer tout ça correctement sur l'un des deux serveurs : Amérique du nord ou Europe. Pour vous le bon choix sera généralement Europe beret

Voilà le lien magique : http://supertiltbro.wontfix.it/online.html

Merci de me faire des retours. Que l'expérience soit bonne, mauvaise ou toute pourrie. Tout retour m'aidera à savoir sur quoi me concentrer ensuite. Aussi, les serveurs ne seronts pas très fréquentés, pensez à prévenirs vos amis avant de lancer une partie, histoire d'avoir quelqu'un contre qui jouer.
avatar

63

Supeeeer !
Je vais m’organiser avec mon frère pour tester. Je vais peut-être faire de la capture video aussi pour les retours !!
avatar
@originalfei
In pixels we trust.
ORE WO DARE DA TO OMOTTE YAGARU !

64

Merciii ! heart

Hâte d'entendre vos retours. Vous faites partie du top mondial sur ce jeu (même s'il suffit d'avoir joué pour rentrer dans le top.) S'il y a un truc que j'ai appris en implémentant ce netcode c'est que les problèmes sont clairement plus évidents pour les joueurs qui savent ce que font les boutons. Enfin, j'ai aussi appris tout un tas d'autres choses, ça méritera un article smile
avatar

65

Le retour de l'internet !

Super Tilt Bro. n'est pas un jeu rétro. Le but à toujours été d'en faire un jeu moderne sur une ancienne console. Et vous savez quoi ? Les jeux modernes, ça se joue en ligne !

Ça fait un bon moment que l'idée me trotte dans la tête, et j'avais même écrit un truc là dessus : topics/188767-devlog-super-tilt-bro/2#post-34 Les choses ont bien évoluées depuis, on arrive à le faire tourner sur de vraies NES et le protocole s'est bonifie. J'ai même eu l'occasion faire des parties transatlantiques sans aucun souci ! Donc voilà, comment ça se passe sous le capot.

D'un point de vue hardware, basiquement on colle une puce WiFi (ESP8266) dans la cartouche. Je suis loin d'être une brute en hardware, mais c'est juste ça et beaucoup de magie. Je vais surtout parler du netcode de Super Tilt Bro.

tRQLdEO.png
Un prototype de cartouche WiFi, par @BrokeStudio

Les problèmes avec le jeu en ligne

Écrire un jeu qui se joue en ligne est réputé difficile. À tout moment, on doit s'assurer que les deux joueurs voient la même chose. Lorsque l'action est intense, quelques millisecondes de ping peuvent tout changer.

Considérons Alice et Bob qui jouent ensemble. Bob a préparé sa super attaque et Alice l'a esquivée au tout dernier moment, MAGISTRAL ! Mais il y a 20 millisecondes de ping entre les appartements d'Alice et de Bob, c'est commun, alors qu'une frame fait 16 millisecondes. Alice a esquivé sur la toute dernière frame possible, donc l'esquive est passée, elle est prête pour une contre-attaque sanglante. Malheureusement Bob reçoit l'information à propos de cette esquive la frame d'après, pour lui elle à esquivé trop tard et s'est prise l'attaque de plein fouet. C'est un cas typique de désynchronisation : les deux joueurs voient une issue complètement différente de leur combat.

3ppvZrS.png
Alice et Bob vivement maintenant dans des univers parallèles

Le netcode basé sur le rollback

Super Tilt Bro. implémente un netcode de type "rollback". On n'attend pas de connaître les inputs de l'adversaire, on les devine. Bien sûr il arrive qu'on se trompe. Dans ce cas, on revient à l'état du jeu avant de s'être trompé et on rejoue le plus rapidement possible (sans les afficher) les frames erronées.

Qu'est-ce que ça donne pour Alice et Bob ? Alice esquive à temps et son jeu l'affiche sans problème. Du côté de Bob, le jeu commence par "deviner" qu'Alice n'a pas esquivé a temps (c'est un super play comme on en voit rarement). L'écran de Bob affiche une frame où on peut voir Alice se prendre l'attaque. Quand l'information arrive, moins de 20 millisecondes après, le jeu rejoue les frames mal devinées. Alice n'a jamais été touchée. Ça veut dire qu'il y a eu une frame étrange, où Bob à vu l'attaque réussir, mais tout est revenu à la normale très vite. Le jeu peut continuer.

Jq44al8.png
Le moteur rollback qui, l'air de rien, remonte le temps.

L'algorithme pour deviner les inputs futurs est super simple. On part du principe que rien ne va changer, aucun nouveau bouton pressé, aucun bouton relâché. Même avec un joueur taré qui fait six actions par seconde, sur un jeu à 60 FPS, on devine correctement 90% du temps.

Ajouter de la latence à l'input

Une autre astuce est de délayer les inputs, tout en les envoyant immédiatement sur le réseau. Disons qu'on ajoute artificiellement quatre frames de délai, soit 64 millisecondes. Tant que les messages mettent moins de 60 millisecondes à traverser le réseau, aucun rollback n'est nécessaire.

Voyons la partie entre Alice et Bob, cette fois avec quatre frames de délai à l'input. Quand Alice appuie sur le bouton esquive, l'effet n'est pas immédiat, donc elle se prend le coup en pleine poire. Une ou deux frames plus tard, Bob reçoit le message à propos de la tentative d'esquive, elle prendra effet plus tard. Les deux joueurs voient la même action : Alice a pris cher. C'est moins épique, mais au moins tout le monde voit la même chose et il n'y a pas eu de glitch.

Wqo13gV.png
Délayer les inputs : pas de glitch, mais ça peut être frustrant.

Bien entendu, les deux façons de faire peuvent être utilisées conjointement. C'est ce que fait Super Tilt Bro. Les inputs sont légèrement délayées, ça suffit la plupart du temps. Quand il y a un pic de latence sur le réseau, le rollback est là pour rattraper les pots cassés. Simplement dit, le rollback provoque de petites sautilles, le délai d'input rend les persos moins réactifs, il faut trouver le juste équilibre entre les deux.

Ce que font les autres

Bon, maintenant on a une idée des techniques de mitigation de la latence implémentées dans Super Tilt Bro. La plupart des développeurs ne parlent pas ouvertement de leur netcode, c'est pourtant un sujet important et les différentes approches sont toutes intéressantes. Voici quelques-unes connues.

Super Smash Bros, le vrai. Ça ne se passe pas tout à fait pareil. Il n'y a aucun rollback dans le jeu de Nintendo. Au lieu de ça, le jeu ralenti ou même freeze en attendant les informations nécessaires. On peut facilement voir ces freezes en jouant sur une connexion instable. Pour mitiger l'impact de ces freezes, le jeu semble adapter le délai aux inputs dynamiquement. (Désolé pour ce "il semblerait", les infos disponibles ont été reverse ingénieurées, voir simplement devinées.) On sait pour sûr que Super Smash Bros Brawl note chaque connexion de la meilleure (avec trois frames de délai) à la pire (avec 15 frames de délai.) Des gens ont tenté de mesurer le délai de Ultimate avec une caméra haute vitesse, ils ont échoué pour le mode en ligne, c'était trop instable. Peut-être qu'Ultimate ajuste le délai au cours de la partie pour chaque joueur.

Cette approche qui consiste à éviter les rollbacks, quitte à freezer le jeu, a du bon comme du mauvais. Premièrement, c'est simple à implémenter, le seul cas spécial à gérer est d'attendre les infos nécessaires avant de continuer le jeu. C'est également peu coûteux en CPU et en mémoire. N'ayant pas besoin de pouvoir rejouer le passé, le moteur de jeu peux simplement oublier ce qui s'est passé avant et aller de l'avant. L'effet sur un pic de latence est un freeze, alors qu'un code de type rollback montrera des persos qui se téléportent. Le freeze est plus lisible, mais une petite sautille d'un personage perturbe moins de rythme du jeu. Ce doit être une question de préférence. Le plus gros problème est le jeu compétitif. Même à un niveau moyen, les joueurs ont appris des combos avec des rythmes très précis (parfois même frame-perfect). Si le jeu ralenti, freeze ou change le délai d'input au milieu d'un combo frame-perfect, c'est foutu, même si l'exécution du joueur était bonne. Enfin, les freezes doivent absolument être minimisés, donc en cas de doute, le délai d'input doit être au plus haut.

Une autre solution, bien connue celle-là est GGPO. C'est un netcode de type rollback fait pour pouvoir être utilisé tel quel par les développeurs de jeux. Il est très populaire dans l'émulation d'arcade et est la solution retenue par Skull Girls, jeu reconnu pour son bon netcode. GGPO fait du rollback, sa documentation ne mentionne pas de délai d'input, mais Skull Girls offre l'option. On peut y choisir un nombre de frames de délai qui restera le même pour toutes nos parties. Ainsi, le joueur peux choisir lui-même où placer le curseur entre trop de délai ou trop de rollback.

Ça ressemble beaucoup au netcode de Super Tilt Bro. Le bon point de cette technique est que le délai est fixé et constant. On peut placer nos combos frame-perfect aussi bien qu'en local. Le plus gros problème est lors de gros pics de latence sur le réseau. Les personnages ont tendance à se téléporter dans tous les sens le temps que les jeux réussissent à se resynchroniser. Dans ces cas là, on ne comprend plus rien, mais le jeu continue de se dérouler. Enfin, un moteur de rollback doit être capable de garder des save-states de lui-même et les gérer en mémoire, pour pouvoir revenir dessus en cas de rollback. Ça a un coût non négligeable en CPU et en RAM.

Toutes ces implémentations modernes on un point commun : le peer-to-peer. Éviter aux messages de transiter par un serveur permet de gagner quelques précieuses millisecondes de latence. C'est vraiment une très bonne solution. Super Tilt Bro., lui, utilise un serveur. Voyons pourquoi.

Le serveur de Super Tilt Bro.

On a vu que le peer-to-peer c'est le top. Super Tilt Bro. ne fait pas ça. On a aussi vu que le rollback avait un coût CPU et RAM élevé. Il faut gérer une liste de save-states en RAM et être capable de re-jouer plusieurs frames immédiatement à tout moment. La NES, avec son CPU 8 bits à 1,5 Mhz et ses 2 Ko de RAM est très, très, loin des systèmes modernes. Implémenter le système de rollback dans ses condition monopoliserait la plupart des ressources, et c'est le gameplay qui en payerai le prix. Le serveur est là pour aider.

Vous vous souvenez d'Alice et Bob ? Avec le protocole de Super Tilt Bro., quand Alice appuie sur un bouton son jeu envoie l'état de sa manette et un timestamp au serveur. Le serveur connait le jeu, il est capable de simuler des frames et de recalculer l'état du jeu à tout moment. Connaissant la partie et la nouvelle input d'Alice, le serveur peut calculer l'état du jeu au moment où Alice a appuyé sur son bouton et envoyer tout ça à Bob. Bob reçoit donc le timestamp, l'état de la manette d'Alice et l'état de la partie à ce moment là. Si le délai d'input à fait son travail, il peut ignorer l'état du jeu décrit dans le message. Si un rollback est nécessaire, la NES de Bob peut se baser sur l'état fraîchement reçu, qui est juste au moment où la prédiction était mauvaise. Donc la NES n'a aucun besoin de gérer une liste des états passés, ce qui retire presque toute la pression sur la mémoire.

Le serveur peut aussi aider avec le budget CPU. Disons, qu'il y a toujours au moins deux frames qui s'écoulent le temps qu'un message transite d'Alice vers Bob. Quand le serveur reçoit une input d'Alice, au lieu de calculer l'état du jeu au moment de l'input, le serveur peut calculer un état deux frames après. Le serveur se met à prédire le futur, de la même façon que l'aurait fait la NES de Bob, lui épargnant ce travail. Bien entendu, ça nécessite d'implémenter un système de rollback aussi dans le serveur, mais ça aide beaucoup à gérer les grosses latences. A l'heure actuelle, Super Tilt Bro. est capable de rejouer trois frames avant de manquer de temps. Si le serveur peut se charger de le faire pour une ou deux frames, ça aide beaucoup.

UDP, TCP... et les navigateurs web

Sur internet il y a deux gros protocoles omniprésents TCP et UDP. TCP est le plus commun, il permet à un ordinateur de se connecter à un autre et d'envoyer des données. Avec TCP il n'y a pas de perte de données et les données arrivent a destination dans l'ordre dans lequel elles ont été envoyées. Le gros d'internet est construit sur TCP, c'est super simple à utiliser. UDP de son côté est un protocole beaucoup plus léger. Avec UDP, quand on envoie un paquet, la seule chose assurée est que le paquet a été envoyé. Il peut être perdu en chemin, ou arriver avant un autre pourtant envoyé auparavant. Donc TCP est le meilleur protocole ? Pas du tout ! La magie dont est capable TCP a un coût.

Quand on utilise le protocole de Super Tilt Bro., les paquets perdus ne sont pas un gros problème. Un message du serveur contient l'intégralité de l'état du jeu, donc si on perd un paquet, on retrouvera nos petits avec le prochain. Si on utilisait TCP, qu'on envoyait deux messages à la suite et que le premier se perde. Le premier serait alors inutile, le second étant plus récent il nous intéresse plus. Bien que le paquet intéressant soit physiquement reçut, TCP assure qu'il ne sera pas utilisé tant que le paquet inutile soit reçut. Il faudra donc attendre que le paquet inutile soit ré-émit. J'ai testé d'implémenter ping avec des garanties similaires à TCP et en forçant 10% de pertes de paquets au niveau de mon driver réseau, le ping pouvait monter jusqu'à trois secondes par moments, contre 20 millisecondes normalement.

Vous imaginez avoir trois secondes de latence à cause de la perte d'un paquet inutile ? Hors de question !

Pour ceux qui suivent le jeu, vous avez remarqué l'émulateur HTML5 sur la page itch.io. Ça semble anodin, et ça ne l'est pas du tout. Les navigateurs web se sont construit sur TCP, depuis des décennies. Ils ne laissent pas une page web envoyer des paquets UDP simplement. Super Tilt Bro. est basé sur l'UDP et il en a besoin. La solution à été d'utiliser WebRTC, un protocole fait pour les vidéo conférences. C'est ce qu'utilise votre Skype online, Google Meet, Facebook "appel vidéo",... préféré. Détourner un protocole de vidéo conférence pour y faire passer un prtocole de jeu a été épique. J'écrirai peut-être un truc là-dessus, en attendant, voilà le fil Twitter en temps réèl de mon combat contre la sécurité du web : https://twitter.com/RogerBidon/status/1259171335135211523

Un dernier mot

Implémenter des possibilités réseau moderne pour la NES à été épique... Et ce n'est pas fini ! Ça à fait son chemin jusqu'à l'ALPHA. Ce n'est pas complet et j'ai terriblement besoin de feedback.

C'est testable ici (HTML5 ou émulateur patché) : https://sgadrat.itch.io/super-tilt-bro

Il y a aussi un Discord pour trouver des joueurs : https://discord.gg/qkxHkfx

Voilà, j'espère que ce petit bout de connaissance de l'internet pourras servir à quelqu'un. N'hésitez pas à poser vos questions pour de plus amples détails. Super Tilt Bro. est un projet libre. Il est là four faire de l'internet un meilleur endroit (à son niveau), pas pour protéger des secrets.
avatar

66

Merci c'est extra eek
avatar
@originalfei
In pixels we trust.
ORE WO DARE DA TO OMOTTE YAGARU !

67

68

formidable! bravo! doom
avatar

69

love Merci, merci !
avatar

70

Petites news du projet

Bon, bah, j'ai ré-implémenté un moteur de musique à partir de la page blanche. Mais pourquoi ? Deux raisons :

1. C'est rigolo à faire
2. J'ai en tête des fonctionnalités qui n'existent dans aucun
3. J'ai calculé que ça ne serait pas si long... mais je ne sais pas compter.

Le moteur est encore en rôdage, mais il fait déjà quelques trucs cools. Je vais le comparrer à ggsound et famitone, qui sont eux aussi des moteurs fais pour être utilisés par des jeux. Aussi au driver de Famitracker, qui lui est hyper complet mais bouffe beaucoup de ressources et est rarement utilisé pour des jeux, par contre en chiptune, c'est l'idéal.

1. On peut lui faire jouer des morceaux de Famitrackers qui contiennent des effets. ggsound et famitone ne font pas ça, ce qui oblige les compositeurs à faire en fonction du moteur,
2. Il est rapide et léger, il faut que je pousse la comparaison, mais pour l'instant il semble battre ggsound/famitone (de pas grand-chose, c'est comparable),
3. La taille des musiques importées est plus grosse que ggsound/famitone, sans être aussi obèse qu'avec Famitracker.

Et donc a terme j'aimerais lui faire jouer des musiques dynamiques. Qui changent de rythme en fonction du déroulement de la partie... Mais on n'y est pas encore. Je pense que je vais me motiver à écrire une entrée de devlog sur ce qui est déjà là. Il y a déjà une énorme quantité de détails techniques croustillants smile

Sinon, on a aussi fait un nouveau trailer avec une amie qui se lance en freelance de motion design. L'ancien avait déjà trois ans et ne ressemble même plus au jeu grin



Instant promotion gratuite : du coup si vous avez des besoins de motion design, pensez à elle. Elle répond sur son instagram.
avatar

71

Ce trailer ! top
avatar
@originalfei
In pixels we trust.
ORE WO DARE DA TO OMOTTE YAGARU !

72

Fei (./71) :
Ce trailer ! top
Grave !!!
avatar
Matmook -- http://blog.barreteau.org
Twitter : @matmookJagware

73

Ça donne vraiment envie...
avatar

74

Merci ! Ça fait plaisir a etendre. A force de le regarder en boucle, j'ai appris a n'en voir que les défauts et trucs qui auraient pu être autrement smile
avatar

75

Relayé sur flipboard

https://www.mirari.fr/qtAk
avatar

76

Héhé, apparemment l'idée du jeu NES en réseau ça plait. Je ne vais pas m'en plaindre king
avatar

77

Netcode rollback sur la NES : les détails inavouables.

Attention, celui-là il va être technique !

Super Tilt Bro. ALPHA 5 vient de sortir. Grosse nouveauté : on peut jouer en ligne avec n'importe quel personnage sur n'importe quel niveau. Le moment idéal pour faire un bilan sur le fonctionnement du netcode, et les plus gros obstacles surmontés.

Vous les savez puisque vous avez lu le dernier post (au moins les parties avec des images), Super Tilt Bro implémente un netcode basé sur le rollback. L'expérience reste toujours fluide, quand les messages de l'autre NES prennent du temps à arriver, le moteur les prédit et continue d'avancer. Bon, parfois il se trompe. Dans ce cas il efface ses prédictions et re-joue les frames manquantes pour revenir à l'état courant de la partie.

Le protocole

Les netcodes basés sur le rollback sont connus pour être difficiles à implémenter. Il n'y a qu'à chercher un peu pour trouver des postes très longs et très sérieux assurant que la Switch n'est pas assez puissante pour faire ça. Et donc, comment réalise-t-on l'impossible sur NES ? (Vous vous en doutez : en trichant !)

Un des gros problèmes quand on implémente ce genre de netcode, c'est la gestion de la mémoire. Le jeu doit littéralement garder une copie de chaque état qu'il a prédit pour pouvoir s'en servir comme checkpoint. Tournant sur NES, avec 2 KB de mémoire (et pas des plus rapides), Super Tilt Bro. doit éviter ça à tout prix. Quand on n'a pas de mémoire, la solution est d'utiliser celle des autres. Les routeurs entre le serveur et la NES sont bourrés de mémoire !

Le protocole en quelque lignes :
  • Quand le joueur appuie sur un bouton, un message est envoyé au serveur. Un tout petit message, juste l'état de la manette et un timestamp.
  • Le serveur calcul l'état du jeu au moment de l'action. Il envoie un message étendu à l'autre NES.
  • Le message étendu contient : l'état de la manette, le timestamp et l'état du jeu à cet instant.
  • La NES qui reçoit ce message à tout ce qu'il lui faut. Il n'y a plus qu'à remplacer l'état du jeu par celui dans le message et simuler quelques frames pour compenser le temps de transit du message.

Voilà, la NES n'à plus à s'occuper de la gestion difficile de la mémoire. Le serveur s'en occupe et transmet tout ce qu'il faut. Aucun problème pour les routeurs, car on est sur NES, l'état de notre jeu fait une grosse centaine d'octets. C'est encore un tout petit paquet sur l'internet moderne. Il y a tout de même des compris faits. Déjà le serveur est plus complexe, il intègre un émulateur pour déterminer l'état du jeu. Le pire étant que, du coup, le serveur est nécessaire, impossible de migrer vers un protocole peer-to-peer. Avec le temps, on verra bien si ce rollback en passant par un serveur rivalise avec les netcodes basés sur l'input-lag en peer-to-peer.

Ok, second vilain : le CPU

Donc la NES a reçu un ancien état depuis le serveur et doit simuler les frames manquantes pour coller au présent. Ça DOIT être rapide. On ne veut pas délayer ça sur plusieurs frames vidéo, accélérant la vitesse de jeu, ça ruinerai le timing des inputs et ferait rater leurs combos aux joueurs. On veut rollback instantanément, qu'a la réception du message le jeu soit immédiatement mis à jour. On dispose d'exactement 20 millisecondes pour faire ça sans rater une frame vidéo (en PAL.)

La première chose à faire est de pouvoir mettre la simulation en “mode rollback”. Dans ce mode, rien n'a besoin d'être affiché, le moteur peux simplement ignorer tout ce qui est placement de sprites, modification du background, et tout ce qui est visuel.

Si on ne fait que ça, simuler une frame en rollback prend 25% de nos 20 millisecondes. Ça pourrait suffire à rollback quatre frames, donc compenser 80 ms de ping, si le reste du jeu ne prenait pas 60% du temps disponible. Notamment, on veut toujours simuler une frame en mode normal, juste histoire de voir quelque chose à l'écran. Du coup, ça permet de jouer, mais le moindre rollback est vite problématique.

Après ça, il reste l'optimisation pure et dure de tout ce qui est fait plusieurs fois par frame. La détection des collisions est là où on a vu les plus gros gains. C'était un vieux bout de code, implémenté tout en apprenant les base de 6502, et ça tourne chaque frame, pour chaque joueur, pour chaque plateforme... plusieurs fois. Autant dire que le grand ménage a été fait là-dedans.

Un autre gain a été trouvé sur le code qui gère les animations. En mode rollback, on se fiche de placer des sprites à l'écran, malheureusement les hitboxes sont définies dans les animations. Le moteur se retrouvait donc à parser des définitions de sprites, au cas où il y aurait une hitboxe au milieux. Ici l'astuce a été de toujours placer les définitions de hitboxes au début, le moteur s'arrête tout de suite après en mode rollback. Et puis des optimisations bas niveau, ça ne fait jamais de mal.

KzIwRkm.png
Avec les optimisations, on peut rollback trois frames... Bien, mais pas top.

Avec ça, on n'arrive pas encore à compenser les grosses latences. Heureusement, on a un serveur à disposition. Après tout, le serveur peut lui aussi prédire des frames, et il le fait. Il prédit juste ce qu'il faut pour compenser la latence minimum observée. Disons que le ping oscille entre 100 et 140 ms, le serveur va prédire de quoi compenser 100 ms. Dans le pire des cas, la NES devra compenser 40 ms, ce qui fait deux frames.

C'est quoi la suite ?

Ce netcode va avoir besoin de gagner l'expérience du terrain. C'est sûr et certain il n'est pas parfait, mais en quoi précisément ? Le seul moyen de le découvrir est de l'essayer, de jouer avec... de l'éprouver en somme. Plus il est utilisé, plus on trouvera de trucs, donc n'hésitez pas à l'essayer par vous-même, forcez vos amis à jouer avec vous, et envoyer moi toute remarque (promis, je ne m'énerverais pas.) Tout commence ici : https://sgadrat.itch.io/super-tilt-bro

Bon, aussi le netcode c'est bien, mais ce n'est pas tout ce qui fait un jeu en ligne. Pour l'instant, une interface moche nous bombarde dans une partie et voilà, point. Je pense commencer par créer un classement officiel consultable en ligne. Comme ça, si on est le meilleur au monde on pourra enfin se la péter. C'est important !
avatar

78

Vivement le petit livret making of offert avec le jeu grin
avatar
@originalfei
In pixels we trust.
ORE WO DARE DA TO OMOTTE YAGARU !