Hello, I've got some systems working, a solid playable game up and running at least in the sense of a small population, but far from proficient in my understanding of optimally managing [data persistence/caching]. I'm hoping some light can be shed on where I'm lacking in knowledge.
Various Situations:
1. Player wants to find friends to add, clicks friend applications button, a refresh-able list is generated:
2. Player wants to search from a list of guilds, clicks guilds button, a refresh-able list is generated.
3. Player wants to add someone from chat, clicks chat, and the log of players that have chatted within a certain duration of time is generated, from which things such as adding that player as a friend can occur.
4. Player fights in an arena battle and the arena battle leader board is updated based on accrued points by said payer.
General Issue: Basically this deals with (data persistence vs. when to update data), the balance between keeping data around on the client side that overtime becomes less accurate when it isn't updated vs. frequent updates with accurate data but at a significantly greater cost to the system due to the frequency of said updates. What I'm mainly trying to figure out is that balance between accuracy of data vs cost of accuracy.
Game Context: The game I'm working on is quite asynchronous, a player could play it single player without much of an interruption. There is no instance where two players would be directly interacting with each other in a real-time fashion, except for maybe chat (with time limits on messages sent). PvP would be the typical "Set your defense, and other players will battle that defense data when they are online". The game is mostly based on time passed rather than direct inputs by the player (Idle in nature). Hope this helps get a sense of what I'm working with.
Questions (Mostly about player data persistence) :
1) Would a list of players generated immediately on input based on player segment filtering be viable?
If this is viable how do I ensure that the player isn't over-taxing said searches? What's a solid rate of continuations based on batch size?
2) Would a list already cached on the client side, filtered on the client side, and updated at a certain frequency through player segmentation be viable?
If this is viable what is an acceptable rate for updating a list of players through player segmentation that will then sit on the client side? Every hour, 6 hours, half a day, 1 day?
3) Would it be viable to utilize a scheduled task which pulls a player segment, stores this data in title internal data, and then is sent out to the player at a certain interval?
If this is viable then what's a solid rate for this to occur? Every hour, 6 hours, half a day, 1 day?
4) Let's say their is a refresh button, to populate a different list of potential friends, I'm assuming that it's best to already have the data on the client side at this point, and continuation occur in a client-side manner (basically just loop through the next batch already on the client side) rather than calling in a new continuation from the server?
If the former case is preferable, is there a recommended scale, or at least a general limit in terms of scale for batch size when generating an adequate friends list source of data? For instance, let's say you have 10k active players in the server, would a list of 100 players suffice, 1000, more? This is more of a "it depends on your game", but I'd like even an opinion in terms of scaling player lists based on player population in the server, for say a player that has a max friends list of 30.
5) Is there an alternative, potentially more optimal method to handle these various instances where "finding players" is required? (Is calling GetPlayersInSegments, the optimal way, or is there a better route I could take?)
Thank you for your time,
1Step
