I wish you the best in finding a solution. This problem is way over my head.

Are you worried about hacking, or perhaps player to player collisions?  I think this is pretty much the way Everquest worked but it didn't do much physics. Just gravity and basic collision.
 

Thanks Rutin, I'll figure something out.  Or scrap it and start on something new...

Maybe go back to being a wood carving gold miner in the Sierra Nevadas...  That was zen!  Well, when my Datsun windows weren't being shot out by angry xenophobic drunks, and dudes weren't burning stolen cars just down stream....  But especially when I wasn't being given notice that I was claim jumping...

But I'm probably never gonna drive taxi again, that shit is for the birds.

Hahahaha

@Gnollrunner, nah, hacking is not the concern.  A concern, yes, always. It's mostly fast motion and entity interaction issues.  I also spent some time building a vehicle platform and that is ALL physics, dunno if I can even reuse any of that...

It's a mess at the moment.  

The more I think about things though the more I wonder if I can't keep some of the physics in play.  Like my gravity..  I'm trying to imagine a scenario where that could cause the gameplay to diverge..  Pretty much only if two players are falling a significant distance while doing something competitive...  Hmm..  

Do you have to run the server using unity? Providing unity clients can talk in packets to something else you can write your server in something more efficient and just use unity for 3d visualization.

The first step in coming up with a networking solution is coming up with some solid design diagrams of how you want your game to work, game size, how many players etc. You cannot afford to be wishy washy and vague with this, because the networking design will limit what you can achieve gameplay wise later. Maybe you can link to some posts if you have discussed this previously.

Many of us may be familiar with various multiplayer / networking strategies but might not be familiar with what unity has to offer in this department, so you probably either need some input with someone familiar with unity networking or you need to thoroughly read the docs and understand them to get the pros / cons.

@lawnjelly I'm not struggling with netcode, or design.  I'm struggling with a lack of server hardware that can run physics simulations.

If you know of a C# physics engine that will run on a virtual machine without graphics hardware access, I would love to know about it though! 

For what it's worth Unity really has nothing in this department, that's why there's so many ads on here for Unity network game service providers.

I've spent the last several months trying to figure out how to wrangle client physics without a central physics simulation, simply because I can't afford to build one, not because I really like doing things differently..  Though I do that too...

So, it seems I either have to centralize the physics into a server program I might never be able to see working on the internet, or remove nearly all of it and cross my fingers that I can deterministically simulate physical effects well enough to make it look believable.

Just not a fun place to be at the moment.

Here's an idea I had that I think I might try when I get that far. It's not perfect. There will be some artifacts in that you might see something different from what another player sees. But there should be no divergence. Basically the idea is the physics/movement for any given object is calculated by whatever system controls that object. For instance if player A runs into Player B, Player A may bounce off of player B but according to B the collision may never have happened.  So he might see player A just kind of bounce back a bit off of nothing.

So of course there is the problem that A and B may run to the same spot at the same time so they end up occupying the same space when everything is resolved.  So what we need to do is implement a kind of sloppy collision, between players. Basically a collision isn't so much a collision but results in a force vector pushing you away until you are no long touching. But again the force vector for Player A is resolved on his client and for Player B on his client. The server simply gets the position updates.

The reason I came up with this, is that I noticed in EQ 1 they had player collisions and they seemed to work pretty well. When I started playing WoW they just got rid of them for whatever reason.  My guess is they didn't want to deal with certain griefing aspects of P-to-P collision.

Then I played Age of Conan for a while and again they had them but the problem is you would often collide with something that wasn't there (or probably was there on the server but not for you) and I found that completely annoying.  My theory is, if you are going to have player to player collisions, you should collide with what you can see, and if it looks a bit different to another player, that's OK.  But at least you will never run into an invisible person.

This is probably only applicable to certain kinds of games but I just thought I'd mention it.  There is also the hacking issue but I had a few ideas on how to minimize that problem.

@Gnollrunner a much more vague version of that is sort of what I saw happening in my game.  In fact, the only entities that use physics for movement are the entities directly controlled by the player...  The network player objects are all kinematic, animated and interpolated...  I actually wasn't planning on propagating physical effects from client to client either.  Every multiplayer test I've run so far looks pretty good too.  Including players running and colliding off of each other.  The network player is slightly in the past, but that occurs in centralized simulations too... 

This is getting a bit ridiculous..  Every time I think it will work somebody convinces me that it's going to fall to pieces.  Every time I agree that it will fall to pieces, I find, or somebody gives me a reason why it might not.  Lol!

I may just have to keep on keepin on until one of the two actually shakes my hand or kicks me in the junk.

Gonna sleep now though, almost 2am here.  

