search

yazoo321 / mmo_server_with_micronaut

Hobby project to create mmo server using Java Micronaut with JWT Auth, postgres and mongoDB support
73 stars 27 forks source link

Tracking nearby players #37

Closed datoslabs closed 5 months ago

datoslabs commented 5 months ago

Hi Yaz,

First of all, thank you for this repo and your blog! I am still evaluating backend server implementations for MMO, I am new to game development and UE so I have learned a lot from your blog.

WRT tracking nearby players, have you considered using GeoHash to determine if a player is nearby? I am still new to your repo and I am new to socket programming too so my suggestion may be off base, if so, please disregard. My understanding is that MongoDB is primarily used to track players and determine who is nearby; however, if we geohash the actor's previous and current locations; we could determine neighboring players who needs to subscribe to the actor's update based on actor's geohash without the need to store data in MongoDB nor store/maintain Set<String> trackingActorIds in each session.

GeoHash is based on z-order curve, another good reference is [Notes on Geohashing](https://eugene-eeo.github.io/blog/geohashing.html#:~:text=A%20first%20(and%20a%20good,Neighbours). Using geohash, the method https://github.com/yazoo321/mmo_server_with_micronaut/blob/ccd15457863e34000a4132292ead5006cc940473/src/main/java/server/socket/service/ClientUpdatesService.java#L137-L139 will take in Set<GeoHash> actorCurrentLocationHashes and Set<GeoHash> actorPreviousLocationHashes instead of actorId, ie actor's current/previous location GeoHash plus their 8 neighboring GeoHash, and the session will check its current GeoHash against actorCurrentLocationHashes and actorPreviousLocationHashes to subscribe/unsubscribe.

Best

Eric.

yazoo321 commented 5 months ago

hi Eric :) thanks for the post and feel free to join on discord where we can discuss further https://discord.gg/6e3KwQY8

in general, your understanding is correct the db is used to first initialize the players when they log in and keeps the session synchronised by occasionally querying what is nearby this is so we can leverage the indexes (which to be fair i haven't added yet and I may either change structure of data or consider different db entirely in future)

the motion is primarily kept in cache so its fast to access (for other services) and once validated, it's directly fed back, without even waiting for it to be stored

your suggestion is good, however it would only work if we didn't scale the server. assuming you've scaled it horizontally and had 2 server nodes running concurrently, you would not be able to use that approach, unless you create a separate (single) service/node keeping track of all players - which in fairness could work well too