In a real-time multiplayer game, where lots of physics and quite unpredictable stuff is going on, is common to use an authoritative server that detects collisions. The best way to achieve this is to run an istance of the game on the server. So the server just have to send players/objects positions and client have to send input to the server to execute an action, simulated in the istance of the game. So I basically need to make sure to get an headless version of the developed game, but I also need 2 streams(input and output) to ensure interactions between clients and the server. I could not find any clear way to get an input stream from the headless executable, since it won’t accept any input commands by line. How can I input commands to the headless engine? Am I missing something?
What are you using to communicate?
Do you mean like this?
Test.exe --config=ace.ace=7 --config=test.test=999
sys.get_config("test.test")
Not sure if it’s common or not, but verifying everything server side comes at a huge cost, both in development time and money (because servers need to be more powerful).
I have recently made a real-time multiplayer physics racer, No Brakes io. You have to be a bit clever with interpolation, but if you can get away with approximate collisions, I can recommend doing the collisions client side.
Indeed, this is an option, and a valid one if you’re working on a game that have to deal with just players collision, or that is based on simple physics. I would end to develop a p2p game but with an external server for communications.
The real problem is when you have to deal with other stuff. For example if shooting is involved in your game this system would be unusable. If a player detects that his bullet has reached an enemy, but the enemy has not detected this, who would be the right? Cheating would be even more troublesome than before, sure there could be some instrument to punish cheating, but not preventing it.
In No Brakes io there is in fact shooting as well as turbo and even bombs! All done client side. In this case it’s not that important to resolve the conflicts caused by lag. As long as you show each player what feels “right” to them, no one will feel it’s unfair. In fact, if each action has to be verified it’s likely the experience will suffer because instant events, like explosions, will “feel” wrong on at least one client because of the lag.
I’m using colyseus for client-server communications.
I was not aware of this solution. It is interesting, I could do some workarounds if this is the only option but it would be inefficient. I should, in server-side, simulate part of the actual game dynamics ( so I’d have to run the headless with initial parameters then it’d have to stops and then re execute when an input from the client is received).
I was looking something like a message that could be sent to a game object, but using the prompt while the game is running( so I could in server-side extrapolate an input stream).
Well, in an ideal scenario it is fine, but you can’t satisfy every client and is unfair for higher latency users to let them see what is “right” to them, since it could cause for clients with normal latency to feel less right.
I think this is always true, regardless of good or bad latency. The way I did it was to divide game actions in two categories:
- Non critical actions: client side
- Critical actions: server side
In my case, since it’s a racing game, I decided the only critical action is crossing the finish line. I can verify this without any noticeable issues and announce the winner.
For a game where there might be critical actions in game, it can get a lot trickier.