1 hour ago, Septopus said:

Making it "windowless" or "headless" as it were, doesn't necessarily negate the need for "physics/graphics" hardware for many engines.  I called it 3D hardware, but in this case it would be the physics hardware, usually supplied as part of the graphics hardware.  Many engines only work with hardware physics support. 

IIRC Bullet has a GPU version that's separate from the CPU version, and PhysX can optionally use a GPU for acceleration. Typically GPU physics is only used for "optional" calculations - graphics fluff like sparks, debris, animated hair and cloth, etc... 

I don't know of any physics library that doesn't work without a GPU. 

Cool, thanks for all that!

I will certainly look into a C# wrapper for Bullet or ODE.  When you don't know what to look for specifically... Well..  You don't find much.  

I'm also just 1 dude with a project that already spans 2 operating systems and about 15000 lines of code between its 8 major components, so I have to keep the tinkering to a minimum. 

That Unity project you worked on, just out of curiosity, how many man hours did it take to get it working like that?

After my most recent re-examination and these many subsequent discussions I'm almost certain I can achieve the desired game-play as well as the overall look and feel I require, without using an "authoritative" physics simulation at all.  The client will be using its physics capabilities to motivate objects it "influences/owns" only.  You can check out the most recent posts on my blog if you want to see what I'll probably never be able to succinctly explain.  

Thanks for giving me some very specific paths to explore.  Always happy to see all the angles and learn all the ways.  

1 minute ago, Hodgman said:

IIRC Bullet has a GPU version that's separate from the CPU version, and PhysX can optionally use a GPU for acceleration. Typically GPU physics is only used for "optional" calculations - graphics fluff like sparks, debris, animated hair and cloth, etc... 

I don't know of any physics library that doesn't work without a GPU. 

Well, apparently I was looking up engines and not libraries.   And not very thoroughly at that.

Game physics is not a topic I've studied much until recently.  If that is not apparent.  Lol.

I'm gonna look into a few libraries with C# wrappers, but this discussion is mostly academic at this point as I believe I've solved the riddles I was struggling with.  Without an authoritative simulation at all.

I did hint at this in an earlier post, but to ask directly, have you written any smaller scale multiplayer games?

21 minutes ago, Hodgman said:

IIRC Bullet has a GPU version that's separate from the CPU version, and PhysX can optionally use a GPU for acceleration. Typically GPU physics is only used for "optional" calculations - graphics fluff like sparks, debris, animated hair and cloth, etc... 

Yes, Bullet3 runs on the GPU afaik. Bullet2 (which is still regularly updated) runs on the CPU. When setting up PhysX you provide it with a dispatcher, which the library uses to do its work. There is a default one which sets up a thread pool and uses that, ie. it runs on the CPU too, or you can provide your own. You can also run parts of the simulation on the GPU, although I don't have any experience with that.

24 minutes ago, Septopus said:

That Unity project you worked on, just out of curiosity, how many man hours did it take to get it working like that?

This is a difficult question to answer, because it worked like that from the very beginning. There is actually very little up-front work to do to make it work like this. Basically you need to:

• Make sure the simulation code does not use any Unity code (it is easy to make the server compilation fail, by accidentally using unity code later on), but this is easy to do if you know of the limitation from the start.
• Write some kind of bootstrapper for the server code. This can be a simple as a main method which starts up the server loop. On the client this is typically handled by the game engine, ie. Unity in this case.
• (Optional) Write tests that verify that the code behaves the same on both C and S. When we did this Unity was using a very old Mono runtime, which caused some headaches. Certain code behaved differently on Unity vs the MS .net runtime. Afaik Unity now uses a more modern runtime, so this might not be an issue. There could still be some problems, eg. if you run the clients on ARM hardware and the server on x86 etc.

31 minutes ago, Septopus said:

...this discussion is mostly academic at this point as I believe I've solved the riddles I was struggling with...

I am glad you figured it out, good luck with your project!

57 minutes ago, Hodgman said:

 Typically GPU physics is only used for "optional" calculations - graphics fluff like sparks, debris, animated hair and cloth, etc...

Really?!? Well, I may have to look into that myself when the time comes. I was thinking I would do my physics on the CPU since I did collision and gravity before and it worked well.  But just doing animation related physics on the GPU sounds like a great idea to me, since it really doesn't affect anything else.  It's always cool when you can pick up tidbits reading other people's thread ?

8 hours ago, lawnjelly said:

I did hint at this in an earlier post, but to ask directly, have you written any smaller scale multiplayer games?

Nothing like this.   Tons of multi-user client/server applications and etc. though.

Also, previous experience wasn't really a requirement for the job either. hahahaha

I have addressed this before, but I've never been one to walk before I run.   I've been imagining this game system for actual YEARS now.  And if my lack of multi-player game specific experience was hindering me much I wouldn't have an online multi-player system already working, I think I tackled that first because I didn't know how to do it, only took a few weeks to hammer out.  The only aspect of "game" programming that I've discovered to be highly specific to "game programming" is the physics bits, which I believe I've now fairly sorted, with the wonderful help of all you brilliant folks!!

Cheers to you!

p.s. for what it's worth, this is my first ever 3D game too.   Bwahahaha, funny, but no joke.