4 Replies
basically lacking a kind of game loop running on the server...
(which again, convex will fix soon with real timers and such)
all of the participants of the game had to advocate for the game to advance
and so, really the game only ticked once, and fast5 uses convex's atomic transaction properties to ensure this happens
but everyone participating would kind of ping the server at intervals to "vote" for moving the game forward to the next state
and the server-side mutation, if it was time to advance, would transact the game state change exactly once to the next phase or whatever
this was definitely h4x, but it works
Can't see the game because my screen is too small 🥲 but if I understand you correctly, I would have each client fire a mutation to a separate table that it is ready to change a state and all the clients also use a query that checks whether all clients have done this, and when that is the case, it moves forward.
I wonder if I could make this problem much simpler if I just used UTC time on the client and just stored the start time - we aren't planning to have a pause button because it's a race - on the Convex database
because I don't think the way fast5 would be the right solution for a timer. Since it's a race, the timer is not the only way the game ends, it's a secondary feature.
@jamwt So I'm finally getting to implementing this timer, and I was wondering in terms of best practices and avoiding antipatterns, since my game is a race, I need the timer to be every second. I am thinking the person who is "hosting" the race will be mutating the database, but would I have the setInterval on the client and then the mutation function is simply updating the number? Is there another way that harnesses Convex better, and would this method I'm describing cause a compounding delay for the "guests" of the race if I am using a useQuery on that number?
no compounding delay! in terms of the "host" of the race calling the mutation, that works fine as long as it's okay that the game ends if the host leaves the game anyway, since the timer will stop being driven if that browser session disconnects
convex will automatically skip intermediate states on updates if things ever get delayed, so delays to the timer value won't compound
@Night at some point, if the code is OSS, feel free to share a link to it here and we'd love to give you more specific advice and general feedback when it comes to Convex best practices/antipatterns as you requested
Okay great! Yeah it is open source and once it is functional, which should be soon, I'll let you know. I'll also read up on Stack and in the Convex docs so I understand Convex better and the other features I can use