I guess, what I'm wondering about is twofold...

Do you think rollback netcode can be implemented in a cart without consuming a ton of it's resources... and do you think a cart with that level of netplay (within the remaining resources) has an audience it would appeal to? Granted, this is major feature-creep territory for any project scaled to P8 in the first place, but again, that's why it's a theoretical discussion...

Hi @TonyTheTGR.

Are you referring to being able to load a previous version of an updated and more recent cart ?

Like, fighting-game rollback netcode, where if it turns out that the other player made a move five frames ago it skips to frame six?

(Edit: I wanna say this article from a Killer Instinct guide website might be the one I read about this - I remember seeing one that was a really good explanation...)

I think it's theoretically possible - you'd definitely have to design it around making rollbacks easy from the start...

how are you adding networking in the first place?

with javascript, so carts are restricted to html exports and excluded from bbs, splore and consoles?

or with a custom wrapper program connected to pico8, which excludes bbs, splore and html exports, and requires special installation and run command?

Okay, thinking about numbers: if you want to be able to handle 300 ms lag spikes, at 60 fps, that's 18 frames. If you hardcode an 8-frame input delay into your cart, which (going by the article I linked) is high but not unheard of, then you have up to 10 frames of rollback before you make the game freeze to wait for input ... so you would need to design your game to be able to calculate 10 frames of simulation in a single frame without lagging out. So however much CPU you allow yourself for game state simulation, you actually need to use 10% of.

So, pretty restrictive, but if you know that going in, then maybe possible?

Edit: I assumed this was a Javascript-only cart with a custom plate to send network data via GPIO? It's definitely some kind of niche use case.

@dw817 It's definitely more of the fighting-game-use-case... and tbh, since this is theoretical/precontemplative in nature, I haven't committed to either approach... it's something of a very-stretched feature creep thing I'm considering for a couple of carts/projects I've been working... very slowly for a long time... on. And yes, one of them IS a fighting game.

It might not even be feasible to begin with; but since FGs are animation based, and animations would be set with tables which themselves require a conditional and unconditional next state - the animations themselves are at best, loops of 14 frames. So the operable FPS itself would already have to account for that limitation on the backend anyways, meaning it would effectively be outputting 10/12/15 FPS at best, most likely... and going by the calculation above, it would only need to roll back a maximum of 3-5 keyframes, provided the extra steps called in between them, right? Because the way I'm primarily designing moves is with a 3-4 frame startup, then active frames, then 3-4 frames of cooldown where applicable; so the pacing for the frameskip actually works out; it's just a matter of how that box fits in with PICO's capability.

So I'm wondering, if I'm skipping that many steps on the backend just pacing the animation/frame data anyhow, if implementation of rollback is worth considering with the remaining processing power, provided it doesn't get stuffed in the Token Limit.

I don't know if it would work as a BBS/Splore cart anyhow, because it's still multi-cart in nature. Now, setting up matchmaking? That is another layer altogether, especially if cart version control becomes a concern. I'd like to keep it as peer-to-peer as possible; or at least room-to-host. FWIW:

Main Cart is just the "character manager" and function caller for matches/outcomes thereof, as well as some incidentals like character portraits. There's a secondary cart that does the FSM management and matches themselves, to output a result to the Main Cart as Win/Loss/Draw/Score. This is actually the only place where the Rollback would be necessary, since it's the only instance where the game is input/timing sensitive. Then, each character is a cart to be conditionally included as the characters are selected/involved in the Match functions; which also include a BG to be scaled/stretched to the map, a BGM or two, and a small bank of universal sound effects. So a subfolder of these "Character Carts" would then just be a modular approach to said game. Naturally, the character carts would "unload" at the end of each match (or preload all at once, for say, an Arcade Mode run without loading screens?).

The second project I was considering, somewhat similar in nature, would be akin to Mario Party and it's minigames, but with subfolder modularity and conditionals involved in its minigame implementation, rather than only the characters.

At first, this was a demake attempt; but I've already found myself "demaking my demakes" and that's part of the stalling loop I find myself in. That, and lots of outside work! But yes, considering the nature of the games in question, you can see why network-implementation is at least a worthy consideration, and why I would elect for rollback. And while actually greenlighting the netplay is technically in "feature creep" territory, it's important to predicate the build of the game on it's possibility from the outset.

In my head, I was a little wondering if you could specify, like, animation state just by having numbers for each parameter? Like, frame of sprite animation, x-coordinate of fireball, that kind of thing. That way, when the rollback happens, the state that the draw function checks gets updated and it just draws the new one.

tbh displaying the correct animation frame is the easiest problem to solve.
you need some network gameplay that works in the first place, eg something that is resolved server side and then sync’ed to multiple clients.

Not sure I understand what you are after…

could you answer my question: how are you adding networking in the first place?

if it’s javascript code for an HTML export game only, or a custom program that wraps pico8 and communicates over serial channels, then the best way is probably to have the rollback code part of that networking code, and only send computed results to the pico-8 game to have the right values for the current state of the world.

these articles about a networked game on the nes may be illuminating:
https://sgadrat.itch.io/super-tilt-bro/devlog/154432/real-time-online-gaming-with-the-nes
https://sgadrat.itch.io/super-tilt-bro/devlog/211874/rollback-netcode-on-the-nes-the-gory-details

also this one is a great read: http://web.archive.org/web/20120229011305/http://www.gamasutra.com/view/feature/131503/1500_archers_on_a_288_network_.php?print=1

@merwok
First idea was to just pack it into the Main and Battle Carts themselves; just looking for other comparable instances of the cart running via it's cart ID for matchmaking purposes, give or take a predictive difficulty modifier that the player decides upon... and then try to have the Battle Engine manage it internally as best as possible.

If that's unfeasable within the Token Limit, then it might possibly need a frontend... but an emulation/wraparound client creates more of the "problematic" netcode that having a zero input delay buffer gives. I was going to back 2 frames in the engine itself, for the sake of performance consistency between offline and online mode (and because hitboxes also need to check for the opponent's previous-frame hitboxes anyhow for counters); but I'm not sure how to make a wraparound already account for that, besides removing the frame delay in the cart and implementing it there anyhow.

But if I'm making a wraparound to begin with, what's the point of making it a P8 project and not just a standalone engine? That's kinda where this becomes "is this feasible within Pico, or should I drop the Pico aspect of this and just make it with an external engine to begin with?" comes in...

These articles are very helpful, btw! They do all really reinforce why the consideration needs to be taken very early! If I can make this in a Splore-friendly format, EVEN BETTER (but again... are multicart projects in there to start with?)...

no, multicarts can’t be on the bbs.

also saw your tweet about this — you are mistaken, the fact that pico-8 connects to the bbs for splore does not mean that games can do networking.
using custom code is a requirement; generally people do it with javascript (so HTML exports only, for itch or your own website).

we are going to get online leaderboards at some point (search zep’s tweet for scoresub), which should be abusable to implement some limited turn-based games.

Well, I guess this IS the feedback I was looking for, so I can basically dust the networking work in the projects. Good to know! Thanks all of you, I appreciate your insight on this matter.

you’re welcome, and sorry to dash your hopes!
(but do take away the ideas of doing networking in javascript, or using scoresub when we get it, or waiting to see if picotron provides anything)

Funnily I just posted a very similar question before finding yours...

The difference is that I'd like to have it natively since having a virtual console makes it a breeze.

And I had the idea become of my LD48 multiplayer game Dodgy48