Thanks for the replies everybody! 

Love to hear more of ya got em.

1 hour ago, Septopus said:

This is getting a bit ridiculous..  Every time I think it will work somebody convinces me that it's going to fall to pieces.  Every time I agree that it will fall to pieces, I find, or somebody gives me a reason why it might not.  Lol!

IMO, unless you understand why it definitely won't work, you might as well keep going in that direction until you encounter some show stopping problem.  Much of the stuff I write, I come up with myself. Sometimes it works great, sometimes I have to scrap it. Either way I learn something.

2 hours ago, Septopus said:

@lawnjelly I'm not struggling with netcode, or design.  I'm struggling with a lack of server hardware that can run physics simulations.

If you know of a C# physics engine that will run on a virtual machine without graphics hardware access, I would love to know about it though!

Typically for the kind of game I *think* you are referring to (there was no clarification on this), I would be asking whether the server actually needs to run any 'physics engine' type physics at all? For supporting a large amount of players you might use something simpler like a navmesh, with some very simple repel / slide movement. Real physics is often reserved for 'eye candy' on the client which is not gameplay critical.

Overall the kind of questions I would be asking is, where do you intend to go with this design? Is this a learning exercise (in which case you can just pretend you had great hardware and run a local server and see what happens)?

If you are seriously intending to create something supporting lots of players I think you need a plan, in terms of paying for infrastructure, how are you going to get players, will you have enough content etc. Big companies throw millions of dollars at this problem and usually fail spectacularly.

In either case I would be assuming you had already built plenty of smaller scale networked games, otherwise you are trying to run before you can walk, so to speak.

Thanks @Gnollrunner that's usually how I approach things too, but sometimes when everybody is screaming fire you start to feel warm even if you haven't reached any flames yet.

@lawnjelly What you see on this here blog is what there is.

I don't work on plans, I work on ideas.  I formulate a plan only once I've realized the idea.  If the idea isn't sound, the plan WILL fail.

I thoroughly madden girlfriends, bosses, managers, and friends.  That's why I have none of the first, got rid of the second two, and maintain only a few of the last.  lol

I do everything with scale in mind, I was a Systems Engineer who designed internet scale infrastructure when I had bosses and managers.  I've written rfc compliant server/client systems and many custom ones over the years..  In fact, understanding the client/server model is pretty much what a Systems Engineer is employed to do.  So, I understand the underlying hardware and software requirements that are needed to support network loads/etc..  And all that with only a high-school education, so I've learned to run pretty quickly over the years.  There's never been much time for walking in my life.

The "IDEA" I'm working on is an mmo game running on distributed(relatively low resource) servers without a central physics simulation, I just made the erroneous assumption early on that I would still be able to use client physics to do some really fancy things.

The issue here is TRULY JUST the synchronization of physics that I've never really had to consider before, every other aspect of the game's network/servers has been roughed out and tested already.  And honestly, I'm not SURE I need physics for most of the stuff I've been using it for, so that's what I'm going to explore next.

And really, I think I've been listening to too many people who have no idea what I'm working on and can't handle the idea of somebody working without a fully detailed plan.  So they just give me the standard canned rundown every time I try to ask a specific question, because I'm terrible at providing a reasonable context.   And MOST of my game mechanics haven't even been fully conceptualized yet, mainly because I don't know what the final constraints on them(physics) will be.  Chicken, meet egg.

I work this way so I can change it up whenever I like, aka. fail softly.  hahahaha!!

Are you making something like block-chain client~servers?  

1 minute ago, Awoken said:

Are you making something like block-chain client~servers?  

I'm not really sure what you mean, haven't really studied how the client-server relationship works in block-chain..  Just some of the hashing proof of work mechanisms and that sort of thing.  I'm employing some of THAT as a salt and pepper of anti-cheat/anti-hack code.  Also planning to use re-actively complex p.o.w. hashing for the login process and anything else exposed to nature, to help prevent ddos and brute force.

As well, given the distributed nature of the system, I could incorporate some block-chain derived peer-verification type schemes if I run into a need.  And I might. 

So, I'm guessing that I could probably say the answer to your question is likely YES..  Though I can't say that for certain..  hahaha!!

Most "distributed" systems end up looking the same from at least a few angles anyhow.

I have considered putting a pub/sub broker in the client as well, that would complete the full client/server double-punch!  But that would have to be a "user really wants to host a node!" kind of thing.  In which case anonymous peer verification would probably be wise.  To keep rogue nodes from springing up..  Not quite there yet.. lol.

There's also the very real possibility that I DID study block-chain more in depth than I remember, a long time ago and have subconsciously designed using the bits I liked...  I've spent a lot of time reading the random and interesting on the interwebs.