Closed Logerfo closed 1 year ago
Max players value is 255 because PlayerId is byte for lower bandwith. Also Players array is array of references because NetPlayer is a class. So it's size will be 256*8 = 2048 bytes. This isn't much.
so only one UDP port gets allocated and players are restricted to their matches more easily.
You can easily use one UDP port and one LiteNetLib instance (NetManager) and multiple ServerEntityManagers. Just add some header data like SessionId and forward this data to different EntityManagers
Max players value is 255 because PlayerId is byte for lower bandwith. Also Players array is array of references because NetPlayer is a class. So it's size will be 256*8 = 2048 bytes. This isn't much.
I'm aware of all that, but mentioned it because my first thought was to increase everything from byte
/short
to int
and cap them at int.MaxValue
but the memory overload was huge.
You can easily use one UDP port and one LiteNetLib instance (NetManager) and multiple ServerEntityManagers. Just add some header data like SessionId and forward this data to different EntityManagers
I'll try that, thanks.
Oh, just a quick follow-up question: if I use only one NetManager
, can I still have 255 players per match or I am supposed to fit multiple matches in this 255 player limit?
@Logerfo LiteNetLib can handle much more players. 255 its just limit in LiteEntitySystem. It can be more possibly (like 65535). But it designed for such games like CounterStrike/Battlefield in mind. And it less usable for MMORPGs because they needed a bit different and lightweight approach and doesn't require such precision.
I'm developing a game for less than 100 players per match, the issue I'm facing is with the matchmaking part. But I'll try what you're suggesting, thank you!
Indeed, the problem was my lack of understanding regarding the boundaries between LiteEntitySystem and LiteNetLib. I managed to write a matchmaking service without using entities and a relay server to forward data to each match entity managers, using only a single UDP port. Didn't use a header, though, but rather stored a peer:match
dictionary.
Although it took me quite a while to figure everything out and rewrite a lot of stuff, the final result is actually even shorter on code and more simple, both for client and server-side, which is fantastic!
Maybe a matchmaking module would still fit the library, but it`s not as demanding as I once thought, so I'll close this issue for now.
Thank you very much for your help!
Right now, this library doesn't seem to have a good support for matchmaking, because the server allocates memory beforehand for each one of the maximum player number, which restricts this very same maximum number, right now at 255. Also, each match being hosted on their own server means that each match allocates one UDP port. Because of those reasons, although It is possible to host a matchmaking server, they tend to scale poorly. I think it would be a good idea to implement a real support for matchmaking. Much of the server load can be lifted considering that the matchmaking only needs one entity per player, always of the same type. And, of course, everything have to be not pre-allocated. And more scaling-oriented implementations could be considered. Another feature that would probably be a rewarding effort is to allow the matchmaking server to act as a relay, so only one UDP port gets allocated and players are restricted to their matches more easily.