Quote:forwarding is the only way
Not true. Proper multi-player games support NAT peer-to-peer punch-through.
As, might I add, is explained in the Networking forum FAQ, so perhaps moving to this forum was exactly the right thing to do.
Network Programming.
Not true. Proper multi-player games support NAT peer-to-peer punch-through.
As, might I add, is explained in the Networking forum FAQ, so perhaps moving to this forum was exactly the right thing to do.
Quote:Original post by hplus0603Quote:forwarding is the only way
Not true. Proper multi-player games support NAT peer-to-peer punch-through.
As, might I add, is explained in the Networking forum FAQ, so perhaps moving to this forum was exactly the right thing to do.
Yes, but to be able to do the punch through you have to go through a host. Otherwise both sides don't know to open the connection simultaneusly. So, hosting behind the NAT is out of question, unless you have a third server outside the NAT that initates the connection. That is usually true if you use some kind of master server or other matchmaking system, that you have control of and integrated into your game properly. However if you are writing a standalone server, then port-forwarding is the only way to go.
That's why services like GameSpy.net exist, as well as Battle.net (although they don't actually use Battle.net to do UDP punch-through).
Anyway, wouldn't you want the game registration server to run under your control anyway? That way, you can ban stolen registration codes and stuff, as well as keep a good gauge on what your game community is up to.
Anyway, wouldn't you want the game registration server to run under your control anyway? That way, you can ban stolen registration codes and stuff, as well as keep a good gauge on what your game community is up to.
That's certainly true for commercial games. But if you are writing an independent game, then you might not have the luxury of having a contract with "one of the big" or being able to host your own matchmaking service.
And now slightly off-topic.
Even if you are in a commercial game project, there might be problems, as those services are EXPENSIVE. And getting the publisher convinced is not the easiest project in the world. It really hurts to program a game that works with XBox Live. And then be forced to just support LAN on PC, even if almost everything is done, just the matchmaking part is missing. The only thing I could do was to make some commandline options so that you at least can play online if you want, and know your friends ip. And yes the actual network code supports NAT punch-through.
And now slightly off-topic.
Even if you are in a commercial game project, there might be problems, as those services are EXPENSIVE. And getting the publisher convinced is not the easiest project in the world. It really hurts to program a game that works with XBox Live. And then be forced to just support LAN on PC, even if almost everything is done, just the matchmaking part is missing. The only thing I could do was to make some commandline options so that you at least can play online if you want, and know your friends ip. And yes the actual network code supports NAT punch-through.
Maybe you could bring Open Source to the rescue? Write a simple matchmaking protocol, and document it. Then release an open-source matchmaker server that people can compile and run on open hardware they have available. If the game is any good, servers are likely to show up.
Have a dialog box where the user can enter the name and port of a matchmaker, and remember it when re-launching the application, so it won't have to be done more than once.
Have a dialog box where the user can enter the name and port of a matchmaker, and remember it when re-launching the application, so it won't have to be done more than once.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
