Authority on RTS-games

[Notepid]

Hello guys.

In a RTS type game, how would you set up the authority? Should the server process all units for all players, or should each player have direct control over their units.

Say if one implements a authoritatively oriented server, would the correct implementation be that clients sends a RFC to the host and asks to have a unit instantiate, then the host does a TNetManager.Create() on behalf of the client?

Also how would one go about to have a client do something on a specific unit. Like telling the server that this unit is to move to that position, etc. I have not been able to find a way to send a RFC to a specific TNObject as it seems there is some kind of magic that hides the Id.

[Manmax75]

In a lot of RTS games they simply use a P2P networking model, which is where every client is their own "authoritative server". In older RTS's they used a method called lockstepping but this presents a lot of problems with desyncing, specifically because EVERYTHING has to be deterministic. Which pretty much means it's impossible to do in Unity because PhysX is far from deterministic (in my experiences anyway). Plus you'd have to roll your own floating-point system to deal with numeric drift.

But anyway, you've got two options here. One client will always be the "host", the host being the person who handles relaying packets to everyone. Now it's entirely up to you whether you make the host authoritative over all its clients, or simply allow each client to tell where its own things go.

They both have their pro's and con's, for example. A fully authoritative approach will allow you to handle cheating very nicely, as the server handles all the logic. This also means that everything will be generally well in sync for all clients. The downsides of this approach is that it can be quite difficult and challenging to implement. And it will take a lot of your time.

The pro's and con's for a P2P solution are pretty much the opposite of the fully-authoritative approach. Cheating *may* be hard to manage, clients may desync due to different states (something you'll have to handle) but implementing a P2P model isn't overly difficult.

If you choose to do a fully authoritive approach, I suggest reading this article:
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking

It is incredibly helpful for understanding networking.

These may also be relevant to you:
http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php
http://gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/

[Notepid]

Thanks for the good reply and good articles.

At the moment I am prototyping a game concept, but the more of the networking I am nailing now, the less re-factoring we need to do in the future. At the moment I guess I am running a P2P-model as each client just tells everyone else where their units are, and accepts blindly any updates on units that is not their own. This works well for position updates and such, but there is an issue when it comes to agreeing on interaction between two different clients objects.

Example: Two units approach each other and they want to attack the other unit. There is the technical issue of sending a "I did damage to you" between these two units (at least I have not found a good way as of yet).

Secondly there is a problem agreeing who did damage to the other first. On one screen my unit fired first, but on my opponents screen he fired first. This can be solved to allow to receive damage even if in your simulation the enemy is no longer there, but introduce some latency and that can look very strange as in "I died for no apparent reason".

[Notepid]

What I really want to know now is how do I tell the host that the client wants to spawn a unit?

I am really lost at the moment as everything I try (bar creating my own packet type) seems to fizzle...

[Manmax75]

You can use TNManager.Create to spawn units. Or have an RPC that a client can call to create a unit.

That is one of the hurdles of P2P networking. I'm not entirely sure how RTS's with a P2P approach do it, but the player authority model might help you there.

Pretty much it means that each player is allocated an ID upon join (say there's 4 players) the ID's would go 0,1,2,3. Now how this works is that at any given interaction, the user with the lowest ID dictates what happened first when there is a dispute about who did what first. In high ping situations, the other user is selected. This does seem unfair in some sense, as you will always side with one player, but I just can't see anyway around something like that. Other than doing a hybrid-authoritative approach, and have one client (probably the server) monitoring over all interactions, and when there is a dispute, telling which client gets to dictate what.

[ArenMook]

Don't allocate IDs. TNet has unique player IDs for each player. Also don't designate one player to be authoritative. TNet also does this -- TNManager.isHosting tells you whether you're the authoritative player or not. The best thing to do is for each player to spawn their own units via TNManager.Create. Your AI logic and such can run either on TNManager.isHosting == true player (the authoritative player), or TNObject.isMine (the player who created the object).