Unity instances for physics

Post here your questions about SFS2X. Here we discuss all server-side matters. For client API questions see the dedicated forums.

Moderators: Lapo, Bax

TomPo
Posts: 10
Joined: 08 Aug 2015, 21:57

Unity instances for physics

Postby TomPo » 23 Apr 2018, 16:08

Hello
Why sfs2x has no ability to:
- run instances of Unity processes (like execute new stand alone level etc) with for example -nographics parameter ?
- to connect via IPC, PipeLine, ZeroMQ, sockets or other solution to such instances ?

What I'm asking is why sfs2x is not able to run some physics. bounding box checking, raytracing using Unity engine ?

This is really great stuff (apart of this that I have to use Java on server side and c# in Unity - would be nice to be able to use same language)
but.... if you can't make even the simplest checking using the engine then this is useful only for games like Hearstone etc where there is no need to use raytracing or collision detection or any other engine behaviour.

Do you have a plan to implement such a solution ?
So when room is created is an option to start new instance of Unity level (new process) on the server side to be able to communicate with it ?

Without such a solutions sfs2x looks worthless in 99% of games, or maybe it's possible but I'm missing something here ?
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: Unity instances for physics

Postby Lapo » 24 Apr 2018, 09:30

Hello,
good questions :)

SmartFoxServer does not do physics because Unity already does it exceptionally well and it's integrated in the engine. Also simulating physics for 1000s of clients on the server side would be very resource intensive.

We think it's much better to let Unity do the physics, collision checking and ray tracing and let SmartFoxServer do the backend: matchmaking, buddy lists, user management, invitations, security, db integration, etc...

The integration between server-side Unity and SFS2X is relatively simple and I don't think it requires extra tools such as ZeroMQ and such...

To leverage the power of server-side Unity with SmartFoxServer you can use SFS to coordinate small Unity instances to handle the game directly, without using Java as a middleman.

Here's an example of what I am suggesting:
-> Players connect to SFS2X, where their account is stored together with their status (ranking, inventory, avatar cfg, etc...)
-> Players join the lobby and jump in a quick match or invite a bunch of friends to a private game
-> The SFS2X extension spawns a server-side Unity engine and tells the clients to connect to it
-> Players are now connected directly to the Unity engine and SFS2X

This approach requires no intermediary or complex C#->Java->C# conversions (with tricky serialization or type conversions), and it allows the Unity client and server to communicate directly.

Here SFS2X acts as a backend and orchestrator without getting in the way of Unity, managing Users, Rooms, buddy lists, launching Unity engines etc...

In terms of communication between the server side Unity engine there are a couple of solutions:
1- using the standard client C# API to talk to SFS2X
2- using HTTP/HTTPS calls via Jetty servlet

Unless you need continuous interaction between server-side Unity and SFS2X (which I don't think is common in most games) option #2 should be fine and easier to implement.

Do you have a plan to implement such a solution ?

Yes, using the approach just described we plan to release a series of "Unity integration" components to simplify the spawning of Unity engines and the interaction between the two.

Using interfaces and events the system could be extended to also support specific cloud environments. E.g. one could extend the components to work specifically in the AWS/EC2 environment to spawn new Unity engines in cloud-based micro instances.

Hope it helps
Lapo
--
gotoAndPlay()
...addicted to flash games
TomPo
Posts: 10
Joined: 08 Aug 2015, 21:57

Re: Unity instances for physics

Postby TomPo » 24 Apr 2018, 09:52

Hello
Thank you for the answer! :)

now... you said:
-> The SFS2X extension spawns a server-side Unity engine and tells the clients to connect to it
-> Players are now connected directly to the Unity engine and SFS2X

That's exactly what I was thinking about !!!

