   Transmitting game info from server (Java) to client (Flash)
  I'm putting together a basic system to get some practice working with sockets and the problems of near real time multiplayer Flash games.I've gotten a basic chat application working using sockets and wonder what people feel the best way to send info from server to client about the state of game entities.Here's my current idea:Assemble a message as a string with delimiters.  The first field tells the client what kind of a message this is, e.g., add a new entity, update an existing entity, remove an existing entity, chat message, etc.  The remaining fields are string representations of data relevant to the particular message.For example (using spaces as delimiters) "1 232221 3 30.571 29.341 1.51 2.533" might be translated as: (1 = Create new entity) with id 232221, owner id 3, x = 30.571, y = 29.341, angle = 1.51, speed = 2.533.Is this a good system?  If not, what improvement would you recommend?  What's a logical delimiter?    
  Did you look at Blaze DS?It might be better and easier to use a 'standard' protocol and stack provided it fits your requirements of course.Blaze DS;  If you want to use strings space will work fine as a delimeter.I'd suggest instead sending your messages in binary. You'll save bandwidth and it'll be faster for both the server and client to interpret.You've said you're already using flash sockets, so look at readByte, readInt, etc.   ;Quote:Original post by ernowDid you look at Blaze DS?It might be better and easier to use a 'standard' protocol and stack provided it fits your requirements of course.Blaze DSI hadn't looked at Blaze DS.  There doesn't seem to be a lot of hits on BlazeDS and games, so I'm wondering if it's an appropriate fit.  Is there a lot of overhead to BlazeDS?   ;Quote:Original post by justkevinI hadn't looked at Blaze DS.  There doesn't seem to be a lot of hits on BlazeDS and games, so I'm wondering if it's an appropriate fit.  Is there a lot of overhead to BlazeDS?Since it's binary protocol, almost certainly less that your proposal, but still more than custom binary protocol would have.If bandwidth is an absolute premium, then the biggest savings will probably come from sending only minimal amount of data possible. And, as can be recently discussed, if most of messages are small, protocol headers will play most of overhead, so finding good batching heuristics will bring most benefits.The minimal deciding factor should be whether its RMI supports asynchronous invocations and how robust or tolerant it is. In case of lost packet, does it wait for resend? Does it give access to buffering strategy to manually control latency vs. overhead trade-off?   ;Quote:Original post by flat2If you want to use strings space will work fine as a delimeter.I'd suggest instead sending your messages in binary. You'll save bandwidth and it'll be faster for both the server and client to interpret.You've said you're already using flash sockets, so look at readByte, readInt, etc.I considered this. I'm thinking for my first app I should stick with strings for simplicity.;Quote:Original post by justkevinQuote:Original post by flat2If you want to use strings space will work fine as a delimeter.I'd suggest instead sending your messages in binary. You'll save bandwidth and it'll be faster for both the server and client to interpret.You've said you're already using flash sockets, so look at readByte, readInt, etc.I considered this. I'm thinking for my first app I should stick with strings for simplicity.That's the problem it's not simpler. Actually if you read over Binary Packet article on the wiki it'll give you the basic idea. I've been meaning to update my AS3 binary packet to use the new algorithms. Once you decide on a format and have the classes written it's really nice and compact to write messages both sides can understand. On the AS3 side I've always implemented my binary readers/writers on top of the AS3 bytearray class. Since you're using java the C# code in that article will probably look very familiar. (If you go down this route and get confused I'm on irc.afternet.org #gamedev)   ;  Okay, I'll try a byte based approach. I was originally discouraged when my initial efforts produced garbage on the client, but I have since discovered that the method I was using was converting my data to text.  If I get really bold I'll try Sirisian's binary packet solution.   ;  Personally I am using the same method you described, a custom format like this:CHAT|nick|messageROOM|nickHELO|nickGBYE|nickNGAM|nick|gameidPLAY|nick|moveUsing 4 letters for the action and pipes as delimiters, message.split("|") on the client and switch(action) for processing it.So it all depends on your taste, for me it works fine both on the server and the client without any additional headaches.;  Some questions about your protocol:What happens if I register a nick containing a "|" ?What happens if I send a chat message containing a "|"?Worse, what happens if I send a chat message containing a newline, followed by a GBYE|your-nick ?Assuming you have one TCP connection per client, where name/password is already established, couldn't you just drop the "nick" parts from the protocol?