depending on how many decks you have you
depending on how many decks you have, you might want to split into a separate table with a reference/relation
18 Replies
putting everything into real tables is definitely on the todo list next to deck building
right now everything is just a big global redux state and I'm trying a 1:1 migration of reducers to convex mutations, loading the game with the right id, mutating the game state, and calling db.replace to update state and propagate to the players
cool. yeah, total makes sense to do this out of the gate, just pointing out that if your game design has individual documents get really big, that can slow things down over time
vs. relying on some sort of foreign key and secondary table
but some apps the docs are pretty bounded in size, and then you can often just keep this shape forever 🤷 . good enough!
that makes a lot of sense, atm it's just a big shared state json with 20-30kb but loooooooooots of room for foreign keys and other optimizations
so I'm not 100% sure how db.patch and db.replace work, but would that count as a 20kb database bandwidth per game action then?
1:1 migration of reducers to convex mutationsI love this approach, it's hard to beat one god object when prototyping and then you can add Convex without much trouble
@cyremur yeah, patch and friends are convenience functions to save you a bit of code in a read-modify-write cycle. under the covers, the operation is on the whole object
so if loading into a function with db.query and writing with db.replace both count as db bandwidth that's like 50kb of bandwidth per game action in the current state...
btw my account doesn't have this usage type component on the team page like in jherr's vid
yeah, so that'd be about 20k cycles on the free plan, and 1 million on the pro plan
lots more if you operate on smaller segments of the game
I see... right now everything is just GameState mutations and I feel like trying to optimize for only touching smaller parts of the gamestate is going to reduce my velocity too much
I might just do the quick and dirty convex drop in without fully typing out the gamestate just so I can see how it works in practice
re: that dashboard, we disabled that for now because we're not actually enforcing any limits
as we get closer to enforcing limits we'll reintroduce it with accurate statistics
makes sense
so the fun thing about this game is that a lot of the state is already designed like a database, there's fields, entities and statuses that are connected via what are basically foreign keys
so I can definitely see this work but there's a lot of indexing finetuning and code rewriting to be done
the good news is you can potentially only rewrite code in the convex layer and just join together the final objects if you wanted to keep the app the same
at least for mutations you could speed stuff up...
I mean 20k game actions aren't nothing, and if I foreign key out the cards and only load them on demand that's probably enough to severely increase available actions
also here's a sneak peak so you can have an image of my madness
very early
really cool!
"Let's mash up MtG and DnD combat, surely the gamestate can't be that complicated."
@cyremur the usage dashboard is back: https://discord.com/channels/1019350475847499849/1019350478817079338/1141473611799076864