This is probably just a long an rhetorical post here but I'm on a mission:
I am putting together a system of common functions to abstract how the ESP8266 actually works, into something a lot cleaner for a developer. Otherwise I think it will be too intimidating to be common. Even with the current buggy uzem 8266 support we can develop and test concepts for networked game demo right now(though until the Tx code is done, it will be jittery at best). I have been thinking about this, and I am leaning towards the idea that non-padstate networking is not unrealistic for many games as long as there are working examples of the theory. I think the best thing to get working first, as a good tutorial even, is a networked version of Megatris. Obviously it was the real flag ship game for the console and everyone has played it, and it's hard to find someone who doesn't enjoy it at some level. Besides, it's a great competition game, has some resources left in the build, and lends itself nicely to non-synchronous networking ie. not padstates. Open source tetris AIs are around, run an AI server on uzebox.net, and there is the "VS CPU" mode I always wanted-distributed computing is limitless.
I showed that padstates can be drop dead easy, but doing it any other way, I would say, looks complex as hell at this point. Megatris I suspect will not be that difficult and I will write up a tutorial as I go, improve ESP8266 emulation in Uzem as I discover it's shortcomings during the development, and for any of this to work well I need Alec to add Tx buffer code
I will also need to finish a simple gameplay server for uzebox.net too, so I'm not saying this will happen overnight but it's my main focus. The general overview of how it will work is: each Uzebox will send the state of it's entire well(compressed) to the server as fast as possible, the server will send it to the other client. Now no matter you did you are looking at their well slightly in the past, that's internet gameplay, doesn't matter, think of them as separate threads. The server is just a data mediator but not the authority, the clients are trusted not to cheat.
The only time we need calculate "what happened first" happens to be the only way players really interact with each other: when garbage is sent over. You could get picky and calculate dead reckoning into the past to determine if garbage should have been in their well, before they finished planting a piece(that finished a line), that, depending on which happened first, would have caused a game over by filling the well or to have enough space left by clearing....yeah, screw all that stuff
. When the client hears about the garbage you sent, he will add it to his well and from there you will see the garbage in his well appear, since he's constantly sending you well states as fast as possible anyways. It would be only an extremely rare situation where that would make a real difference, and in that case latency plays no favorites. Play with lower ping people if you are that much of a purist
Besides that general concept I know will work, the details aren't too radical. Since well states come rapidly and we only care about the newest available, use UDP packets with a time stamp. On receiving packets, discard any data older than what we already know about(packets out of order) since it's worthless. There must be a way to send reliable messages over UDP, so make a message ID/acknowledge system....no, forget that too
. There is no cost to having multiple connections open on the 8266 and conveniently we can automatically have well state and message states separated. One connection is UDP for latency sensitive well data, the other one is TCP so we don't need to waste code space for a reliable message system for garbage. Let the module do all that work in it's TCP/IP stack. A well is 10*20 and there are 8 possible states for each 1(empty,color1,color2,etc) so 3 bits per space. We can send a compressed well state easily using only (10*20*8)/3 = 534 bits = 67 bytes @ 38400 baud = ~60 network frames a second: it should be silky smooth on even mediocre internet connections.