How do you handle pathfinding/collisions/etc... using a third party server?

Unity Engine
1

I’ve seen a number of examples dealing with card games, chat, etc… but my question is if you want to have a dedicated server in control of creature movement, there needs to be some sort of access to the scene data right? I mean, how are people handling this other than proxying these calls out to a unity instance with the map loaded? Is there typically a synchronize() method to persist the scene hierarchy to a server on loading a new map so it can be used?

I’m thinking of cases like moving a monster across the map and controlling this via a server extension. If you’re using Unity3D’s built-in networking I can see that, but what about a third party service like smartfox, es5, etc?

I can see solutions ranging from persisting/mirroring scene state (collection/heightmap/?) to using a delegate instance of unity that controls map state and having it make raycasts/etc… on behalf of the smartfox/es5 extension.

Hoping theres more to these setups than that though, sure be nice to have a sandboxed scene instance you can do raycasts against from within server code.

2

One solution is to have the collision detection done on the client, either the player’s own client or the player’s opponent. That of course is open to cheating.

I haven’t done collision detection with a Unity multiplayer game yet, but I implemented server side collision detection for the AS3 Tank Game example for ES5. You could certainly use something similar to that. The source code is publicly available.

What some games do is have the collision detection done on the client, but then verified on the server. “My bullet #349 hit player C at coordinates X, Y” - server would check for the latest position update message from player C, the position from the player reporting this when he fired bullet 349, make sure that there isn’t a wall in between those two positions, that the bullet was aimed at coordinates X, Y, and that player C is likely to be at coordinates X, Y at the time the bullet hit. The server never knows the exact position of anything at a given time, because it’s always moving, but it can definitely check time stamps and velocity and heading to see if two things are going to be close enough to hit each other. In the tank game the bullets are going so fast and were so much smaller than the tanks that we just assumed that the tanks were still at the last location they reported, and treated the tanks as circles.

3

Right, I can see that - from the sounds of it though this is pretty bare metal code to use a 3rd party networking solution though.

Ideally I’d like to see a plugin for something like ES5 that is a simulation of the physical environment for the given scene. Maybe I’ll put that together and post it when I come to that point (starting work on npc AI soon here so i’m guessing that’ll take a bit :wink: ). It really should be the case that all colliders are recursively persisted up to the server (or better, the server plugin has a loadScene() method itself) then the Vector3/Physics classes are emulated in that sandboxed environment.

So basically it comes down to the following options (so I’m clear):

  1. Use a ‘master’ client (or p2p client scheme) to manage npc movement, etc…
  2. Use a headless unity3d server scripted instance to be the server (leaning towards this for my first cut atm).
  3. Persist and simulate scene on game server side.
  4. Use a headless unity3d server as a service provider to game server.

Is that basically what we’re looking at?

4

So if I get what you’re saying :slight_smile: You want to know how to make all this work on an auth server with character interaction fundamentally.

In my case, I use uLink as my server solution and everything that appears on the client is a proxy of something that exists on the server. Each character, NPC, interactive object is spawned on the server, with a proxy being sent to the client via a game controller using serialised RPC calls and each relevant object also having a network view on it.

Any interaction… lets say triggering a dialogue or a combat, is done when the player character on the server interacts with the NPC on the server, nothing at all to do with where they are on the client machine. The player in effect sends a command to say… swing my sword, the server then does so and determines if the sword hit anything and responds with the result. The barrel blows up and goes flying through the air on the server, with the network view sending that to the clients. All physics is on the server, I don’t bother with it on the client, because everything on the client is just a proxy.

As a result of this, my servers run headless in the cloud with absolute basics on them… buildings are just blocks with the same dimensions as the ones on a client, the characters and all objects are lowest poly proxy copies, not even with any animations on them. This keeps the server operating fast enough to ensure all the clients are getting regular updates from the serialisation from client - server - proxies.

My server never drops below 60FPS and actually is limited to not go higher than that so as to synch the messages backwards and forwards. The clients can sometimes drop to 30FPS in heavy areas, but as long as your network messages are all correctly timestamped, then missing one or two won’t be a major issue.

If my loot table needs an item, it looks it up from a Db connected to the server and then sends a reference to the client so the client can turn a number into a snazzy 3d object locally. I have no Db’s connected to a client, all Db info is done by the client as a request to the server with a response from the server. :slight_smile:

The only time I don’t go through a server from the client is initial Login or Character setup which operate purely clientside through PHP to an account server which then sends info to the Game Server when validated so as to not let anyone near the game server until they are fully validated and have a character to play…

So really I would push you towards version 2 in your chart 'cause I know that for me, that works well.

Regards

Graham

5

Great stuff Moria, this sounds about right - I’m thinking of adding an abstraction layer so there’s a dispatch server instance sitting on top of N headless servers - just so I can cluster functions (chat on one server, AI on another, etc). I’m still fairly new to C# so not sure if it has an event bus or pub/sub library of note, thinking of a JMS style implementation for me.

Thanks for the feedback, time to do some AI and then look into raknet coding fun :)!

6

Moria,
how many clients are you able to support with uLink on some given hardware?

How do you handle launching\monitoring\updating lots of uLink builds in the cloud?

thanks,
Slav

7

A very nice example for a 2d game, thank you! :slight_smile:

8

@Moria -
I appreciated your description of the server <> client relationship. This is how I have been working with Unity’s built-in networking and happily with success.

I am curious about your description of “absolute basics” for the headless server running (e.g. using cubes instead of buildings, etc.). Has that proven to be useful in tests? I found that I could run the same scene as the full game (client side) in headless mode (batchmode), but if I did not lock the target framerate in the server scripting, it would run away at very high frame rates - so it seemed that any overhead with graphics-related stuff is basically ignored anyway.