forums.smartfoxserver.com

So, I've gone through the docs for SFS2, as well as the tutorial for the FPS unity. I got it up and running, and now I would like to verify that I understand how this all works.

Somewhere in the Unity tutorial, it mentions that for a development project, you should also check player->world collisions on the the server.

To me, this means (if I were to program such a game-- fortunately, I am not, my game is simpler), I would need to rewrite most of the collision routines that I have taken granted for in Unity since SFS2.0 has no way of knowing it. Which means I would need to reprogram things like meshColliders, box colliders, as well as checking if moving from lastPos to currentPos causes a collision per each collider.

This also means that much of the Unity API that I have taken for granted is about to bite me in the butt, since doing things like ray casting is easy in Unity, but going through the FPS tutorial, it looks like this needs to be programmed in should I want to raycast (look at the "checkHit" function).

So, to do something like check for world collisions, SFS is going to have to have a copy of the world model, be it a complicated mesh collider, a bunch of box colliders. For a mesh collider, it would then have to check the windings of the triangles and see if lastPos -> currentPos collideded with the windings of all the triangles in the map. In addition to that, SFS would also have to have some sort of a hinting system to make the collisions run faster.

I am assuming for the full authoratative server, physics would also have to be reimplemented server side to prevent cheating (not that running physics server side is the brightest idea, I'm sure y'all remember how bad multiplayer in HL2 ran with all the physics objects).

To me, this means that just about everything in Unity needs to be rewritten server side to prevent cheating.

Don't get me wrong, I am not trying to complain. I really am just seeking the answers to the raycasting and world collision problems presented in the tutorial. Before I start programming, I would like to know what might be in store for me in the future, and if there are any Unity routines I might want to copy over. And quite possibly, maybe I would write a Unity Helper Java .jar to replace some of the missing functionality, such as raycasts.

Thanks for your response in advance! (I am going to finish reading through the FPS tutorial code right now )

Reimplementing everything on the server side would be an absolute nightmare. When faced with the same problem, this is what I did:

I have a server version of the unity standalone. When a game is launched, I launch the standalone on the server in headless mode (nothing rendered) for max performance, and log it into the server and join the game room as a sort of game host. That way, I can run the full game simulation in the engine and arbitrate everything on the server side.

That's the general idea we pursued; there's loads of fine details I haven't gotten into and specific problems we had to solve, but that should be enough to point you in one possible direction.

using any server solution that would be the case, but to solve cheating yes you would need more stuff on the server side, but it would depend on the situation FPS example cheating would make the game not worth playing, in a mmo how fast someone moves isn't as important.

But you can get the server to do everything to stop cheating or just get the server to allow a maximum and minimum values so it stops people cheating enough to effect things.

but you can write (virtually)anything you need into an extension. but i don't think youll need to write much for raycasting to be authoritative just check the values are within reasonable limits

Depends on what your game is though, hope I've helped

Oh-- my game is much simpler, I am just trying to think this through-- If I were to make an FPS at some point, I beleive the above mentioned is what the FPS tutorial was getting at.

Right now, my networked game isn't much different from golf. Right now, I am simply getting the basics down and implementing the lobby.

However, the ball must be controlled by the server-- which means the physics must be as well. This is something I really don't want to program in, so I'd like to actually run the scene in a dedicated server somehow.

tpenn, I'm a little new to this networking stuff. Would you mind describing the setup a little more? I am awake that Unity has the ability to create dedicated servers, and it sounds like what I want to do is roughly what you did do.

What it sounds like you are describing is that SmartFox acts as an interface to your Unity dedicated server-- right? So, a net packet would go through your smartfox box, which would possibly run some checks such as player position updates on the Unity server, and then send it back as O.K.?

Thanks for your assistance

Hehehe - a minefield you are moving into

But yes - you are totally right and understand the problem.

In one end - you have the client do all the collision checks and do nothing on the server. But that will - in a multiplayer FPS - lead to nasty cheats. Wall hacks like the good old counterstrike days etc.etc.

In the other end - you have a complete and accurate representation of your server world running on your server. Doing raycasts, accurate collision detection etc. Very nasty should you go down this route.

Using Unity headless servers is one way to get access to the physics. This needs to be optimized though for it to be worth going down that route imho. You cannot just spawn a headless Unity server per game instance - might as well have used Unity networking then in the first place and suffer the scalability problem server side.

What I would try to pursue (without having done so - just ideas):

- run a headless Unity server per "scene type" / "level". And then use that in some way to use physics easier

but what I would prefer myself

- simplify the collision checks and run them in straight up code on the server

I would make a small export script for my levels to export the main geometry into data. And then have some very very basic checks running in code similar to the "checkHit". And possibly only use them as verification that the client did not cheat.

So its back to not running every little check server side - but let the client do the detailed work - and verify it server side to catch cheaters. Very much like the min/max checks by lastowl. Did the player run faster than the max speed allowed? Did a player just pass an impassable box collider wall? Did a player just try to shoot someone through a wall?

Some things dont even need any collision checks if you start to simplify things (who said networked games is easy? ). E.g. the shooting part could be solved easily by using a zoning scheme. E.g. divide your world into different rooms/zones. And then you have a small lookup table that says - only players in the same zone can shoot each other. So if player 1 shoots at player 2 who is in a zone X that is separated by a wall in your game - then that guy is a cheater and you simply do not apply the damage.

I would not really care too much if he run through a tree by cheating. So there is a fine line somewhere on what you want server side and what you want to ignore if the player cheats. Comes down to your game.

And also - if you run competitive competitions for real money - then you better do everything you can server side. If its just for fun and its a coop game vs. AI with friends playing. Then the chances of anyone cheating in the first place (and the consequences) would almost have me not implement anything server side in the first place.

/T

Lol, yes, I realized that-- I'm glad I stopped before I blew my leg off

From my previous networking experiences, I didn't think that networking was too bad-- even Interpolation and Extrapolation, though I've never done it, didn't seem so bad to implement-- but having to reproduce everything server side is definitely something I didn't think I'd have to do!

But yes, I think I will use some of the methods mentioned here to make things a little simpler-- using boxes and spheres to determine whether supposed positions are indeed valid.

But that is awesome info Thomas, it really puts how little I know into perspective. Thanks!