thread
Theory-craft this with me.
If you were going to re-create this game: https://cardsjd.com/minesweeper/game/#/menu (which is a multiplayer minecraft game) using Convex.dev how would you go about it?
Some issues I have been 🤔
1. How do you represent the grid of cells?
A medium sized grid would be 64x64 which is 4096 cells. Now not all cells require actions, a lot of them are automatically revealed as per the rules of the game.
What could the schema be? Would you store the entire grid as a
v.bytes()? Im concerned that each and every cell change would result in a LOT of data being sent to the clients.
Would you store a list of "actions" then replay the actions on the client to get the state? Then use a paginated query where page is size of 1 to only get the one action added?
2. How would you think about epitomizing this?
4096 cells is what like 2000 actions per battle? If you have like 10 battles an hour thats 480,000 function calls per day JUST for the cell turn actions, not to mention all the re-fetches of data for each client.
Im also thinking about leaderboards and things, if you want to keep a running leaderboard per battle that summarization could be expensive as that would also have to update frequently.
...
Ye so maybe this idea wouldnt work from a cost perspective on Conevx, thoughts?
3 Replies
🧵
hey! we explored a lot of these questions for AI town, where we wanted to have a realtime, interactive game that didn't quickly blow through a free account's limits. here's some notes on its game engine's architecture: https://github.com/a16z-infra/ai-town/blob/main/ARCHITECTURE.md
we hit database bandwidth limits before function call limits for AI town. here are some thoughts about the data model for optimizing bandwidth for minesweeper:
- the core game state is (1) which cells have a mine, (2) which cells are uncovered, and (3) who uncovered each cell. the minimum read size for convex is 1KB, so I'd break up a board into chunks that are roughly 1KB and use a bitset / other compression techniques for fitting as much of the board in 1KB as possible. so your schema would have multiple documents per board, each storing a chunk in a
v.bytes().
- the numbers and flags are all derived and the same for all players. so, I'd compute that on-demand with a per-chunk query that gets cached and shared across all clients. then, only the call to fill the cache after an update will consume database read bandwidth.
since we ideally want the mine positions to be secret and not sent down to clients, a replicated input approach won't work. (clients won't be able to replay the actions without knowing where the mines are.)
on function counts, yeah that's the rough order of magnitude. the number of mines is probably a bit lower than 50% right? expert on ms minesweeper is a 36x16 board with 99 mines. but yeah, per player click, we'd have...
1. the mutation to click on a square and write its updated state back out.
2. the first query to compute the touched blocks' new states and fill the cache.
3. subsequent queries to read the cached value. these charge a function call each but take no bandwidth.
for the leaderboard, I'd recommend just computing it client side. if the per-block information already has who revealed which mine, we can compute scores from that client side (maybe with some memoization), compute the sums, and then sort by score.awesome thanks for that input @sujayakar ! im going to think on this all a bit more