3 ms·

I happened to use foundationdb for the leaderboards for an experimental game recently, for which fdb was the main experiment. The big difference was I used the

I happened to use foundationdb for the leaderboards for an experimental game recently, for which fdb was the main experiment. The big difference was I used the “record layer”, however, naively believing this meant only needing to understand the record layer . . . No. In foundationdb it is vital to understand all the layers up to and including the one you are using, partly so you can make sense of the documentation, but also because the problems you run into are so tied to the semantics of the lower layers. That said, the great thing about fdb is deploying it is so easy. It is like a secret weapon hiding in plain sight. The game https://luduxia.com/showdown/ https://luduxia.com/showdown/

dzonga 2y ago
beautiful game!! all on the web :clap
- fidotron 2y ago
  Thanks! I also added them to my other game that's been here before: https://www.luduxia.com/whichwayround/ https://www.luduxia.com/whichwayround/ The funny thing is I modeled the service for leaderboards on a commercial product an old boss of mine wrote v1 of in PHP/MySQL over 20 years ago. https://web.archive.org/web/20040806114005/http://www.macrospace.com/services/connectx_overview.shtml https://web.archive.org/web/20040806114005/http://www.macros... Games people end up with things like massively sharded mysql and replication fun. One of the nice potential things with fdb is keeping transactions within user scope, and not having to deal with the sharding/replication yourself, you just have to arrange the keyspace correctly instead. I have worked on games where people sorely underestimated the complexities of db replication and literally burned tens of millions in recovering from the mistake.
  - arnorhs 2y ago
    What are the defining features of this leaderboard model?
    - fidotron 2y ago
      It's dumb, and that's a feature! One of the main things about it is you don't want to be updating the service for every new game, so you defer as many decisions as possible to the game, and be ready for it to make changes over time. The nasty part is this significantly complicates extracting the data for the leaderboards as scores are added, but you do that once and it's done. On some level it's like mongodb with a special index type. A trend I see with too many efforts is to be way too overly specific, classically things like claiming something shuffling byte buffers around needs to know about the data format. You get surprising mileage and long term velocity out of embracing the lowest levels first, and allowing them to be built on arbitrarily later.

dzonga 2y ago

beautiful game!! all on the web :clap

fidotron 2y ago
Thanks! I also added them to my other game that's been here before: https://www.luduxia.com/whichwayround/ https://www.luduxia.com/whichwayround/ The funny thing is I modeled the service for leaderboards on a commercial product an old boss of mine wrote v1 of in PHP/MySQL over 20 years ago. https://web.archive.org/web/20040806114005/http://www.macrospace.com/services/connectx_overview.shtml https://web.archive.org/web/20040806114005/http://www.macros... Games people end up with things like massively sharded mysql and replication fun. One of the nice potential things with fdb is keeping transactions within user scope, and not having to deal with the sharding/replication yourself, you just have to arrange the keyspace correctly instead. I have worked on games where people sorely underestimated the complexities of db replication and literally burned tens of millions in recovering from the mistake.
- arnorhs 2y ago
  What are the defining features of this leaderboard model?
  - fidotron 2y ago
    It's dumb, and that's a feature! One of the main things about it is you don't want to be updating the service for every new game, so you defer as many decisions as possible to the game, and be ready for it to make changes over time. The nasty part is this significantly complicates extracting the data for the leaderboards as scores are added, but you do that once and it's done. On some level it's like mongodb with a special index type. A trend I see with too many efforts is to be way too overly specific, classically things like claiming something shuffling byte buffers around needs to know about the data format. You get surprising mileage and long term velocity out of embracing the lowest levels first, and allowing them to be built on arbitrarily later.