Hi,
I was just wondering how far away the multiplayer code is from being complete?
I like the JonoF port much better than the Rancidmeat port. Looks much better.
I can't wait to blast my friends in Rabid Transit again!
Good luck with the code!
Nxskingdom at
They are working very hard (Jonof and Ken). We just need to be patient until it go out :)
TX at
Soonish. The current state of the code is decent enough to play, though occasionally the game still goes out of sync. At least that was the last I heard of it, which was.. oh, a week ago, I think.
Anonymous at
Woo hoo!
Glad to hear it's not dead!
Can't wait! =)
JonoF at
The hold up for a test release is not actually the netcode itself at the moment. There's a few annoying problems elsewhere I need to fix before I can put together something for people to play with. So, a test for the netcode isn't too far away actually.
Jonathon
P-J at
JonoF : A question I've always wanted to ask-- I'm not a networking expert, but I notice a lot (all?) games prefer to use UDP over TCP.
I think I know that UDP is faster but has less error compensation, and TCP is more solid but slower. If I'm correct in my assumption, wouldn't TCP be suitable in this day and age of high-speed internet?
Apologies if I really don't know what I'm talking about :)
JonoF at
TCP is a reliable data protocol, so it errs on the side of safety rather than performance. TCP will wait until the next packet it's expecting arrives from the network, which could be forever if things really go bad. With UDP, the game accepts the responsibility for checking the packets for errors, and resending lost messages, which in Build we do by sending redundant information with the hope that if a message is lost in transit, there'll be another one behind it that would have a duplicate on hand to bring up the slack. This equates to smoother gameplay when errors or loss occurs.
Jonathon
P-J at
JonoF said
TCP is a reliable data protocol, so it errs on the side of safety rather than performance. TCP will wait until the next packet it's expecting arrives from the network, which could be forever if things really go bad. With UDP, the game accepts the responsibility for checking the packets for errors, and resending lost messages, which in Build we do by sending redundant information with the hope that if a message is lost in transit, there'll be another one behind it that would have a duplicate on hand to bring up the slack. This equates to smoother gameplay when errors or loss occurs.
Right, I get it. So then what 'problems' could be caused by using TCP in your 'average' multiplayer environment-- As in how they would manifest themselves in the game/app if the worst happened?
(p.s. Sorry if I'm bothering you!)
addfaz at
P-J said
Right, I get it. So then what 'problems' could be caused by using TCP in your 'average' multiplayer environment-- As in how they would manifest themselves in the game/app if the worst happened?
(p.s. Sorry if I'm bothering you!)
AFAIK, the faster internet connection you have the less difference in performance you'll notice between UDP and TCP.
It all depends on the end product. Do you want an application/game that is able to suffer the loss of random packets (use UDP) or do you want it to be solid (use TCP)?
You have to think about how often will you need to send packets. If its just for updating movement then resending an old packet using UDP will be useless, since you could be 2 or 3 seconds in front of where you were. You dont want to backtrack :P. Only actions need to have some sort of support of transport.
TCP consumes more bandwidth when sending/receiving packets, due to the increased size of headers in each packet.
As mentioned, if one TCP packet gets held up at any point, so are all the ones following it. You may suddenly get a burst of packets coming towards you :P This is a bad bottleneck where gaming is concerned.
You have got to consider security as well. I would imagine TCP is much harder to "hack" since you have to literally make a connection with the host. Where as UDP will accept any packet sent to it. You will need some sort of packet security measure, and some method of dropping bad/incomplete packets.
Even tho TCP is far superior than UDP in many ways, for multiplayer gaming i'd go for UDP, simply because of its speed.
Anonymous at
Wow, JonoF and creator of Dukester on the same thread. How cool :)
Thanks for the info-- I've been working on a few projects which are getting to the stage where I need to implement multiplayer and wondered which way to go. They're relatively simple in terms of what data needs to be transmitted every 'cycle' so perhaps I'll try TCP-- Or maybe both.
Speaking of Dukester, and I know this isn't the place, but now I have you here :)
Here's a feature I think would be cool.
Say you split Dukester into a client and server, or a single program that turned into a client or server depending on usage. An owner of a server somewhere could set up a dukester server (on a standalone machine without Duke 3D) and people could connect to it. The administrator of the game (the person who sets levels and starts the game) would be in charge of the server. If the administrator wasn't connected, the first person to connect to the server could become the administrator, and he would be 'kicked out' of that position of someone with higher rights on the server connected.
I imagine the administrator(s) could be authenticated by password or by IP address, and maybe there could be a hierarchy of administrators.
Anyway once the game is set to go, the administrator of the game could then start it and his Duke 3D installation would become the master, exactly like it does with Dukester at the moment.
I hope you understand what I'm suggesting-- Not a standalone Duke 3D server, that would be too much work-- But a standalone Dukester server that people could meet on regardless of whether the owner of the server was 'available'.
Hope you like the idea :)
P-J at
Poo to guest accounts :) That's me above.
addfaz at
My aim is to create a Kali for Duke Ports
Expect in the end an application simular to that. That is you create a lobby, within lobbies you host and join chat and game servers. Lobbies and its contents will be recorded on a central website for tracking.
:)
Nxskingdom at
Hello addfaz! :)
I think that you and I are just waiting for the multiplayer code. I'm learning C++ language but I think that VB stay the best for applications in windows.
C language is much more powerful but VB is very easy to use.
Good luck with Dukester :P
addfaz at
Nxskingdom said
Hello addfaz! :)
I think that you and I are just waiting for the multiplayer code. I'm learning C++ language but I think that VB stay the best for applications in windows.
C language is much more powerful but VB is very easy to use.
Good luck with Dukester :P
Hey King, nice to hear from you :) howz ACRSetup going? you aint had any updates for a few months.
I myself haven't got my head around C yet :( i would really like to get to know it better :D
TX at
Nxskingdom said
Hello addfaz! :)
I think that VB stay the best for applications in windows.
Sure, if you don't mind that your app ends up extremely slow. VB is certainly not up to anything computationally intensive.
addfaz at
i just don't like the fact that VB applications require the VB runtime libraries for successful execution. This seems to put most ppl off. But for now i have to live with it :roll:
Execution speed hasn't been an issue for the type of applications ive done in the past.
Definitely gona look into changing languages like...
Nxskingdom at
addfaz said
Nxskingdom said
Hello addfaz! :)
I think that you and I are just waiting for the multiplayer code. I'm learning C++ language but I think that VB stay the best for applications in windows.
C language is much more powerful but VB is very easy to use.
Good luck with Dukester :P
Hey King, nice to hear from you :) howz ACRSetup going? you aint had any updates for a few months.
I myself haven't got my head around C yet :( i would really like to get to know it better :D
I don't have time to make some kind of updates. I'm currently working for an electronics company (electronics engeneering). ACRSetup will be updated when Jonof and Ken publish their multiplayer code. I'll just make some changes to accept Jonof Port to be launched in multiplayer. Maybe i'll add some options too.
If you need some help for dukester (part of codes, tests or anything else) just tell me. Duekster is the way to go :)
Lune- at
TX said
Sure, if you don't mind that your app ends up extremely slow. VB is certainly not up to
anything computationally intensive.
you know, you CAN use dll's in VB, and you can code these in say c++ or asm
I've been fondeling a bit with directx, and with vb cause you know :lol: and it worked like a charm. not lightning fast but fast enough if you optimise (and yes, you can optimise)