The solution where sfs is starting new process of Unity level (of'couse with -nogpraphics parameter) and (two options here)
1 all players in this room are "moved" to this level and connected to Unity level directly
after game is over Unity room sending all data to sfs, redirect users back to sfs (lobby) and at the end killing the process
2. Players are still connected to sfs and only we are sending via some PipeLine info to this level for physics (collisions, raytracing) updating only the position, rotation etc of the objects.

Whould be very very very nice if you will be able to make such a tutorial how to do it, and how to do it properly without bottlenecks and without killing the server. Of'course then number of rooms per server will be limited, what is quite common in today's on-line games.

In my opinion your approach is far better than built-in solution or Photon or Forge where client became a host - this is bad idea in my opinion in terms of cheating, reverse engineering or directly connect the client-host to the DB. That's why when I tried to made Heartstone-like game I found your solution the best and quite easy to use, but when came to try to make something different then I realized that I can't :( without possibility to do raytracing or collision detection. Like in your FPS tutorial/demo - so clearly we can see lack of possibilities to make raytracing when shooting to avoid cheating or walls hacks.

Hard question - when you will make such a solution/tutorial ? :D Can't wait!
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: Unity instances for physics

Postby Lapo » 24 Apr 2018, 14:20

Hi,
1 all players in this room are "moved" to this level and connected to Unity level directly
after game is over Unity room sending all data to sfs, redirect users back to sfs (lobby) and at the end killing the process

Yes
2. Players are still connected to sfs and only we are sending via some PipeLine info to this level for physics (collisions, raytracing) updating only the position, rotation etc of the objects.

I am not sure what you mean by "pipeline" here. Are you referring to the connection between the client the server-side Unity engine?
If so, yes I think the normal Unity networking API would be the pipeline :)

Would be very very very nice if you will be able to make such a tutorial how to do it, and how to do it properly without bottlenecks and without killing the server. Of'course then number of rooms per server will be limited, what is quite common in today's on-line games.

We're planning to publish an article on our blog in the next weeks.
As regards "killing the server". It depends how it's done and how heavy is the game world and logic in the headless unity. There's certainly a risk to use a lot of resources if, for example, you need 100 Rooms and each Unity engine uses 250MB of RAM... you would end up with 25GB of RAM just for the 100 Rooms. :shock:
Still doable, but requires hefty hardware.

I think another option is looking into working with a cloud API and spawning micro servers for each Room, though this approach definitely requires more work in terms of integrating the system with the cloud API etc...

We'll try to discuss all these aspects in the article.

In my opinion your approach is far better than built-in solution or Photon or Forge where client became a host - this is bad idea in my opinion in terms of cheating, reverse engineering or directly connect the client-host to the DB.

Indeed, there are many problems with client-only multiplayer.
They are easy to set up because you don't need the central server but sooner or later you will need a custom login/sign up system, database, security features etc... and it gets trickier as you have to rely on other services with integration issues, limitations etc...

We're interested in providing a solution like the one we've outlined here that integrates in the cloud (e.g. AWS) and currently we're working on new features to improve the integration of SFS2X in the cloud.

Hope it helps
Lapo

--

gotoAndPlay()

...addicted to flash games
TomPo
Posts: 10
Joined: 08 Aug 2015, 21:57

Re: Unity instances for physics

Postby TomPo » 24 Apr 2018, 15:13

Hi
I am not sure what you mean by "pipeline" here. Are you referring to the connection between the client the server-side Unity engine?
If so, yes I think the normal Unity networking API would be the pipeline :

Here I was saying about the situation when on one server we have sfs and level processes. So pipelline to communicate between sfs and each level on the same machine (Pipeline like part of Inter Processes Communication).

OK, so waiting for the article and some features, tutorials blogs etc to bring such a solution to the table.
Micro servers for each room (unity process) in the cloud sounds reasonable :) and players re-connected back and forth between sfs and unity level sounds like very good idea for me. You can always choose to keep everything on one BIG server - if you are reach enough :D or game not required as much compute power.

No graphics, no 3D objects, just map raw data and bounding boxes with position, rotation etc - in normal situation (like 20-30 ppl per room) - don't think we have to call NASA :D

Couple of weeks then.... fingers crossed :) Good Luck!

Return to “SFS2X Questions”

Who is online

Users browsing this forum: No registered users and 97 guests