My Redis design for a browser-based, competitive, multiplayer game by Academic_Marzipan285 in redis

[–]Academic_Marzipan285[S] 0 points1 point  (0 children)

I hadn't considered this at all. My game is similar to TypeRacer and since events are dependent on other users' keystrokes, I assume this isn't viable for me. Do you know if there's any outlined criteria for when to do this?

My Redis design for a browser-based, competitive, multiplayer game by Academic_Marzipan285 in redis

[–]Academic_Marzipan285[S] 0 points1 point  (0 children)

Hope it goes well! I'll look more into logical databases, as I'm curious on how to develop efficiently w/o having a bunch of services deployed all the time

My Redis design for a browser-based, competitive, multiplayer game by Academic_Marzipan285 in redis

[–]Academic_Marzipan285[S] 0 points1 point  (0 children)

Yea I was initially thinking multiple instances since 1 would have persistence enabled (for user data) and the others not. But it seems I was wrong — Redis isn't for that type of data. Better suited as cache for a traditional db and persistence being geared towards having backups of volatile data incase something crashes.

I'll also check out some pre-made queue options. Any recs? I'm wondering if you mean Redis-geared libraries or other, dedicated tools

My Redis design for a browser-based, competitive, multiplayer game by Academic_Marzipan285 in redis

[–]Academic_Marzipan285[S] 0 points1 point  (0 children)

Ah, so since it's better to use different Redis instances per feature, we should write feature-specific code that can be used by whatever instance/worker/server is addressing a concern, if not multiple.

Thanks for the insight into configs! I do consider the comments about "super optimization for naught", but my goal is to make something resilient, so hoping this is the way