Create Multiplayer without Photon or UNet

Hi, guys,

I am studying at college and one of the courses I have is Distributed Systems. In this course, my group and I have to create a project and we have to implement something that uses a Client-2-Server or P2P style. Our first idea was to create a 2D/3D game that has a multiplayer mode in it. However, we presented the idea to our teacher and he said that the tools Unity has, such as Photon or UNet, are "too simple". He wants us to implement the communication part, creating sockets or something else in order to achieve the multiplayer part.

I researched a little bit and found that it is possible to use JSON to create this part of the game, but I am a little bit lost in what I should do. Anyone has tips in this part? I don't know how we would be able to synchronize players' positions and also share vital informations of the game without using Network Manager or Photon Unity.

Thanks in advance!

 

You can use sockets in Unity, no problem. If you've been working with sockets on the course already, you should have no issues at all, if not, do some googling/youtubing on using sockets with Unity. You're bound to find a ton of stuff and some snippets of code to start you off.

Best of luck (skill)!

 

Thank you, Luke! So, basically, I have to create a socket between client and server, which will be responsible for sending vital informations, such as players positions and other stuff... Would you recommend me TCP or UDP ? And would you recommend me implementing everything in the client side, so the server would be only responsible for receiving/sending data or do you think it would be best to implement a part of the game(rooms, maps,for example) into the server part?

Thank you again !

 

TCP vs UDP depends on the game.

TCP is simpler to implement, but that simpler implementation is because of higher level functionality that is not necessarily optimal for some types of games across all data being sent. Often those games TCP is not great for are fast paced games where much of the data sent is outdated as soon as it is sent (such as high frequency position updates). Turn based games, card games, or really any game where lag isn't a big deal, TCP works great for.

UDP has a more complicated implementation because you still sometimes will want some of that higher level functionality, but will want to use it situationally.

For example, TCP offers packet reliability on all data sent, while UDP does not. Even in games where most data sent does not need to be resent if lost, you'll still have things like telling all clients to start a match, or telling a client that their player has died, that you will want to send reliably. Doing so will require building your own packet reliability system on top of UDP that you use as needed instead of across all packets.

Where you implement maps, etc, again depends on the design of your game. Is one of the player's hosting the match? Is this a dedicated server? Does the game's nature require the client to be authoritative of certain data?

Generally it is best if the server runs as much as possible of the game, and the clients simply display what the server is sending and send inputs to the server. This reduces the possibility of cheating, and makes for a rather clean delineation of who owns what data (the server owns everything, simple). This doesn't work that great in games like FPS, where you need really smooth and responsive motion, as well as bullets flying exactly when and where the client firing them experiences them. So FPS games often use client side authority for players and the bullets they fire (which is also why FPS games are one of the most common genres associated with cheating).

 

I would add that if this isn't going to be a massive game, but more of a proof-of-concept for coursework, I'd go with TCP as the reliability of packets is going to save you a ton of heartache. To go UDP and write a reliability layer, you'd be spending months reinventing the wheel, as there are numerous reliable layer UDP libraries out there already, and your goal is to write a simple socket using game.

 

It's not going to be a massive game. We don't have the intention ok keeping the project after the course presentation. Due to the fact TCP is simpler to implement, probably we are going to use it. Our first plan is to create a 3D FPS, but after the teacher told us he wanted something different, we are afraid of the amount of work that programming a 3D game + Client 2 Server style would take, and also the amount of time that it would take for us to find a way of sending all the necessary information ...

 

Use something like socket.io and dont try to reinvent the wheel

 

Keep it simple. No need to have grandiose plans for full 3D, lifelike avatars in a beautiful world. Your course is about sockets and networking, so keep that in focus. Go for 2D, and something multiplayer but simple. There's a ton of top-down assets available very cheaply on the store, giving you max time to concentrate on the networking. Max out the areas where the top marks are, skimp on areas where there are no marks.