Open pnarimani opened 3 years ago
novabyte
commented
3 years ago @mnarimani I agree this would be a useful feature but I disagree that for "fully data-driven games becomes very resource-intensive" because the whole API is batch-orientated so if you're smart with your data design for the game you can ensure that the user makes a single batch request to obtain the storage objects they need for their play session.
pnarimani
commented
3 years ago @novabyte Fair enough.
A question that comes to mind is that is it better to have all the data in one storage row or data should be split into multiple rows in the same collection and different keys?
Also to add more context, we have nearly 500KB of JSON data that client needs to start the game.
novabyte
commented
3 years ago A question that comes to mind is that is it better to have all the data in one storage row or data should be split into multiple rows in the same collection and different keys?
@mnarimani That's a great question though one I think is better for us to talk through on a forum post. In principle though its about which game screens will need data at game start and whether there's a natural separation in the data model itself. Also 500KB of data is not a lot 😉 I have seen and worked on games which require far far more information than that. Let's chat further on the forums.
I'll leave this feature request open because I think its a good addition to make for the storage engine API.
In Nakama, You can store public read-only data with the storage system. But there's no way to return the data only if the version in the client is different than what's on the server.
Without Conditional GET API, making fully data-driven games becomes very resource-intensive since you read everything from the database every time a user opens the game.