FPS MMO, UDP vs TCP, yes ive read the monster thread above

[VoS]

Ok, first off.  Phew that was a long read, just spent  a good half hour of my life reading all of the UDP vs TCP thread and i feel like ive gotten a little smarter about it..

I like every other programmer it seems want to make a game.
If i come anywhere near what i want to do it will be an MMO style FPS game. Where your mouse clicking speed is of utmost importance. Like any other fps game out there.

What i want to do is have a bunch of players in the same world (MMO) shooting at each other and gaining levels. Where the shooting is done like any other FPS game where you aim your cursor at the player and click of a few rounds.

After reading all of the 5(or so) pages ive basically come to the conclusion that im not sure wtf i want.

UDP: good if i can loose data and gives minimal bonus in latency, going to need to do extra for messages that need to arrive, like gun shots and chat.

TCP: a hell of alot easier to implement, but can be a bitch b/c of lag (the whole lost packet #5 thing).

Well in my game i would probably be better of with UDP but i would need to make a reliable ack method of deliviering data as well for the gun fires and chat messages. As im hoping to have many players ive also understood it that UDP is better since it causes less performance issues on the server (less overhead, computation, memory, etc..)

I also read the article on Quake 3 networking model http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking it dosent seem like anything to reinventing but about the same things i was thinking of doing if i was to use UDP myself. But is it a good thing over the internet? They speak mostly of LAN play.

Also in the big UDP vs TCP thread someone said that they would use TCP for all their networking needs if they could turn of the packets in order thing, is there no way to do this? Are there no java classes that put just this functionality on top of UDP, would seem to me that there are way to many smart people in the world for this not to have been done.

Well this whole post can be summed up with, im confused. I want to make my little (maybe not so little) game but im stuck in the planning stage.

Thanks for your help

[Riven]

JGN has a few classes that offer Reliable messages over UDP.


The only problem with JGN is that it lacks proper documentation, but you might get started with the test-cases in the sourcecode (it is opensource).

[ChrisM]

The biggest issue is trying to combine two very different styles, from a server perspective, that happen to align well from a gameplay perspective.  The reality is that you don't need everything in a FPS environment that you do need in a MMO environment (persistence, transaction integrity, etc.).  One way to accomplish this kind of environment is to think about hub world style segmentation of your game universe (look at Phantasy Star Online for a good example) where things persist in the MMO space, but battles take place in instanced environments.

Games published by our own members! Check 'em out!

[VoS]

My plan was to have it all in the same world without instances.

So what im really after is a way to send data through UDP as normal UDP would send (not guaranteed)  but also have a special method through with data can be sent in such a way that it will arrive at some point in time. As soon as the word guranteed delivery enters the vocabulary you get problems with sliding windows and over spamming the network. It would also seem to me to be a little bit slower since then you need to keep a record of the packet that needs to be sent if there is no ACK message returned and do a little more processing on the data than if i would just send it (this is written into the TCP protocol for TCP and not in java as this 'fix' would be for UDP hence my though of it slowing down compared to TCP). This also seems like it could grow to astronomical proportions when doing this on a full scale server with something small like 200+ connections (gigantic list of unacknowledged data).

I also visited the JGN site and saw a few interesting ideas and things im going to be playing around with, thanks

[ChrisM]

My plan was to have it all in the same world without instances.

So what im really after is a way to send data through UDP as normal UDP would send (not guaranteed)  but also have a special method through with data can be sent in such a way that it will arrive at some point in time. As soon as the word guranteed delivery enters the vocabulary you get problems with sliding windows and over spamming the network. It would also seem to me to be a little bit slower since then you need to keep a record of the packet that needs to be sent if there is no ACK message returned and do a little more processing on the data than if i would just send it (this is written into the TCP protocol for TCP and not in java as this 'fix' would be for UDP hence my though of it slowing down compared to TCP). This also seems like it could grow to astronomical proportions when doing this on a full scale server with something small like 200+ connections (gigantic list of unacknowledged data).

I also visited the JGN site and saw a few interesting ideas and things im going to be playing around with, thanks

I wish you luck in this   Persistence and transaction integrity are the two biggest things needed in the MMO side of your game as it is what adds validity to item acquisition and build up of work.  I would be very interested to see how you separate out the FPS transactions form the MMO ones.  Here's hoping you publish your findings!

-Chris

[VoS]

I wish you luck in this

probably going to need that.

At first when thinking about it it dosent seem to difficult.

all outgoing 'guaranteed messages' get an incrementing id
all outgoing guaranteed messages are placed in a hashtable with their id's as indexes.
if a message with something like 'ACK <id#>' arrives remove the entry for that id.

That dosent seem to hard, could probably whip that up in a few minutes. The problem comes with the resending of unaknowledged packets.

You could brute force it like the quake3 boys did, resend all unackowledged packets every 100ms (or less) untill they are acknowledged or the client drops. This does seem like the easiest and best way to make sure packets get there in time critical applications. But how would that look over the net, especially if there are a few hundred clients. I'm pretty sure my server wouldent be to happy with me. Any better ideas are greatly appreciated.

And dealing with the case of lost ack's dosent get to complicated this way either.
lets say im sending messages with the following syntax  '<ackFlag> <type> <id> <message>'.
ackFlag is 0 or 1, if it is 0 the client or server whoever received it dont care about acknowlading the packet, they just deal with it.
if the flag is 1 they send a response message with the id of the packet. Even if they did receive it before they send the ack ( takes out lost ack problem ) but then they later discard it when they notice that the id of the packet is old.

Thinking about this i also realised another problem. What if an older guranteed message arrives after a new one, its ID would be older than the new one that arrived before it and hence it would be difficuclt to tell with just an incrementing ID if it had already been dealt with. Best way (a way atleast) to remove this could be too keep the last 20 seconds worth of received ID's in a table and test all incomming messages against it, if it isent in table it hasent been received, if it is, drop it like its radioactive.

I'm at the moment not sure how else to go about guranteeing UDP messages.

To restate what others have said before for non guranteed UDP, all you have to do is send the messages with incrementing ID, if an ID of a packet is lower than a previously accepted packet its old, discard it.

My biggest problem, or what i think is the MOST unpretty about this is the way i would test if ive already received a guranteed packet. theres gotta be a better way to do that.

//VoS

[sunsett]

Riven, thanks for the mention of JGN.

VoS, I'm the creator and main sustainer of JGN and though it's lacking in documentation it's growing pretty quickly lately due to some very kind users on the JGN forums.  There's not a whole lot yet to see, but check out http://www.javagn.org to see some extra documentation.  Like Riven said though the best place to start is in the source code there are tons of tests.  I don't spend a whole lot of time on here, but on the JGN forums I am always there (my nickname on there is darkfrog).