As this is my first post I just wanted to say a big thank you to the jmonkeyengine guys for all the work they have done. I only picked it up a few weeks ago and was surprised how easy it was to build a 3D world with water/light/random terrain/etc which I could explore.
Anyway I’ve started looking into the multiplayer side of things, I figured it would be easier to get this working first before I continued doing any work on my project. The basic aim is to be able to have 4 players in a world.
So I created a server, using spider monkey, and have been following articles and tutorials online about what data should be sent to and from the server, how to combat cheating, client predictions and lag compensation.
At the moment the client connects to the server and every time a user presses a button this is sent to the server (eg when the forward button is pressed and again when it is released). The server, which extends SimpleApplication, has a copy of the map loaded, runs the physics and every time the users position changes sends it back to the client.
At the moment, for simplicity sakes, i’m not doing any client prediction or lag compensation. So my first question (of many, sorry) is should the server be doing all the physics simulations? I intent to add client prediction later, but is it good practise to have the server doing all the grunt work with collision detections.
Secondly how often should the server be sending the client a position update, at the moment it’s doing it on every iteration of simpleUpdate but i’ve read in some articles that the server should send an update at fixed intervals, e.g every 50ms.
So at the moment I can connect to my server, over LAN, have the server run all the physics and update the client constantly and the game runs smoothly. However this is because it is connecting over LAN, I wanted to connect over the internet to see how bad the lag is and see what kind of lag compensation I need however if I use my IP in:
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
So my final question is, any ideas what's causing this? My guess is it's a problem with my firewall/router (BT HomeHub and macbook pro w/ Lion)
But is there anything I need to configure on the server to allow me to connect over the Internet? I can post code if people want to see it.
Sorry for the monolithic post but I wanted to get these things sorted in my mind before I waste hours doing it wrong.
1) Should the server run all the physics
2) How often should the server update the clients
3) Cannot connect to my server over the Internet, just Lion
Is the first error in the quoted log the first error that you saw?
I think I’ve seen a similar error before. There’s a particular player who connects to my server and something goes sour with his connection. From then on I get these messages. They are harmless other than that they dirty up the logs and console… but I’d like to know why they happen and attempt a fix.
It’s basically saying that the network layer received a packet over UDP but that it doesn’t contain a full message. This shouldn’t happen really because UDP packets are delivered in total or not at all. I’ve often suspected that something else is at play.
physics : sent only the data that were altered in the world.
a) not only that, the question is in what type of messages will you have.
position / velocity ( every 100-200 ms)
physics (every 500-700ms).
because ipv4 sucks, nat forbids you from delivering data to your machine. you have to go to your router and tell it to redirect data to your machine. Too bad that 99% of users dont know how to do that.
For your first questions… what kind of game is it? A lot of that depends.
For the last question, as tralala indicates, your firewall needs to know how to route the connections to the server that sits behind it. The internet sees you as one address and your LAN sees you as another. For whatever ports your server opens, you need to forward those through your firewall/router. Note that this is only a requirement for the server… clients through a NAT should work just fine as long as they find the server.
For example, I host a mythruna public server through my cable connection. I have a machine on my LAN running the server and listening on port 4234. In my router, I’ve configured it to forward any UDP and TCP data for port 4234 to go directly to that machine on my LAN. So when a user connects to my cable modem on :4234 they are actually connecting to a machine on my LAN with the NAT firewall making sure the packets go back and forth like they should. Your router should have some way of configuring this.
re: network architecture…
If you are not relying on the “twitch factor” like a FPS then you can get away with a slightly simpler architecture since at best you only do prediction on the client.
Still, I’m rather fond of the UDP state updates at fixed intervals. The key here is that you are still sending the same number of updates but you are bundling them into less frequent messages. So if your physics runs at 60 FPS and you are only sending state messages at 20 FPS (50 ms) then you’d be sending three updates per message. You can do this with the state that the client sends to the server and also the state that the server sends to the client.
Though there is nothing wrong with blasting every state update like you are… though I’d hope it’s UDP and not TCP for these updates. I do this with Mythruna right now… I’ve designed to bundle but I know on at least one direction that I’m not doing it.
You sound like you already read these but I’m including them just in case:
For a non-FPS game you can probably ignore the server side prediction stuff.
And yeah, I think the server should be doing the physics so that it can be authoritative. It’s your best defense against rampant cheating or just strange paradoxes. The client can still do it too for prediction but the server is “law” if there are conflicts.
For example, I host a mythruna public server through my cable connection. I have a machine on my LAN running the server and listening on port 4234. In my router, I've configured it to forward any UDP and TCP data for port 4234 to go directly to that machine on my LAN. So when a user connects to my cable modem on :4234 they are actually connecting to a machine on my LAN with the NAT firewall making sure the packets go back and forth like they should. Your router should have some way of configuring this.
Is there a particular name for this method so I can google how to do it on my router, it sounds like port forwarding to me.
At the moment it's TCP, but the only reason it's that was so I could check the server and client were working properly and know all the packets were being received. I will be switching to UDP soon and implementing the basic TCP-esq reliability features myself on top of UDP.
With respect to sending messages at fixed intervals I think i'm going to get my server to work over the Internet first, determine how bad the lag is then experiment to find a solution which works best for my game.
Port forwarding should be pretty good. Most routers that I’m familiar with have a configuration web page you can hit and set these things.
I wouldn’t implement your own TCP on top of UDP… you might as well just use TCP. UDP is good for the data that is stale the moment the next packet comes in.
There are two basic schemes: TCP and only send changes in state and just deal with the extra lag through client prediction. UDP always send the latest state for everything the player can see… if a packet gets lost then there’s no big deal because another one is already on its way. This second case is what the Valve articles describe.
I will be switching to UDP soon and implementing the basic TCP-esq reliability features myself on top of UDP.
You will re-implemented the wheel to reach a slower type connection ? why do that ?
UDP is good for the data that is stale the moment the next packet comes in.
For transmiting physics you will need tcp, because you need an 100% reliable way to transmit data that always must reach at same order.
For transmiting position / velocity you do need udp, because you dont care about the past position of the player because of a lost packet since you have a new packet that tells you where he is.
Which physics? You need to make sure the inputs get there from the client reliably but presuming that there is minimal client-side prediction of physics then all other state coming from the server is transient state… just position data, really. Even if you try to do some client-side prediction, as long as the server to client state includes position then the next packet trumps the last.