koobas.hobune.stream
Separate Client and Server?
I'm attempting to make a very simple prototype multiplayer online game. The first step is to simply have two players login and move their own sphere around, while being able to see other players' spheres moving around as well.
I want the server to handle all actions, and have the clients simply request movements (Server authoritative). The server would send the players' movements to everyone so it updates at the same time.
Two questions regarding this:
1) As the title states, should I be making the server in a seperate project completely? I've seen tutorials and videos on how to create something similar to this but they all seem to use the same client. I don't wish to make this project easier, I wish do to this project right.
2) I recall attempting something similar to this project a while ago and was unable to make the movement "smooth" for the players. It would update, and it functioned, but the movement was choppy and warping. How do I solve this issue this time around?
Thanks in advance,
Mr.Muffles
Hello,
1)
Personally I find it easier to make both the client and server in the same project. For ease of use I have (on multiple occasions) created a authoritative client-server model that can run both seperately and at the same time, allowing for players to both host their own servers and have dedicated servers. Maintaining two projects is really hard, and due to the way Unity works, the server project would also have to be built in Unity (if you want any sorf of Unity based functionality) and having to switch between projects continually to add simple features is just a waste of time.
In networking there is no right. There are definate no no's, but the rest is up to the situation and what you can work with.
Before you start making an authoritative server however, note that in all modern games that use authoritative servers, the clients do a bit more than just request movement. They also try to predict the movement that the server will send back, allowing for proper gameplay that is lag independant. Doing this takes a quite advanced movement system. It's not easy but nessecary if you don't want your users to wait, possibly seconds at high ping values, for their input to change anything in the game.
2)
When doing anything in multiplayer, you are never able to keep the refresh rate very high, because the latancy and bandwidth usage would probably make the game unusable. I suggest a refresh rate of 15-20 times per second. On that note, because we are working in large steps instead of tiny steps like we get when using the framerate, we need to interpolate between the updated points. You can also Extrapolate to find the point that will probably happen, however that can get quite complex, expensive and is not very accurate. You can find enough information on Interpolation and Extrapolation on the internet. Both are good methods and both get used (sometimes together) in tripple A titles.
Hope this helps and clears some things up,
Benproductions1
I'd just add that certain types of game work well by applying the principles of extrapolation and/or interpolation to things like steering behaviours. For example you would be sending the server the current steering heading and velocity of the player and the current rate of change of those things - this works much better than sending only positions and rotations (in suitable games).
Next up, if collision detection is important you can consider not using the normal methods (OnCollisionXXXX) for the moving player representatives and ins$$anonymous$$d "sweep" rigidbodies through the scene for the actual path taken, reporting collision in this manner from the server. This can help when the server is informed of the actual path taken, rather than it interpolating from discrete positions - that probably is AAA stuff though.
Those are some very good points XD
$$anonymous$$ind if I add them to my answer?
