I figured I'd make this discussion on the forums so that it's not just a discussion between Keith, Badger, and myself via email.
Badger notes that we really should have NAT punchthrough prior to starting the beta, because that's a big pain in the rear for getting multiplayer set up otherwise. I've noted in the past (prior to the kickstarter) that this was a possibility, but not one we've fully investigated yet, and it's something potentially very time-consuming as well as something with potential ongoing costs.
Basically, the way that NAT punchthrough works, to my knowledge, is via a few methods, which are similar to the private VPNs like Hamachi and whatnot:
1. There's some sort of server hosted somewhere, by Arcen or otherwise, and it keeps track of "game hosts" that say they want other people to be able to connect to them. So, for instance, Badger fires up the game and says he wants to connect.
2. Badger's friends then try to connect to him, via that relay server. At that point the relay server tries to broker a direct connection between Badger and his friends. If it's successful, then that's like getting a green dot in Hamachi. Basically there's no middleman, and because of the respective firewall and router configurations on both ends, things are all happy.
3. But it's also possible that even with the central server, the routers are not going to allow for this type of direct connection. There all manner of router and firewall setups, and there's no real centralized way to keep track of that stuff. So what happens in this case? Well, Badger can talk to the central relay server, and so can his friends, so they can pass messages to one another by talking to the relay and having it... well, relay... those messages on. This is the "yellow dot" situation in Hamachi.
As you can imagine, this introduces a lot of lag, but it ALSO means that all the bandwidth of the gameplay for Badger and his friends is now costing Arcen money directly while he's playing. We can't afford that sort of thing, and this is also the sort of thing that leads to game servers being shut down a few years down the road by AAA companies, and then everyone complaining.
The really large publishers maintain somewhat game-agnostic relay servers, as I understand it, so if they have 2 people playing a game they published 10 years ago, that's just a drop in the bucket on top of the 200k people who are playing their latest titles. Wheee. Steam also maintains relay servers and similar, but we don't use Steam networking, nor do we have any intention of doing so -- that locks us to Steam.
Remember my commentary about the "yellow dot" scenario, above? Well, in those circumstances ALL of the traffic is being routed through Steam instead of going through Forge Networking or similar on our end. This is... suboptimal. What about DRM-free copies of the game, for one thing? Also, Steam's networking is... not my first choice, for a variety of reasons.
Right now we're using a customized version of Forge Networking Remastered (
https://github.com/BeardedManStudios/ForgeNetworkingRemastered), which we bought (
https://www.assetstore.unity3d.com/en/#!/content/38344) but which is now apparently free and open source. They have a version of NAT punchthrough, but I don't know how robust it is:
http://docs.forgepowered.com/nat-hole-punching/There are other NAT Traversal solutions, such as this one, that are generalized, but mainly geared toward UNET:
https://www.assetstore.unity3d.com/en/#!/content/58948UNET is something we've found to be generally bloated and unreliable, so that wasn't something we wanted to go with. I think that the solution above could be made to work with FORGE, but I'm not sure it would be any better than the stuff built into FORGE. And in ALL of those cases, I'm not sure that this would be zero-cost to Arcen, which is the only way we can guarantee that 20 years from now the networking will still work. We're small!
With that in mind, I'm open to solutions and suggestions. There are various personal VPNs that might have APIs that could be integrated, for instance. Ideally whatever is going on is invisible to the FORGE networking layer (it just thinks it's talking directly to the clients, in other words), like was the case for Hamachi and Wippien and similar.
Next we come to what is essentially a manpower issue:
Now that FORGE is open source, if there are any programmers in the audience here who would like to take a stab at seeing what they can get working with it, and if they can improve things over what Keith has had time to do, then it's certainly worth an attempt at least. We're shortstaffed in this area, and I think that this particular feature is pretty much just not going to happen (I have a gut feel) if someone external isn't able to volunteer their time and expertise. Personally I'd rather have Keith focusing on the game itself, and the AI and whatnot, and other things he's more directly suited to.
