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.
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.