From: <Cir...@cs...> - 2005-04-02 22:10:56
|
Well, about that essay: 1) Nothing in it is applicable to Once due to its current design, = except possibly for the 200 UDP connections - but 200 UDP or 200 TCP - = what's the difference? TCP behaves badly when you have long lags (5s = or more on round trip) - admittedly you wouldn't play under those = conditions... 2) The discussion on UDP vs TCP doesn't make any sense at all. I have = used sockets a fair bit over the years (although I never made much use = of UDP until now - normally I only use it to broadcast messages to = discover services like DHCP etc) so I had to learn quick about this = 'reliable UDP' stuff and ask all sorts of questions - and one great = thing about UDP is that a lot of data sent can be lost and we don't care = - for them we use unreliable packets (normal UDP) and if they're lost - = so what. TCP would guarantee that they are sent, so network glitches = can cause some situations which are much more annoying with TCP than = UDP. In RakNet, we send all unreliable packets as 'ordered' - if the = packet is an unreliable type and comes after an unreliable packet which = was sent later, the packet is dropped - our server never knows about it = and doesn't have to handle it, which is the correct behavior. In TCP = time is wasted guaranteeing the retransmission and order of that packet = even though the packet is not very important. =20 As for gaining levels by sending a message multiple times - that is = only possible through incredibly bad game design and as easy to do with = TCP as with UDP - the network is really not an issue in that case. As = for 'real-time', that is only an illusion. There is lag and we can't = beat that (in fact there have been some bad days with PS where the lag = is really annoying). Effects need to be created in such a way that = even if people move a little etc, you get the impression that the target = was hit; equally important you want it to look like the target was = missed if in fact you missed it. You don't want a player screaming "I = saw my arrow hit him but I got the message 'you missed' !" You also = want to avoid the situation where you killed your opponent and suddenly = you see a spell that he cast hit you. Most of the illusion (especially = with spells) is created by building a lag into your actions. For = example, you begin to draw your bow - it's annying that you don't fire = instantaneously because it gives the enemy a chance to move - just like = in the 'real' world. Because you know that, you're annoyed but not angry = when you see the arrow miss, and you're very happy if you see it hit.=20 I won't say anymore about network stuff - we have decided on our new = net library and it works well. You can read articles on = www.gamasutra.com if you want to know what the commercial game = developers have to say on the TCP vs UDP topic. |
From: Bryan D. <duf...@um...> - 2005-04-04 18:49:10
|
I agree. What Cirilo says is correct (to my knowledge). And as far as the "split" server idea: where you have a chat server, mod = server, game server, whatever; I think we are better off with a unified=20 server where everything is together. This of course depends on=20 performance, but we can't assume that everyone starting a Once server=20 will want to host 200 players. One important thing to not is that PS's=20 npcclient is run locally with their current server, while they may be=20 able to run it remotely, I'm not sure if it's worth the performance=20 negation of handling connections/data. I'm going to research this=20 further, but my current guess is that we would be better off having at=20 least simple AI in the server (like animals, and monsters): I believe PS = works this way. As for NPC's, we will probably -in the end- want to=20 allow for both internal and externally run NPC's. Still that will=20 require some looking into. Although from a development/support side,=20 one "unified" server with all the services would be the best. Why run a = separate chat server, when you can just run 2 smaller servers. You'll=20 still need to travel from server to server anyway, so this split server=20 idea seems only to make development more difficult and unmanagable. Also, I'm curious about traveling from server to server. One very=20 important thing to remember. Other servers can't be trusted. Since=20 it's open source, I could start my own server, create a character -beef=20 him up with some server hacks- and send him to the main server. Thus=20 we'll need some way to trust other servers. I'm not sure how will do=20 this: it could be as simple as having a "whitelist" of trusted server=20 ip's; or more complex, such as a PGP key. Another thing, running a unified server will use much less bandwith,=20 which may be an issue for people running a smaller server via their=20 DSL/Cable connection. This I would like to not rule out as an option. =20 With decent AI in place, I would think it would still be fun to have=20 only like 20 people. A MMORPG doesn't have to be "Massive" to be=20 enjoyable, imho. -Bryan (duffolonious) Cir...@cs... wrote: >Well, about that essay: > >1) Nothing in it is applicable to Once due to its current design, excep= t possibly for the 200 UDP connections - but 200 UDP or 200 TCP - what's = the difference? TCP behaves badly when you have long lags (5s or more o= n round trip) - admittedly you wouldn't play under those conditions... > >2) The discussion on UDP vs TCP doesn't make any sense at all. I have = used sockets a fair bit over the years (although I never made much use of= UDP until now - normally I only use it to broadcast messages to discover= services like DHCP etc) so I had to learn quick about this 'reliable UDP= ' stuff and ask all sorts of questions - and one great thing about UDP is= that a lot of data sent can be lost and we don't care - for them we use = unreliable packets (normal UDP) and if they're lost - so what. TCP would= guarantee that they are sent, so network glitches can cause some situati= ons which are much more annoying with TCP than UDP. In RakNet, we send a= ll unreliable packets as 'ordered' - if the packet is an unreliable type = and comes after an unreliable packet which was sent later, the packet is= dropped - our server never knows about it and doesn't have to handle it,= which is the correct behavior. In TCP time is wasted guaranteeing the r= etransmission and order of that packet even though the packet is not very= important. =20 > > As for gaining levels by sending a message multiple times - that is onl= y possible through incredibly bad game design and as easy to do with TCP = as with UDP - the network is really not an issue in that case. As for 'r= eal-time', that is only an illusion. There is lag and we can't beat that = (in fact there have been some bad days with PS where the lag is really an= noying). Effects need to be created in such a way that even if people m= ove a little etc, you get the impression that the target was hit; equally= important you want it to look like the target was missed if in fact you = missed it. You don't want a player screaming "I saw my arrow hit him but= I got the message 'you missed' !" You also want to avoid the situation= where you killed your opponent and suddenly you see a spell that he cast= hit you. Most of the illusion (especially with spells) is created by bu= ilding a lag into your actions. For example, you begin to draw your bow = - it's annying that you don't fire instantaneously because it gives the e= nemy a chance to move - just like in the 'real' world. Because you know t= hat, you're annoyed but not angry when you see the arrow miss, and you're= very happy if you see it hit.=20 > > I won't say anymore about network stuff - we have decided on our new n= et library and it works well. You can read articles on www.gamasutra.com= if you want to know what the commercial game developers have to say on = the TCP vs UDP topic. > > > =20 > |