Re: Bluetooth crisis ..
Re: Bluetooth crisis ..
- Subject: Re: Bluetooth crisis ..
- From: Zack Morris <email@hidden>
- Date: Sun, 08 May 2011 11:15:14 -0600
On May 7, 2011, at 4:14 PM, Lou Zell wrote:
>
>
> On Sat, May 7, 2011 at 2:46 PM, JP May <email@hidden> wrote:
>
> The two things that totally mystify me:
>
>
> (1) there is a billion dollars worth of iPhone games being sold per year: after "opening PNGs", "realtime networking" is about the most basic issue in games. How come this isn't the number 1, most talked about issue, in the entirety of the iPhone universe? What do you have if you can't do realtime networking? It just doesn't make sense that you and me are seemingly the only people the issue it has ever come up for? How can the platform exist without dozens of realtime networking solutions laying around everywhere? Shouldn't the "bluetooth problem" be the biggest thing around? I just don't get it.
>
>
>
> I'm shocked by this as well, maybe there is a trick that we don't know about yet :)
Oh don't worry, it's not just Apple. I've been working on networking for 15 years and for the most part, nobody anywhere really "gets it". I actually spent 2 years and a few tens of thousands of dollars (of real money and opportunity cost) writing a massive peer to peer protocol with router tunneling and everything, and I ended up losing my butt over it because I couldn't make it stable. It turns out that if you have multiple streams of data, you CAN'T control state in threads or anywhere else if you don't have a single atomic store somewhere with the real notion of the game state. I thought I could get around it by having all of the clients have access to the entire stream of events for turn-based games like monopoly, and then reason out the current state somehow, but there were too many edge cases where the game state was good but I get unexpected events over the network like a user timing out. I ended up having threads with if-commands with a dozen cases to handle every contingency and it still didn't work. In the end, the only way to do it properly that I can see, is to have a mundane reliable channel somewhere, whether it's a TCP socket or a REST API or carrier pigeon, and then have layers above that to handle prediction when it doesn't hear from the server for extended periods, and RPC requests from the users to the server, which decides game state and replicates it either piecewise or in complete chunks to the users.
The fact that Apple has such a myriad of weird and non-cross platform tools to do even the simplest networking, doesn't inspire confidence that they could design something like the Torque Network Library. We had begun working with NetSprocket just before the dot bomb and Apple killing GameSprockets, and it turns out that it was a mixed blessing, because NetSprocket doesn't work with high latency. Today I wouldn't bother with any tool that has pre-decided metadata for players, like their names or even how many players there can be. It's better to go with something completely generic, and treat the metadata in special ways on a per-game basis, because often it's not really important. The user only cares about that when they go to do something, it works 100% of the time. Even a 99% success rate isn't good enough. They'll perceive the game as buggy and turn it off immediately.
The tool that the world needs, that doesn't exist, is a real cross platform p2p stream of some sort, similar to Skype. It would have caching, where each say 512 or 1024 byte block is checksummed and it could ask for it from anyone in the network and get it, for file downloads. Ideally it would be all wrapped up with a standard unix file descriptor interface, so you could open the channel on any device just like an ordinary socket, and it would handle reconnects where a user drops from one network and pops up on another (so every user is identified by their user id, not their IP address). Pretty much every cable/cell phone/nanny state organization in the world doesn't want this though, so you won't see it from them. I've seen hints of them over the years but I'm not aware of anything that fits the bill completely yet.
So good luck :-P
--Zack _______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden