The Photon Forum
is Closed Permanently.
After many dedicated years of service, we have made the decision to retire our Forum and switch to read-only: we´ve saved the best to last! Your search result can be found below. Plus, we offer support via these channels:
Try Our
Documentation
Please check if you can find an answer in our extensive documentation on Photon Server.
Join Us
on Discord
Meet and talk to our staff and the entire Photon-Community via Discord.
Read More on
Stack Overflow
Find more information on Stack Overflow (for Circle members only).
Collision detection on the server side
zoultrex
2010-10-24 01:23:13
Hi guys, I was wondering how is collision detection made on the server side. I have asked this also on gamedev.net (http://www.gamedev.net/community/forums/topic.asp?topic_id=585754) to see if someone there had any idea how could I implement it.
I am really lost in this one, I dont even know where to look for more information about it. some time ago someone said to me about loading the mesh into the server, again, no idea how to do that.
I googled fbx reader/parser on the internet but what I found would be very hardcore to do, I cant wrap my head around how would tell the server how to deal with the vertices data.
Any help appreciated ;)
Comments
It will actually be very hardcore to do if you want to do it in photon directly as you need model handling, physics library / simulation framework, a level format reader, collision library, ...
The only way around it is making dedicated "collision clients" / "simulation clients" with your game technology which are hosted on the server cloud and interact directly with photon and which for example verify data from the client or really perform the whole simulation (in an authorative environment).
Hi Dreamora, long time :D
I totally forgot about that option, I guess that this will be my first option at the moment, I will do some basic testing and see how well it goes. If that works, it would be like really perfect, because it would be as if part of the server would be a perfect copy of my game, or as close to it as it needs to get. This would save me tremendous effort in regards to any other options.
Do you remember seeing around the forums that you can somehow "turn off" the 3D display of Unity and make it into a console? Probably I would need something like that right? I say that because I think that server machines are not great in video memory, gpu, etc
You need unity pro, then start the client with -batchmode that will turn of rendering and audio.
on the audio end, ensure that you kill all audio components in addition though (simple check in an awake) as at least 2.6.1 caused massive cpu overheads when doing so as I had to learn the hard way when writing the Reigh of Steel server
So that is how you made the networking on your game then? If so, how did you cope with the time that it takes from the authoritative server to Photon, then from photon back to the clients, this time taken would be like: (AU server time+travel to photon+photon compute time+ travel to clients) where if it was directly done in photon photon compute time+travel to clients
Did you made the clients run 1 step or loop behind the authoritative server?
RoS at the time actually is not Photon but true standalone instances and a webservice based game listing. I had such a setup during the early stage, but Photon in this case didn't offer enough as it does not add anything to the equation, it only makes the pipe longer and adds more latency (as all the processing has to be done on the node anyway including data inspection, physics, etc).
But if you have a game where you only need collision and not the full package, I would definitely give it a test at least (its not that hard if you have an RPC based setup for example which you likely have if you came with the project from U2)
Doing such collision directly on the server would potentially be more performant due to the cluster loop times, but it will also be some rather large work to achieve it as you need to find a collision library, need to write geometry exportation editor capabilities and reader capabilities for photon and you might potentially have to rewrite / redesign your whole collision as not all capabilities present in Unity / PhysX exist in barebone libraries like ODE.net
So I would recommend to check out the options and do the decisions basing on this, cause in this case the theory can be off rather badly.
Oh one thing just to mention: if you use multiple unity nodes, don't forget to have a tool that after starting a node switches the processes processor affinity on windows. Unity has the ugly missbehavior to always only use the core with the lowest number in the cpu listing so if core / processor 0 is active as processor, all instances will run on it and not touch the rest. (the same problem btw is also present on the editor as you might have seen or at least felt at some point. moving it to your highest index processor through the process manager normally helps quite a lot)
Thanks for the insight there on Reign of Steel, dreamora, I too thought you guys had Photon running up there. Thanks also for the affinity tip!
But yeah, I've been thinking of doing something similar with what you said you initially tried with having a Unity client connected through Photon that has an authoritative state, but I'm having my doubts over the extra delay this causes.
It's a pretty cool setup for stuff like card games but not so much for real-time - especially if you want all the bells and whistles from Unity's side. Though I'd have to do a lot of testing in the real world to figure out how many headless clients a server can run at any one time.
if you use the nodes only for verification of critical things and otherwise just let it simulate a local authorative state, would this be an option? There is on MMOs and similar no need to feed all back etc.
alternatively you could license CMUNEs platform code from paradise paintball 3d, which from what I know is Photon based too and uses some smart moving around and replica of states to handle the verification on clients I think (similar to custom games in WC3 where the clients simulate the game and if the host drops outs, the host / authority is shifted to a another player in the game)
Interesting. Letting a player (or players) simulate the world and then having authority over it was what I thought about, but I was a bit too worried over hackers who will take advantage of this and team-up with other players to aid in telling lies about what they did. When you have the ability for players to play free all the time, against potentially paying users, this seems sometimes like a scary situation.
I thought of only doing this in private matches, where they receive no long term awards, even if they are cheating.
My project is pretty serious and luckily I do have funding behind it from an investor, and as such I can look into what Cmune offers. My only hesitation so far is that it's just purely focused on simulation of a FPS. If I go for that, I'll be sure to contact you as I'm sure you'd be interested in peeking around that tech (within contractual/NDA limits).
What genre are you attempting to use the solution on?
Normally FPS is the worst one as stuff happens on a low latency requirement and a high precision requirement (wall hacks, head shots), so solutions that work for FPS work for anything but MMO basically (on mmo there are so many more considerations especially with handling of assets that you could write books about it if you would talk about it in detail)
Well, for me definitely not MMO. Basically I'm looking for something that would work well in a 3rd person and/or first person shooter environment. Other things of importance to me would be land and air vehicles - with not too advanced physics. That's essentially what the clients would control and what would need as close to instant synching as possible. There are several techniques I've looked at using to do this properly, e.g. having the authoritative client perform things in the past (like gun shots) - so I've got a lot of that covered. Right now I just have to decide which solution I go for. Thx for your comments so far btw.
At the exact moment I am implementing the approach recommended by dreamora to have an authoritative server for collision and important things that I don't want the player to have control. In a detail, when I say that the authoritative server will take care of the collision I don't mean the physics, just the damage, hits, shots, kills etc. My idea is to run the as close to everyone synchronized as possible and run all the simulations exactly the same and the authoritative server will act a referee telling the important stuff like if you die or not, take hit or not, but the animations will run according to the graphics first on the client side, and if something happened on the client that did not supposed to, the info from the authoritative server will come in the next update and will correct anything wrong in the simulation.
That's my general idea, right now I'm making the collisions with the environment take HP from the ships in my space shooter, and the projectiles take HP from the ships. Will let you guys know about the outcome next week after I test everything =)
That would be the approach I would be taking too, having the nodes on the server / cluster as referee to validate data (just cause dual loopback to validate it on clients takes far too long).
The main thing to keep in mind and follow is a similar "event pushback" behavior as the unity network example has it (all input etc you do is delayed on the receiver side by 100ms since its sending timestamp before its applied locally). By doing this, you can validate the correctness of things on the referee "upfront its date" and have corrections applied before they are pushed through potentially.
anomandarius
2010-12-09 05:49:31
I have a couple of questions and a couple of additional issues to raise.
To be certain I understand you're saying you'd have a headless instance of Unity running on the server cluster and use it's simulation as the authoritative physics representation?
If I understand this correctly then I'd definitely suggest implementing a dead reckoning system over the lock-step you seem to be discussing.
Dead reckoning would simply be allowing the client to respond immediately to input and then interpolating the client simulation with the authoritative node over X time.
Lock step tends to feel sluggish for action games and doesn't scale very well as it suffers from the lowest common denominator problem.
Back to top