# Async matchmaking like Farmville or Boom Beach **URL:** \ **Category:** Game Design\ **Tags:** docs\ **Created:** [December 1, 2020, 1:47pm UTC](https://forum.heroiclabs.com/t/async-matchmaking-like-farmville-or-boom-beach/1188 "2020-12-01T13:47:27Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![cloudAle](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.heroiclabs.com/cloudale/32/300_2.png) [@cloudAle](https://forum.heroiclabs.com/u/cloudAle)\ **Post date:** [December 1, 2020, 1:47pm UTC](https://forum.heroiclabs.com/t/async-matchmaking-like-farmville-or-boom-beach/1188/1 "2020-12-01T13:47:27Z")
Consider a farmville-esque game where user could visit another person village. This could be easily done with getting their village data in the storage The problem is how would I query a list of similar people? Say I fire an rpc that would gather a list of people with certain category (village prestige 100-200), this data itself could be stored on the account metadata, or a separate storage object for each user. How would I query according to that filter? Listing all storage collections with key “village\_prestige” would work but I don’t think nakama storage could filter based on query that is passed (e.g not returning all collection keys and then filter it on rpc). Thoughts on this? ---
**Author:** ![DaveOak](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.heroiclabs.com/daveoak/32/377_2.png) [@DaveOak](https://forum.heroiclabs.com/u/DaveOak)\ **Post date:** [December 2, 2020, 1:28pm UTC](https://forum.heroiclabs.com/t/async-matchmaking-like-farmville-or-boom-beach/1188/2 "2020-12-02T13:28:25Z")
I see no reason you couldn’t do this with custom SQL in your RPC. > **[Function Reference - Nakama server](https://heroiclabs.com/docs/runtime-code-function-reference/#sql)** ---
**Author:** ![novabyte](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.heroiclabs.com/novabyte/32/1324_2.png) [@novabyte](https://forum.heroiclabs.com/u/novabyte)\ **Post date:** [December 2, 2020, 11:59pm UTC](https://forum.heroiclabs.com/t/async-matchmaking-like-farmville-or-boom-beach/1188/3 "2020-12-02T23:59:04Z")
@cloudAle This is a great question. There’s two ways that I would consider to implement this game design with Nakama but I’ll first summarize the asynchronous matchmaking that you’re interested in to check that we’re discussing the same design requirements. In Boom Beach a player builds their island and explores the ocean around them to find opponents island’s to battle against. The game makes it feel as though the opponents are discovered as part of exploration but essentially the level of the opponent is within some ranges to make sure the game is competitive but also fun. This is an asynchronous matchmaking approach hidden within a fun discovery process for the player. It’s not quite clear in Boom Beach on what the set of criteria is that opponents matchmake together but we can assume there’s a couple of fields like: - Level - Base Power - There’s likely more to it but this is sufficient to demonstrate the approach. In Nakama we already support both match listings and the matchmaker which are great when the search criteria for opponents needs to be applied for realtime matches. The reason it works so well is that the data which is indexed to search on is tied to the lifecycle of either a multiplayer match or the socket connection of the user (depends on whichever feature above is used). In asynchronous multiplayer it’s tricker to determine how long the data to be used for matchmaking should live for and be considered valid. This is why up until now game teams that want to do async matchmaking with Nakama have used one of these two approaches with our help: 1. Use specialized indexes on a storage collection of objects and access it via optimized SQL queries. 2. Use the Bleve search engine with your own custom indexer on the dataset you want to matchmake over. You can see that the two approaches require deep and meaningful knowledge of the exact fields to matchmake on and how to maintain the dataset and queries in an optimal way. This makes it very hard for us to provide a first class API to do asynchronous matchmaking that is scalable and flexible enough for most games. Nevertheless its an area of real interest for me and I’ll continue to experiment with ways we could make this feel effortless for developers. If you can share more specifics for the criteria you’d want to search on I can suggest more specific example code that would help with the game design requirements. Hope it helps. ---
**Author:** ![cloudAle](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.heroiclabs.com/cloudale/32/300_2.png) [@cloudAle](https://forum.heroiclabs.com/u/cloudAle)\ **Post date:** [December 7, 2020, 6:53am UTC](https://forum.heroiclabs.com/t/async-matchmaking-like-farmville-or-boom-beach/1188/4 "2020-12-07T06:53:22Z")
Thanks @novabyte for the detailed explanation, while we’re going to go with the Bleve route, it seems that it’ll be smaller if we just index userId and power/village\_prestige, while leaving the data in the storage itself not on the bleve index. This means we do a bleve search, to first get user id and then do a storage get for village data for that user id Would this perform better than the one you’ve described above? Not doing any goroutine check to bootstrap / update data for the matchmaking process. This also means user hitting bleve index directly with rpc not into storage objects Would this approach be better? We haven’t done this preferably at scale so we probably be missing a lot of details / pitfalls ---
**Author:** ![novabyte](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.heroiclabs.com/novabyte/32/1324_2.png) [@novabyte](https://forum.heroiclabs.com/u/novabyte)\ **Post date:** [December 7, 2020, 10:45am UTC](https://forum.heroiclabs.com/t/async-matchmaking-like-farmville-or-boom-beach/1188/5 "2020-12-07T10:45:30Z")
> while we’re going to go with the Bleve route, it seems that it’ll be smaller if we just index userId and power/village\_prestige, while leaving the data in the storage itself not on the bleve index @cloudAle I would definitely recommend this approach. It keeps the in-memory index small and you can use the results of that index query to fetch the objects in a single batch read from the storage engine. > Not doing any goroutine check to bootstrap / update data for the matchmaking process. This also means user hitting bleve index directly with rpc not into storage objects […] > Would this approach be better? We haven’t done this preferably at scale so we probably be missing a lot of details / pitfalls I don’t quite follow what you mean. Hit the Bleve index in the RPC is definitely what you’d want to do it’s what we do in both match listings and the matchmaker. The rest of what you mentioned is not clear to me.