Suitability Question

I am starting a new project and am evaluating Unity as a possible platform. Not being familiar with all of Unities capabilities, I'd like to make sure it is a suitable tool for the job at hand before I invest in learning the platform.

Based on the list below, is Unity very, somewhat or not suitable for the project. Also, any hints tips or possible starting points or other resources would be very much appreciated.

In short, this is less a game and more a 2D multi-user collaboration application with the following requirements:

• Multi-User
  • Peer to Peer
• HTML5/Browser-based (preferred)
• One "moderator"
  • Possibly multiple
  • Can add/remove/move assets to the shared canvas
• Multiple "participants"
  • Can move "their" asset(s)
  • Minimal other interaction
• 2D "canvas"
  • Background image asset
    • Layers?
  • Grid overlay (layer)
    • Scalable
  • Hide/Reveal portions (moderator)
  • Canvases can be prepared ahead of time and presented once a "session" is running

 

Unity supports a variety of 3rd party networking solutions, but choosing a browser based platform limits your options as WebGL itself only supports websockets, and only as a client. For peer to peer networking you need one of the players to initially act as a server to facilitate the connection, so instead you'll need to set up a server that your players connect to rather than true peer to peer. The fact that almost all players will be behind NAT routers anyways, means that true peer to peer doesn't generally work without hosting a server (outside of LAN games) even without the restrictions of WebGL.

FYI, the built in networking called Unet you will see in the documentation is deprecated and being removed this year, while the replacement is right now in alpha phase. The replacement has no support for websockets, so no support for WebGL, with no announced plans for adding it. So a third party websockets library is what you'll need for this.

Unity builds for web as WebGL, not HTML5. HTML5 simply lacks the graphics capabilities an engine like Unity would require, even if Unity wanted to support it. If you insist on HTML5 you're looking for a far simpler in capabilities engine than Unity.

These would all be concepts you would build into the code of your game yourself. Unity fully supports 2D games, and layering objects, deactivating/activating (hide/reveal) is pretty core to the system. I'm not exactly clear what you mean by preparing canvases ahead of time, but you could certainly make your game have functionality to prepare whatever your canvases consist of outside of a multiplayer game and bring them in.

If you need local storage for whatever these canvases are that the players will be creating, you'll likely be better off choosing a platform that isn't browser based (Windows/Mac standalone, etc), so you'll have better access to on disk storage than a browser. That would also open up a lot more networking options.

As far as should you build this game in Unity (or whatever non-game application it is), any time a Unity novice asks about making a networked multiplayer game the answer should always be that it is a bad idea. You're dealing with fairly advanced topics. Networked games are Ferrari's and Unity dev novices should be trying to first build go-carts, not Ferrari's. That said, there is nothing inherent to Unity that would make it bad for your project, it just comes down to your skill/experience level to realize it.

 

Joe,

Thank you very much for your reply, it addresses my main question of suitability to task.

As for the browser-based preference, it is just that, a preference, and it sounds like one I will have to let go (which I'm fine with doing). My next choice would be Windows stand-alone. With that in mind, can you re-address the networking options? To be clear, what I'm trying to avoid is the requirement to maintain servers to facilitate the multi-user aspect. Ideally, I'd like one player to act as host and other players connect there. The documentation that I've read to this point suggests that this is not out of line, am I misunderstanding?

As for being a Unity novis, while true, I'm an accomplished C# developer on several platforms and, as stated, looking for feedback on Unity' suitability to this sort of task.

 

How about using Unity for the client front-end with an ASP.NET Core SignalR application on the server side?

How do you feel about suitability to task with that in mind?

 

So with Windows stand alone, all of the available 3rd party networking API's are then available, including the alpha release of Unity's upcoming network API (I wouldn't use it, but it is available). You can find more information in the various threads over in the Connected Games forum.

The issue of not wanting to run a server though is not a Unity or game development issue, but an issue of how the modern internet functions. Virtually everybody has their computer behind a NAT router, with their computer assigned a non-routable IP address, with the public IP address assigned to the router. That means when a player wants to host a game they open up the port to act as a server on their local machine, but the router will still reject client requests because it won't know where to send them unless the player logs into their router, goes to its advanced configuration, and manually sets port forwarding rules for the ports your game uses to the internal IP address of their computer.

Look at your computer's own IP address. Typically your computer will have an IP address in one of the following ranges, which are not actually addressable by clients who wish to join your game: 10.x.x.x, 192.168.x.x, or 172.16.x.x - 172.31.x.x

Further reading:
https://en.wikipedia.org/wiki/Network_address_translation

That is typically not how it is done though, typically the creator of the game sets up a server which facilitates connections in some manner to get around the non-routable IP address issue. You could use a service such as Photon which is a combined network API and server side service for connecting clients, or you could roll your own server which provides match making (or otherwise allocating multi-user sessions), relay and/or NAT punchthrough.

https://en.wikipedia.org/wiki/Hole_punching_(networking)