Clientside/Serverside logic oppinions

I have some experience using unity but i would still describe myself as an unity-beginner.
Myself and some friends just started to develop an multiplayer game and i find myself struggling to decide which logic should be done the server and which on the client (and in what way).

I understood the basic concept of Cmd/Rpc and SycVars.

I already read some articles and oppinions regarding this topic, but i would love to get some oppinions and insight from people that are more experienced than i am.

What are we trying to accomplish?
Basically we are trying to learn something and we don't really know if the game turns out.
Our goal is to develop an RTS-Game which allows a seamless transition to an ego-shooter to control units.
So basically we have nav-agents that are synced over network , but also manual movement that has to be sycned.

What do we have so far ?
Right now we are only focusing on multiplayer, so that we are already spawning buildings and units via the server and are syncing unit movements.

The units are also able to target enemies and shoot at them (with a verrrryyy basic AI) and it is also possible to control a unit in ego perspective and shoot manually.

How is it implemented?
I don't know if any of this is a good idea, feel free to criticize and give your oppinions.
It would be really helpful if you could provide information (on how and) why you would implemented something in a specific way.

• Unit movement in RTS View
  • Player clicks on a destination
  • Command is called that sets a destination on the server NavMeshAgent
  • Command calls RPC that sets a destination for all client objects
  • The Unit prefab also has a networkTransform (this is probably a bad idea?)

• Unit Movement EGO View (same prefab/object as RTS Unit)
  • NavAgent is disabled
    
  • Client transforms it's local Object
  • NetworkTransform syncs the position (this is a bit laggy with the current config)

• Unit RTS AI
  • The logic regarding target detection and raycasting is done on the client to whom the units belong.
  • New destinations are set in the same way as described in "Unit movement in RTS View"
  • Weapon effects (Sound, Line Renderer) are send via a cmd and then executed via rpc call on all client objects.
  • Raycasting for hit-detection is done on the client and if a hit was detetced, the unit that detected the hit on an enemy sends a cmd with the target network id. The server then applies the damage to the server object. The actual health is synced via SyncVar.

• Unit EGO-shooting
  • Basically the same story as above
  • Raycasting is done on client and then submitted to the srever via cmd by the unit that caused the damage.

General considerations:

• Should all logic be exectued on the server, which would turn the clients to "Render only"?
  • If so, why?
  • If not, why not?
• If the logic is split between server and client, what is a good way do descide where to put it?

 

Some general comments from someone who hasn't actually created a multiplayer RTS or FPS, so take them for what they are worth.

You're combining two play modes with rather conflicting networking requirements into the same game. This while of course not impossible to do, is going to make your work much more difficult than if you stuck to one or the other.

While RTS games have traditionally used a network and simulation technique called deterministic lockstep, I don't see why you couldn't make the game using a server authoritative model where the simulation is done on the server and everything is synced to all the clients, unless you're dealing with extremely large numbers of units to sync at a high rate. So I'd imagine in your RTS mode the player gives an order to units or to build something and it is normally fine if that action is delayed by a fraction of a second, while the command is sent to the server, and the results of that command are synced back to the clients. You click to tell units to attack a target, and then less than a second later you see them turn to fire on said target. Should work pretty good.

Now when in your EGO Shooter mode (FPS, or first person controlling a vehicle I'm assuming that means?) the responsiveness of the above RTS technique will feel laggy and unresponsive on anything but a LAN connection. In first person mode, anything but near instantaneous response is going to be unacceptable. That means you'd need to make actions by the player client authoritative instead of the server (which is a clear avenue for hacking among other problems) or implement a somewhat complicated system of client side prediction while the server is still authoritative. The later meaning the player's movements and actions are simulated locally before the server receives the player's commands instead of waiting for the server. The most difficult part is dealing with when the client's simulation becomes out of sync with the server's, and how to correct that without it being jarring to the player.

Another issue between the two modes is simply perspective. At a high level when viewing an RTS top down, movements of units can appear smooth, but when you get down to their perspective you magnify any imperfections. Units with almost imperceptible movement corrections, such as a tank sliding to the left a track width, will look just fine. But in first person mode that same correction will make the tank look like it is sliding on ice. You can send updates more frequently, or otherwise try to make syncing of units more precise, but with a lot of units that could end up being an unreasonable amount of messages. You could try a technique I'm using in my game when a client is in EGO mode, where I have the server sync position updates at a much higher rate for units within a certain range of the player, and more distant units I sync at about 1/10 the rate. Just an idea.

 

Thanks! That gives me some clues and ideas. Yes, Ego-mode means FPS.

 

Just a comment on client-server synchronization:

We developed a demo game which is not an RTS and not an FPS, but somehow something in between: you are controlling a spaceship in realtime, firing at other players. It makes use of an authoritative server. Well actually I think we can say it is more FPS-like, even if it has a third-person view.

This is how we deal with synchronization: http://docs2x.smartfoxserver.com/ExamplesFlash/spacewar-p1#synch
We are quite happy with the result, as it works quite well even in cases where the client-server lag is sub-optimal.

NOTE: the tutorial linked above refers to the Flash version of the game, but we implemented the same logic in Unity. Here you can find the Unity version: http://docs2x.smartfoxserver.com/ExamplesUnity/spacewar

NOTE 2: we also developed an HTML5/JavaScript version of the same demo, which share the same server-side logic with the other versions. This video shows how it behaves with 250+1 starships flying and firing:

https://www.facebook.com/video.php?v=1407009572672115

 

We will take a look at the smartfox server, thanks!
Right now we are using the Unity client-server framework.