Filter game data according to player unlocks

Question

I'm currently developing an online "empire management" style game in HTML and Node. Along the game, the player will be able to raise resources (by creating farms, mines, raiding) to unlock new structures and rare items, etc. The same old drill.

All game data is in a server-side file which gets called and processed before sending to the player.

Now, when I serve the game data (containing information on building costs, paths to all imagery, etc) over to the client, I took a good care to filter it accordingly to the player's unlocked features (so to avoid people fiddling in the client-side code and getting access to the whole game data). I didn't really think about it when I made this, it just seemed "natural" to hide locked content. But now it is becoming a bit hard to keep data synced when the player starts to unlock stuff. I just regret this a bit and I'm starting to think it's not worth the hassle.

Now some questions arose in my mind: what is the usual approach to this? Do this kind of games usually send everything (which increases sightly bandwidth usage) or pre-process like I did (which increases server load)? Would it hurt the game experience somehow, especially considering many games have their own wikis nowadays?

(note that this is more of a concept question rather than technical)

Answer 1

It's likely not worth the hassle.

With a HTML+Javascript application, most of that data on the client will live in memory. Accessing it requires some serious fiddling with the debugger. Most players won't be able to do this. Those who are able to do this will just look it up on a wiki. The only information you must really hide from the client-side is any information which gives an unfair advantage in multiplayer if known (like enemy positions the player isn't supposed to know). Not because it would hurt their own gameplay (that would be their own fault), but because it would hurt the gameplay of other players.

Hiding locked content in the UI is mostly for the convenience of the player. It prevents them from getting distracted and confused while they are still learning the game. Another reason is giving the player a feeling of exploration. But anyone who takes the step of looking at the game code with a debugger has decided that they are not interested in the intended exploration experience and have chosen to pursue a completely different kind of exploration.

Regarding the bandwidth argument: How much data are we really talking about? Do the mere numbers and strings for each unlocked piece of content even exceed one kB? Images and audio, however, are a different story. When they are relatively large then it can make sense to only load these on demand. Not just because it saves you a bit of bandwidth but also because it reduces the initial loading time of your game. On the other hand, preloading everything can improve the experience during play. This is a tradeoff specific to the unique experience of each game.

Answer 2

I agree with Phillip that most of the time, people messing with the code is only going to hurt their own experience. He mentioned multiplayer as an exception to this, but I would also add in-game purchases (like with real money, not game currency), but it doesn't sound like you are going in that direction. A third way it might affect others is if you have some difficult-to-get unlock-able content that you want the player community to struggle to discover some time after the initial release of the game. Most games don't even bother trying to hide things like that, with maybe the exception of some MMORPGs.

Even if those things don't concern you, your current approach still has its benefits. Since the game is designed to run in a browser, your target players would get impatient in the case of a long initial download. Console and standalone PC games can get away with having the player download everything at once because they only need to do it once. With web development, though, you need to assume that everything goes away when you close your browser. Sure, the game could be cached, but you can't count on that.

On the other hand, it would get annoying having to wait a couple seconds between when you unlock something and when it is actually download it. It can definitely get messy on the programming side, since certain gameplay cannot happen until a download completes, and you don't know exactly when or if the download will happen.

Manage downloads by predicting unlocks.

To keep downloads from getting in the way of the game, you can predict what content will be unlocked next, and then begin the download before it is ever unlocked. It sounds messy, but it doesn't have to be. Just do the following:

1. Start the game with an initial list of unlockables. Since this list is only the names, or even just the IDs of them, it won't slow things down significantly at the start.
2. Each unlockable is assigned an initial state of "not downloaded" and "locked."
3. As soon as the game launches, the thing most likely to be unlocked first (probably the first thing on the list) begins to download in the background.
4. The thing will almost definitely download before it is unlocked. Set the status of the thing to "downloaded"
5. When the player actually does unlock the thing, set the status to "unlocked." Since it has a status of both "unlocked" and "downloaded," it is allowed to appear in the game menus. At this time, trigger the download of the thing most likely to be unlocked next, and repeat steps 4 and 5.

In the case that the player is really fast, or the download is really slow, you will, of course, need to block access to it from the menus until it is also downloaded. Depending on how you want the game to play out, you might only trigger the message that it is unlocked once it is both downloaded and unlocked. If this would not work well for the game, you may need to stall it with an error, but assuming that the player has an active Internet connection, this should be a rare case. If the player is not online, there's not really much you can do.