There may have been another thread that discussed this in detail recently. In that game setup it was more about just player stats being shared between ‘games’ but it still might be helpful.
The idea was that a regular REST web server would coordinate the “outside game” data, accounts, etc… Each “game” would have its own data, ie: own entity day, own server, etc…
Yeah, that was about the separate hosts and separate players, but in this case it’s about the same host, same game and same players but the different level in the game . So I was not sure if I should follow the same principle here.
Yes, this was in mind to use rest to save player entity data, but I was not sure if this is right, because player data are actually game objects. but will give it yet another think. Thanks.
Unless your game is huge with 50,000 players in a single “game” and 9,000 levels with a hundred million entities each, it would be tempting to just put it all in one DB.
My Outside Engine puts everything for all worlds in the same database. There is a users table for account info. A characters table for character data for both users and npcs. A npc table for NPC specific data. A world_items and world_objects table for objects and items in the game world. Each of the world tables use virtual tables via partitions to separate the data per world. This is done using postgres. This way a single table is used for the querries, but behind the scenes the worldId actually selects different table partitions. The Outside enigne supports multiple unrelated games and their worlds using this structure while allowing a universal user account.
Personally I’d put it in a single database because it’s the same stuff. Collating data cross-databases is expensive, too, so reading multiple databases and then possibly re-organising it based on collated data will be a pain and an area of both expense and maintenance.
I’d suggest keeping all data in the same DB - preferably one you have good admin access to outside of your game engine. This makes things a lot less error prone and much simpler (no chance for data loss or duplication due to a failure at an unlucky time).
You might want to look into Apache Ignite (https://ignite.apache.org/) - it greatly simplifies managing server-specific data, locality, and persistence, and it can be used in a very lightweight embedded mode.
And to note, a lot of database layers have multi-threading built in (connection pools) which is also a bonus - saving you the effort. All roads lead to a single setup for me.
. So I was not sure if I should follow the same principle here.