Would like assistance vetting MMF2d against idea

[Glenshadow]

Patrick,

UDP isn't really 'unstable'... It's just not a guaranteed way to send information across the internet.

TCP is very, VERY good for non-action oriented games, like RPGs, because every little bit of information is important, and needs to be delivered. It is also 'slow' (compared to UDP) because it gaurantees that every single packet will make it from the client to the server and vice-versa.

UDP is much 'faster' because it doesn't guarantee delivery of the packet. This isn't a problem in an action game typically because you are sending a whole lot more packets. For example, if you have an object sending it's x,y coordinates 20 times per second in an action game, it doesn't matter if a few of them drop, because there's always another packet right behind it, only 1/20th of a second (or what have you) away.

UDP = Action
TCP = RPG

You could in certain circumstances use both protocals for certain things in both games, but generally, what I've typed above is accurate.

I should also say, in the interest of completedness, that UDP and TCP travel at exactly the same 'speed' across the internet. UDP isn't really 'faster' and TCP isn't really 'slower', they just *appear* that way because one is a guaranteed method of delivery, and one isn't.

UDP could be enterpreted as less 'stable' than TCP, but it is that way by design... It's not a flaw that it works the way that it does.

[Patrick]

Yes, what i was tring to tell is that i am not sure if MooClick still supports UDP in this way (because of what -if i remember right- apeared to be a problem) so i can't help you at this point then Maybe someone else knows how to get MMF2 working trough UDP.

[Glenshadow]

hhhmmm... I think I read in the documentation that MooClick had UDP support. Perhaps someone here can confirm for me one way or the other as that is a big selling point for me.

Without UDP I might as well use Flash. Flash doesn't support UDP (without some kind of projector wrapper) which is one of the main reasons I'm looking at MMC2d.

[Random]

From what I see "blast text" is still available, which I believe is the "interface" for MooClick's UDP. MooGame explicitly has UDP mode.

MooClick requires its own type of server. This is (when MMF2 compiled) Win32 exe. This cannot run on Linux server without the use of an emulation app like Wine.
I suggest you go for Windows2003 servers also.

I don't think so. Someone should try it out properly, but last time I checked MooSock it was nothing you can't handle with a non Moo-supported program. I doubt MooClick is in any way encrypted or otherwise unreadable. Plus a MooAPI server is available for linux (called mos4linux). It supports both MooClick and MooGame.

[Blizna]

Random is right, MooClick doesnt require its own type of server. When you grab the message headers and all the stuff, you can do your server in C++, Java...

[Glenshadow]

I spent the night pouring over the moo docs and doing some experiments of my own. So far everything looks very good.

It appears that mooclick does indeed handle TCP and UDP, over the same port. With 'send' representing TCP and 'blast' representing UDP. There also appears to be a built in parser that takes a simple delimiter, so that's also good.

Unless the documentation is horribly out of date or flat our wrong, I think I'll be able to get most if not all of this done without coding my own extensions.

I've been sniffing the packet information that moo sends out, and it's definately not encrypted, so I'd have to agree with Random and Blizna that I could potentially write the client or the server, or both (technically speaking, not necessarily performance-wise), in MMF2d.

[Blizna]

Yes, MooClick has nice ability to "parse" the subchannels (if this is what you are talking about), also you dont need to do it manually. Just use channel 10 for chat, channel 15 for shooting etc..With smart coding -sending (however just UDP) only when needed,also only when player really moves or changes direction it is definitely possible to make nice game. When my game runs so nicely with TCP/IP server with 40+ people permanently (where even each movement step is server checked), then has to be absolutely OK.

[Glenshadow]

Bliza I was referring to delimiters in a single sent string when referring parsing, ie, when you send something like this:

foo,bar

If that is sent from client to server, then the comma "," is the delimiter.

You bring up something interesting though, the whole 'channels' thing. I haven't really got my head wrapped around that one yet. What would be the benefit, or even the point, in utilizing 'channels'?

The process normally goes like this:

1) Client sends a packet to the server
2) Server parses the packet, potentially takes an action, and then potentially forwards that packet on to the rest of the clients
3) The other clients recieve and parse the packet, and take whatever action is prudent

So where and why would channels fit into that?

[Blizna]

Well, if this is delimiter, then you cant use it in MMF normally, there is String parser for it.

Channels? Say, you send text "BLA" to server. Server recieves it on event On Client message. Then server do something.

But when you add condition On Client message
+Subchannel=5 --- do A

On Client message
+Subchannel=6 --- do B


Like if you send data on suchannel 6, server will automatically procceed them as a movement and do the rest, you dont need compare the content of message.

[Glenshadow]

You can't use a comma for the delimiter?

What about this:
http://www.create-games.com/article.asp?id=1591

Isn't that a pretty commonly referenced tutorial? He uses commas for this delimter:

- String Parser 2: Add delimiter ,

Or perhaps I'm misunderstanding you somehow?

. . .

Thank you for the explanation of channels! That makes a lot of sense, the way you illustrated their use. I would normally in other languages use a case statement for something that, but I see that is what channels are substituting for ultimatley (at least in the way I normally program).