Authoritative networked collision detection

I know there's been threads about this in the past, but none seem to have reached any kind of conclusion.

If you want an authoritative server to be responsible for player movement and things like raycasting for projectile collisions, server-side 'bots' or NPCs, or support for things like moving platforms, then the server needs to be aware of the level geometry to perform these tasks. My only experience of this in the past has been with engines written from scratch where it's been relatively easy to have a simplified version of the renderer present in the dedicated server to perform collision and raycast checks, reading in the level collision geometry in the same way that the client does.

Considering the general opinion that Unity's built-in implementation of Raknet isn't really suitable for production use (I'll hold judgement on this until I've tested it myself), that means that we're forced into using a third-party networking library like Photon or something. My question is, has anybody ever figured out a method of achieving this with a third-party library? Has anybody implemented a way to read Unity level geometry from within something like Photon and perform collision/raycasts server-side? Or server-side NPCs/AI? Reading terrain heightmap data is easy, but that's not really enough. I would guess the simplest way would be to have a trusted Unity client sitting on the LAN with the server doing this, but then you're bottlenecked by Unity's (allegedly) poor networking again and I would question if you're really getting the full benefits of a third-party networking server if you have to pipe it all through a Unity server anyway.

Assuming nobody has solved this, why are you using these expensive third-party libraries? Are people really creating games of such a scale that they require 1,000+ CCU networking licenses/server and yet they haven't bothered to implement authoritative movement? What's going on?

 

I really don't see why people think unity's built in networking is broken. It works just fine if you're doing an instance-type server where you have somewhere around <64 people connected at the same time. Just stick to RPC calls and you won't have any trouble.

 

First: they aren't expensive. doing something like this yourself costs months of time yet their licenses which you would use normally is lower than a weeks income

second: its all about performance. Unity is nice for small games but if you want to do a facebook game where you have persistent backends and game sessions, unity is basically useless as it eats masses of cpu time which means you need more servers to keep the same number of users.

you can opt it but even at best it will offer you slot counts that are an ordner of a magntidue smaller.
and it will also cost you $1500 at very least cause you need pro to get headless client, without it you won't host anything

if your game is more pphysically oriented etc then you might not have a way around unity at one point (like simulation node on a photon / sfs backend) but really only then

 

Sure, I didn't mean that the price for these is unreasonable at all, nor was it the focus of my post. In fact, software like Photon is shockingly cheap for what they offer. I only tagged that on because I see a lot of people jumping straight into external networking libs for even very "simple" games. Obviously if you need to host many players and/or sessions and you're doing nothing but sending messages around, then a socket server like these is a no-brainer. Being able to plug a database into it is another huge win, of course. It all makes perfect sense for something like a casual or facebook game.

What I'm looking for, if the post wasn't clear enough, is somebody who's managed to build a more traditional medium-scale multiplayer game such as an FPS/RTS (or any game that requires an authoritative server, access to level geometry, and a relatively high network rate) in Unity, and how they achieved the networking given the limitations. I couldn't really find any answers to this question, which suggests that either few people have done it or they've managed to live with the built-in networking.

The more I look at it, the more impossible it seems to achieve this without (as you say) plugging a Unity node into a network backed by a "real" socket server, which doesn't feel very elegant but should be interesting. Something I've enjoyed doing with each engine I've tried over the years is re-making the same simple FPS game in them and see how the development workflow and networking compares. This is just for fun right now, as I don't get anywhere near as much time to mess around writing games as I'd like.

I already have Unity Pro and am more than happy with it - it's the nicest engine I've ever used and don't plan to switch any time soon, but it would be a shame to bring my old game up to date and find that the networking is as limited as people are suggesting. I would've expected it to perform pretty well in headless mode for a sensible number of players, but as it's the only area of Unity that I haven't really played with yet I was hoping to benefit from the experience of others who might have done this already to save myself some time.

edit: missed your post up there, Cerebrate, but that does sound encouraging. I've already realised that I'd have to use good ol' RPCs for this, not to mention probably reimplementing network instantiation and IDs. Should keep me busy for a while...

 

yes, I'm using the built in networking for a third person game that involves small amounts of people per server, like about 8, and I haven't had any problems (Other than discovering that network instantiation is buffered). Mind you I'm not using databases, but it works great.

 

You necro a decade old thread just to link to your own $50 store asset?

 

I've deleted the post. Thanks for the reports.