Here's a fun little project. By "fun" I mean "nightmarish" and by "little" I mean "countless hours of headaches".
Let's network a Pico-8 cart.
But the BEST networking would involve allowing the local game to run a few frames ahead of the networked player and carefully revert and re-run those frames whenever changes in input are received, so that the game still runs full speed and remains synchronized with just a little bit of reality-bending when there's latency. This requires a deep, deep control over the entire game state, and the ability to run the game (without rendering) much faster than it's intended to go.
That's enough rambling for now. This post is just a reminder for fun things to try whenever I'm bored next.
One of my friends has just successfully made a lockstep-synchronized multiplayer Pico-8 system using Cheat Engine for Windows (and a matching, compatible scanmem-based system for Linux) to push srand, button presses, and frame step data into Pico-8's Base RAM in the user-defined section nobody uses, at a full 30 frames per second over the Internet, which the cart can then read to produce a fully synchronized online multiplayer game between two people. :3 I'm really proud of them.
It's a little messy at the moment (it doesn't lose connection cleanly and such), so I'll let them refine it better before we think about releasing it here or something...
Right now I have a really simple modem style modulator/demodulator script that can do about 2-4 characters of text per second over the audio channel. It's a proof of concept, but I can fire arbitrary alpha text to the sound card and have a script parse it on the other side.
I need to clean it up and get it reusable/presentable but eventually it could theoretically be much faster (more like a real modem) and used for things like Muds, turn based tactical games, role playing, etc.
The big challenge I'm going to have is getting input back into pico8. I'm imagining using base 6 input on the second player controller and having the modem script inputting keystrokes as fast as the system can receive them. Where I'm really hitting walls though is the DSP stuff on the pico8 audio channel; it's hard for me to get a clean enough signal to decode it quickly and I'm not all that great at pico8 yet.
That said it'd never be useful for a lockstep style multiplayer game. Good for async stuff though.
Maybe we could reserve a portion of the screen to output data to transfert. It's easy enough to draw Pico8 in a web canvas and read back the value. In a turn by turn system, a "data" frame could be outputed when transmission is required and not even displayed to the player. Of course, on the other end we would need to encode it in player inputs.
[Please log in to post a comment]