koobas.hobune.stream
Best solution for low bandwidth multiplayer game
Hi, I'm building a puzzle game which will have multiplayer (with matchmaking) and I'm looking for best solution for it. There's a lot of going on with Unity Multiplayer (FPS especially) but I got a feeling I might get away with something really simple but I want someone more experienced people thoughts on this.
Let's say game is similar to Pentominos (see image) where user needs to fill all grid with given puzzle pieces. Essentially this a singleplayer game but if we take it to multiplayer level, each player would be filling their own grids as fast as they can. Who does it first - wins. Main network traffic - each player would need to see other players grid 
.
That's basically it, I'm looking for guidelines (or maybe some examples?) how would you implement this? I already have my own dedicated server that has all players info like "coins, rank, etc" so I assume I could use it as "matchmaking server" too?
Key points:
Matchmaking on your own dedicated server. How to? Brief guidelines?
Connecting two players to share low bandwidth data. How to? Brief guidelines?
Think about if the player actually needs to see the other persons grid or just know about how much is done? $$anonymous$$aybe consider another option. Have each players game "report" to the other game a "lower resolution" version of the grid with "block" representation of the players progress almost as if you cut the grids resolution in half or thirds, much like how large .gif/.jpeg pictures load on slow connections before filling in all the details to show a general representation of the other players progress. In the picture example above you could have a 3x5 "$$anonymous$$i" board that just gets filled with 1x1 blocks if that "region" of the other players board gets populated. This has many advantages to actually showing the other players board..
1) If they are playing the same exact game you cant see what they are doing 2) You only need to report 15 spots being populated with a block as opposed to showing the actual objects shapes and placements (i.e. significantly less data transfer) 3) This could be supported by "messages" between the apps (like AddBlock(1,3) to populate square[1,3] or Remove(1,3) to remove square[1,3]. This would be communicated between apps using a command, parameter type message (i.e. send a command and its parameters) with the same type of methods you would push things on a stack but ins$$anonymous$$d of a stack its a communications link between 2 apps where you can pass messages. 4) This would allows allow you to "represent" the other players progress on a much smaller board then the one the current player is playing on so it uses less real-estate on your screen 5) Command/Parameters can be any thing you define as part of the messaging protocol of your own design (using enum/defines, and you can allow commands to have different number of parameters just like pushing things on a stack, the other app pops() the communications stack and pulls as many parameters it needs for that commands
@dajohnso thank you for your reply. Pretty much you've described, that's how I already saw this game. I like your solution with stack and push / pop I will consider it as a possible solution. Appreciate it.
I've decided to try Mirror asset due to the following reasons:
It seems it has high level API, built in KISS principle which should make it easy to use.
It can do everything I would need for this project (double checked with people on Mirror's discord chat)
Also this asset is constantly being updated with all changes Unity is currently making to their networking, which is really promising.
There are many people using it so there is really low chance of this going to deprecate
Really high ratings on Unity
It's completely free
If anyone doesn't seem to like Mirror, I would suggest to try @dajohnso solution, that he described on his reply to my question. I would go for that one if not Mirror.
