Sign In Register

How can we help you today?

Start a new topic

Best way to store and read data

Hello, I have been working with game sparks for a couple of months now and I have a few questions but first some context.

Our game has players that explore multiple maps revealing fog of war with different types of units and they can deploy buildings in said map in the areas they explored.

So far I am keeping the buildings data , fog of war data and information about the map itself each in their own data types 

and I access each document in these data types using playerID + mapID ( entry name) and I do not use indexed fields at all
My question is whether there is an advantage or disadvantage to accessing documents using their IDs directly or using indexed fields?

Also Should I create a separate document for each map for each player ? or keep all information of a map building data under one entry for example 

   

{
   mapId:
         {
           Data: " data",
           Data : "data"
          },
  anotherMapId :
          { 
           Data: " data",
           Data : "data"
           }
}

   

I know that there is 400 Kb limit per document however I do not know if the size of the documents matters in the time it takes to retrieve that document , and what happens when the 400Kb is exceeded ? I have a player that has this limit exceeded ( the buildings data type) what is the best way to deal with this problem ? 


Also another question, I am using my own custom data type to keep track of player currencies, since I thought if am using custom data types I would keep using it for player data as well instead of relying on existing player collection in the system .  Is there any advantages to using player collection that exists by default in game sparks?


For the first question, I think the difference between UID access and index/query access is when you have big stores of information that you want to list out multiples of. If someone has a ton of Rhyhorns in Pokemon, for example, they want to see all of them in a list.


If you do not want to store fog-of-war client side, then I think you'll need each player have their own document, with fog-of-war data grids (radius or square area) at whatever resolution, being marked revealed/unrevealed. If fog-of-war is client side, then I wonder why you'd need each player have their own doc per map.

Hey Russell , thanks for your reply , well the fog of war data is stored on the server side not client side to avoid any cheating , what about the existing player collections is there any advantage to using them ? should I just keep using my custom data type for player data?

Login to post a comment