I have been having this idea of using encryption to prevent users from figuring out content in my program outside of the program itself. Like users may find textures never used in the game meant to be part of some kind of Easter egg while going though the games data. This may e.g. ruin it for everybody if posted online.

Imagine a secret room where the player have to press the correct numbers on a security door in the game, which if correct should generate the correct decryption key and then decrypting that part of the level and opening the door. Thus making the Easter egg otherwise inaccessible even when looking through the game-data since the key isn't actually stored, it's generated based on user-input.

Here is another example of what I was imagining. I have a puzzle game with let's say 20 levels, each one encrypted using a different key. Instead of storing the decryption key with the program directly allowing someone to decompile the program and find it, I instead generate the encryption/decryption key based on the solution of the previous puzzle. This way the player would have to actually figure out the puzzle before getting any information about the next level, even when looking through the game-data.

The player, if knowledgeable, could possible brute-force it "easily" given that the number of puzzle solutions is probably less that the number of decryption keys. It is really a matter complexity of the puzzle and is not very important here. Though I did post an answer regarding it over here

Is there programs/games today that has done something like this? Storing encrypted content in their games? And if not why? Is there a lot of rules and regulation about it, either at the store or country level? Does anyone see any obvious pitfalls that I'm missing? Ignoring things like user-experience, the idea seems sound to me and makes me curious why I haven't seen this before.

Edit: It may not be clear exactly what I'm saying, so here is a more concrete example.

Let's say I have a function that takes in a string of 20 characters and generates a symmetric key which I can use to encrypt/decrypt some content in the game. The only way the user could get to that content is to know those 20 characters and generate the same key. This key is never directly stored and is generated on the fly based on user input. These characters would be hidden in the game in what could be books, dialog with NPCs, maybe even outside of the game on the back of the box even.

So with 2*10^28 possible combinations to try it would probably be more likely people will find the content in the way intended rather that by looking through the game-data.

Edit 2: The content in question would be encrypted with an arbitrary and secret key before being shipped to the consumer. This key will obviously not be shipped with the game. He or she would have to somehow puzzle the key back together given a series of clues made based on the key, and that are hidden throughout the game or somewhere else. This system would however be transparent for the user as you wouldn't know the content was encrypted unless you actually looked through the game-data.

As a lot has mention this has one obvious downside in that its use case is limited. Once a single person has figured it out he/she may share it with everybody else, if not the key/solution then the content itself. However if your intention is to keep something so secret that a single person shouldn't be able to solve it and people have to work together to solve it, or you are afraid that your easter egg is so well hidden (by design) that it is more likely someone will find it in the code rather through game play. Then I think this could work great.

I would personally recommend to only use it maybe once per game and only for things that does not affect core game-play, e.g. easter eggs, a secret ending. Any puzzle would have to be so complicated or well hidden for it to slow people down enough to make encrypting the content worth it and if this puzzle stood in the way of people progressing then nobody is probably having any fun.

  • 57
    Answers focus on the technical details, but if your goal is to hide spoilers, consider that this information will become available by simply playing the game, at which point (if your game is popular) it will go straight onto a Wikia article for everyone to read, player or not. Commented Feb 6, 2016 at 15:22
  • 4
    Duplicate on game development stackexchange: "How can I protect my game data from casual hacking?"
    – Philipp
    Commented Feb 6, 2016 at 18:20
  • 5
    Isn't this a bit overkill for an entertainment product? I mean people could get the "key" by looking a walkthrough or lets play or just ask people who already played it. Also the game might become more error prone because of this "more or less obscure" way of dealing with things. Otherwise i like the idea and it will be a nice gimmick but it still wont stop people from hacking/cheating but rather make it more difficult
    – BlueWizard
    Commented Feb 6, 2016 at 20:16
  • 3
    I think this would be especially cool if your users are known for hacking your game and the puzzle is really really hard. You can imagine on the forums "what is this weird encrypted file". Commented Feb 7, 2016 at 0:08
  • 5
    @PyRulez Ah yes! That has been my main motivation behind this. I hate it when those pesky governments goes through the game files to find all the easter eggs. All just so they can post it on their enemies forums and ruin the country's moral.
    – Christer
    Commented Feb 7, 2016 at 0:33

13 Answers 13


This question is asking whether it is possible (not just commercially viable or some other interpretation) to force at least 1 user to solve a puzzle instead of hacking to unlock certain game content.

To my knowledge this is definitely possible. In fact, it is bizarre to me that other answers are saying it is outright not possible, even when it has been very explicitly stated that the key is neither generated nor stored, merely read in from the game state (which could have googleplexes of possible values). The argument that "the game knows how to decrypt it" so it won't work would then imply that any open source encryption/decryption software (for example, TrueCrypt) is inherently insecure because you know "how" to decrypt containers (just enter a string based on keyboard input, it's simple right?).

In the absolute simplest case, imagine that the game itself is a keyboard simulator and it asks the question "what is the password to my encrypted files?", clearly we all agree that having the source code to the game wouldn't help. Now imagine the game asks the questions "what is the name of the largest animal on Earth concatenated with the name of the smallest animal?". Is it not clear that even having the game's source code would not help, and you still have to solve the puzzle?

With respect to whether this is possible the answer is absolute YES, this is possible.

  • 9
    I feel your answer is the only one so far that seems to understand my question fully. Too many seem to automatically think my question is just like certain other game related encryption questions. I understand where they are comming from, though I wish they read my question a bit better.
    – Christer
    Commented Feb 6, 2016 at 23:21
  • 7
    What you are proposing is that the solution to the problems is only being stored in an encrypted way. It is definintly possible to confirm a valid solution but basically impossible to work back from that. (how-to-store-passwords-101). The second part of the question on how to hide content that doesn't require user-input to be displayed, is, however impossible to solve (note that when I say no user-input, I mean that in a very strict way) Commented Feb 7, 2016 at 2:06
  • 3
    I think, the main point is really that it's only possible to force a single user to solve the puzzle, because that first one can inform everybody else. Which makes the whole point of the encryption exercise mute. Commented Feb 7, 2016 at 6:21
  • 4
    With the source code (or a strings on the executable), a riddle such as "What is the name of the largest animal ...?" might still need to be solved by the player/hacker, but at least he can avoid the dangerous travel to the place in the game where the question occurs. Therefore, the riddles themselves should also be somewhat hidden (text as graphics may often suffice; more elaborately, I think I remember a game where normal 3d objects, when viewed from a specific point, perspectively combined to the solution of a riddle or other important information ...) Commented Feb 7, 2016 at 11:08
  • 4
    Given quotes like "This may e.g. ruin it for everybody if posted online." from the original question... sorry, but this answer is missing the point. It would be just as vulnerable to ruining it for everyone if the answer or decrypted files or whatever are posted, and is just as vulnerable to posting them. Commented Feb 7, 2016 at 16:51

It's been tried. Many, many times. There's an entire sub-industry dedicated to attempting to use encryption to keep users from accessing a program as they see fit. And it never works. The best protection schemes tend to last about a month before they're cracked, and the thing about the Internet is, once it's cracked once, it's cracked everywhere forever as soon as someone posts it. The obvious pitfall that you're missing is that in order for your program to use the data, it has to contain all of the information necessary to decrypt it, and if the computer can do that, a person with access to the computer can do that.

It's been called "the fundamental problem of cryptography": Alice wants to send a message to Bob, without Charlie being able to read it even if he gets ahold of it. The problem with the approach you're proposing is that Bob and Charlie are the same person in this case.

I can understand the desire not to spoil your users, but if people want spoilers they'll find them, and if they don't, they'll tend to actively avoid spoilers. But if you want to truly make a great game, go the opposite route: radical openness. Look at stuff like Neverwinter Nights, Starcraft, or the Elder Scrolls series, games that stay popular for years and years after release. They do so because they ship powerful design tools with the game that allow users to dig into everything, figure out how it works, and build and share their own content. A game is just a game, until it becomes a community, and communities endure.

  • 3
    In this case though cracking the encryption would be equivilant to writing a bot that solved the puzzles. Probably harder than simply completing the game and writing down the answers
    – Ewan
    Commented Feb 6, 2016 at 15:05
  • 15
    I just want to say that this answer doesn't really answer my question! I actually want people to "crack the code" or rather solve my puzzle. That is the entire point, and yes once someone figures it out I can't stop him from sharing the solution, I'm not trying to. However you are wrong saying saying "it has to contain all of the information necessary to decrypt it" as the entire point was the this information was given by the user. Read up updated question for details.
    – Christer
    Commented Feb 6, 2016 at 17:12
  • 6
    @Christer It does and here's why: Mason is saying who cares if they can get into the game files to find out the puzzle answer because only a minority will actually do it ..
    – Insane
    Commented Feb 6, 2016 at 18:57
  • 9
    @JonasDralle That's a disgustingly cynical viewpoint, and it's also not true. The strong, enduring community that got built up around Morrowind and Oblivion didn't prevent Skyrim from selling; if anything, it made it more successful! Commented Feb 6, 2016 at 22:18
  • 3
    @Cronax If you use "one time pad" style encryption, with- in this case- the key being the puzzle solution your attacker doesn't have a better option than brute-foricng over the size of the key space. With the right kind of puzzle, that could be impracitcally large to solve within the lifespan of the universe. Also if the easter egg is, say, a message from the developer, an attacker would have no way of distinguishing the real message from a random correct-Egnlish one. Commented Feb 8, 2016 at 17:47

The main reason why this ought to be on gamedev.SE is that doing this encryption has gameplay consequences.

You want the solution to one puzzle to be the encryption key for the next. That is, the actual data of that solution must decrypt the next puzzle. This means that the decryption key is not part of your game's data anywhere; it is generated by the player.

And here's the consequence. Decryption is usually binary. Either you have the exact decryption key needed to un-encrypt the data, or you do not.

The consequence here is that whatever game you design must be so narrowly focused that there is only one possible solution to every level. So your puzzle mechanics must be very carefully designed such that the player cannot solve the puzzle in a different way from your intent.

Take Portal, Test Chamber 10 for example. You're supposed to go left, do some stuff, then go right and do some stuff, all to lower a platform.

Or you can just give yourself some velocity and fling yourself up to the platform when you walk right in.

GLaDOS: So you made a puzzle game. A puzzle game that punishes the people who most enjoy puzzle games. Good job. But at least those hackers won't get at your precious data. Because people who enjoy solving puzzle games are the exact kinds of people who look up solutions to puzzle games online.

So that's totally worth it.

So, puzzle games like Adventures of Lolo, SpaceCHEM, and Portal (among millions of others) are right out. Instead, you have to design your game such that it is impossible to create a puzzle that has more than one solution. That requires a very great deal of care, and usually requires substantially restricting gameplay.

GLaDOS: So you made a puzzle game. A game that's meant to be played by people who like finding creative solutions to puzzles. And you made a game that has no creative solutions to puzzles. *slow-clap*

I'm not saying that you can't create such a game. Or that such a game can't be good. Only that such a game would have to be designed in a certain way.

Oh, and you have to design this gameplay such that it is impossible (or highly difficult) to mechanically find a solution.

GLaDOS: So you made a puzzle game. A puzzle game that's more interesting to hack than to play. Good job.

Of course, there is one caveat to this: the meaning of "solution". Or more to the point, what elements of a solution do you take into account?

For any game that involves a moving character, you're probably not going to use the character's exact movements to construct the decryption key. For example, if you have a puzzle game where the player needs to pick up certain items to "solve" the puzzle, you could make the key depend on the order in which those items are touched.

Of course, this runs into that problem above, where a player finds a way to do things out-of-order. Which again means you have to design the puzzle such that there is only one order you could possibly pick things up in.

Furthermore, whatever elements you use to construct the decryption key need to provide sufficient entropy to make brute-force decryption hard. Using the order-of-collection mechanic above, each new item is effectively one extra bit. If a level only has 8 items, you're doing 8-bit encryption. Which is crap; most smartphones can handle that in seconds.

Nowadays, you need at least 128 to make it even slightly challenging. Which now means that each level needs to have lots of stuff in it, yet again impacting your game design.

  • 2
    @Christer: Your example only betrays the irrelevance of your overall question. The contents of "a secret altar outside of any quest" is, by definition, irrelevant for any game that is fundamentally about completing quests. And if your game isn't about completing quests, why do you have quests in it? Either way, the overall fact remains: you are spending a very great deal of time on something of no actual relevance to your game or your players. You should focus your very limited time and energy on things that matter. Commented Feb 8, 2016 at 0:47
  • 2
    @Christer: "Also since that fact that encryption is used is transparent to 99.9% of the users, that isn't a valid argument for it being a horrible idea." If it makes an easter egg take up more time in development that could go to genuinely useful features, then yes, it's a horrible idea. You have spent more time on formulating your question and responses to answers than this feature deserves. In that time, you could have been writing your actual game. If it's transparent to 99.9% of users... then why should it matter to them if it's encrypted? Why spend time for 0.1% of people? Commented Feb 8, 2016 at 3:23
  • 2
    I'm sorry, but I like having some fun making my games! Not everyone can be a game producing robot. Also let me be the judge of how long time this takes and how much I'd be willing to spend. The ecryption part itself at least would be straight forward to implement.
    – Christer
    Commented Feb 8, 2016 at 3:32
  • 1
    The consequence here is that whatever game you design must be so narrowly focused that there is only one possible solution to every level. Not necessarily: he could encrypt the content for each possible solution and ship duplicate encrypted content for all possible solutions. Space can be saved using a two-tier encryption - the user key in the linked answer corresponds to a specific solution, the document corresponds to the content.
    – mucaho
    Commented Feb 8, 2016 at 5:41
  • 4
    @mucaho: That requires knowing "each possible solution" beforehand. Commented Feb 8, 2016 at 5:51

I've been around long enough to know that if the content is there, someone will find it. Making it harder will just attract more determined people. The more popular your product, the more interesting it becomes. Partially because it's a challenge, partially because there are so many places you can gain "cred" by posting this kind of information.

If the key is generated locally by the game, you can find a way to cheat through the game until the point where the key is generated, or simply dig out the right piece of code. If the key is sent to you from a server on completing certain steps in the game, someone will trick your server into believing they have gotten far enough.

In the end, your game will benefit a lot more from the time you spend making it fun and engaging, over making it hard to find out what the next level color is.

  • Although encrypted data with a locally stored key can always be hacked. In practice all modern apps and games use this to an extent.
    – Ewan
    Commented Feb 6, 2016 at 14:31
  • Check out soomla and how it does coins
    – Ewan
    Commented Feb 6, 2016 at 14:31
  • I believe the question was about hiding future content from curious players, not about how to protect currencies and player stats from tampering
    – axl
    Commented Feb 6, 2016 at 14:39
  • 1
    Since this is about an easter egg, attracting attention is exactly what you want. Commented Feb 7, 2016 at 0:08
  • 6
    Making it harder will just attract more determined people I think this is a great marketing strategy for a game :) Commented Feb 8, 2016 at 8:18

The answers here are good; I would look at it from another perspective though. What you are describing is a feature. Features have costs and benefits. The costs include both the dollar costs of creating the feature, and the "opportunity costs". Those are: in a world where you have finite dollars and finite hours and finite programmers, every feature you do means an infinite number of possible features that were not done in its place.

So the question is: can you state the costs of this feature in real terms? There are no free features, so be realistic about the costs. Are you willing to pay a thousand dollars for this feature? A hundred thousand? A million? What features are you willing to cut in order to have this feature?

I think once you start to prioritize things in terms of costs, benefits, and opportunities missed, you will realize that you have already spent too much time thinking about this feature when you could have been thinking about ways to make the game more fun.


The Alice Bob and Eve problem illustrates this well. As Mason pointed out in his answer, you can't keep a secret from Eve if Eve is also Bob.

Thus, any solution would consist of Bob not having all the necessary information. You would have to treat each level as an individual message, encrypted separately from each other, and have an external source of the messages for the next level that was able to gate-keep the messages properly.

But eventually, that becomes moot. If someone can play the game themselves, then can also write a program to ingest the game too. So all you're doing is forcing them to go back and forth from your external source (probably a server of some kind). Once they crack how to craft the messages to your server, it's the same old story.

But you're forgetting a key element here. It's a game. If someone cheats in a game, big whoop. You didn't write the game for cheaters. It's the same thing with quest walkthroughs or leveling guides: the people who want the challenge of figuring it out on their own will ignore the posted solutions. Even if you were able to make cracking the game impossible without playing it (we know it's logically impossible, but EVEN IF you could) it would only take one guy walking through before he posted everything necessary to beat it. So you're only delaying the inevitable.

Spend your time making an awesome game. There are Ten Things Every Game Needs and last I looked, encryption wasn't one of them.


I believe your idea is pointless.

When someone plays your game, they choose to play it, they are not doing it to win an award, they are doing it for fun.

Users know that the most fun comes from playing the way you meant and won't cheat, as your customers they already trust you as a storyteller.

Also as soon as someone has found the solution to a puzzle, i.e. your key, they can simply post it somewhere on the internet.
Players who want to cheat would still be able to do it.

However if your game present multiple solutions, like Super Mario Land secret levels, encrypting your assets will prevent an easy access those solutions.

While this seems a point in favor of your idea, in the end it is not.

Even with encryption it would still be possible to know that such secret solutions exist.
Once it is known that a secret solution exists, preventing the players from looking at the secret assets would be irrelevant as they would still want to access the hidden parts of the game through the game itself (yes, even if they have already seen every hidden texture/clip/audio/text).

You may prevent the leaking of the secret solutions existence by using some oblivious technique1, but it would still be suspicious (why doing that if there are no secret solutions?), the players would lose interest in finding them and you would have less players, not more.
After all we can play a couple of hours more after having completed a game to trigger some Easter-eggs but we won't play a minute more if triggering them would require a titanic effort!

What you want to do is like a writing book where the next chapter is encrypted with a word of the current chapter, to prevent readers from spoiling themselves the ending.
Think about it, isn't it pointless?

1Pretty much like VeraCrypt do it with Hidden volumes.

  • 1
    I actually kind like that book idea. I understand it could frustrate a lot of people, but I could also imagine people actually wanting such a book. I know people who can't help spoiling the ending for themselves by skipping ahead, even when trying not to. So I guess such a book could help. Though they could still look up the keys online unless the keys were personlized. Even then they could just look up the ending directly. Still if they were that desperate it would be no point trying to stop them further like you said.
    – Christer
    Commented Feb 7, 2016 at 0:19

I will not comment on commercial viability, however from a pure technical perspective it's an amusing challenge.

I would first note that anything that is not encrypted cannot be protected. You cannot gate the entry into a secret, crackers will find a way around the gate, instead you have to make the entire secret the gate itself. In terms of assets, this need not mean the entire textures, etc... just encrypting the plan and which are used and how is sufficient, and for performance reasons you will wish to encrypt as few data as possible.

Secondly, you are right that if the key is contained in the software then it will be teased from the software. Many games, when protecting content, try to use either security by obscurity or mechanisms that ensure that the game software has not been altered. Those are only delaying tactics.

Your idea of using the solution of an enigma as the key is rather interesting, however, using the key provided directly is likely to be easily brute-forced. Instead, treat the user input as a password and use a state-of-the-art password hashing scheme: the hash produced is the key.

However, even then, there is a mistake in your assumption that the key is not present in the game. If it was not, you could not steer your players toward it; therefore, rather than trying to brute-forced the safe, one could instead reverse engineer the game assets looking for clues. One potential puzzle I can think of is using textures to encode glyphs, and then the password would consist of a few of the available on the keyboard, as revealed by the locations the player should have visited (in order):

  • the crux of the problem is that image recognition is still somewhat difficult for computers
  • on top of which we layer the fact that CAPTCHA crackers are tuned for letters and digits, not custom glyphs
  • on top of which we layer the fact that by combining multiple textures (with transparency) to reveal the glyph to the player no single asset in the game contains what the glyph should look like
  • use other texture (with fragments) all over the place, but never in a way that generates a full glyph except in hidden places the player should never be able to reach

and any program to automatically extract the winning glyph combination will have a hell of a day.

Thirdly, the next difficulty is sharing. Once the solution to a secret is found, it will be revealed. Ideally, each individual should be handed a slightly different version of the software: one where the key is unique to their version of the game. To make it practical, I surmise it would be easier to separate the game (with its assets) from the "secrets" (encrypted) and "secret driver" (the key generator, which places lots of fragments of texture in many many different places, some of which form the passwords).

The obvious attack vector is tricking either the generator in always picking the same password or tricking the verifier in always accepting the same password (by downloading someone else's secrets file, for example).

Here, a potential solution would be to link the files to the user's account, and to salt the password as is usually recommended:

  • when the user requests a set of files, randomly generate a salt and as many passwords as you have secrets then create the secret assets (you may want to limit this process to once/day/user for example, to avoid overloading your server)
  • store the timestamp of the generation and the salt into the user's account information
  • send back the timestamp and the personalized secret files to the user

Then, when the user is ready to submit a password:

  • have the user log in (if she was not already)
  • have the software send both the timestamp and glyph password
  • if the timestamp is different from the one stored, advise the user she is using an obsolete set of secret files
  • if the password has already been attempted too many times, advise the user she is using an obsolete set of secret files
  • otherwise, hash the salt+password to produce the key
  • otherwise, send the key back to the user so she can see her personalized files
  • increase the number of times this password was attempted by this account

The goal here is to impede account sharing as much as possible:

  • sharing an account to generate secret files is (a) limited, because only one can be generated per day and (b) useless, because the latest generated makes the other obsolete
  • sharing an account and distributing the associated secret files is useless, because a given password can only be used N times before it doesn't yield the key any longer

And we are nearly there.

Finally, even there, a cracker could release a modified version of the game in which the secret assets are decrypted and directly integrated (bypassing your careful verification scheme).

The solution is simple (and makes nearly everything above obsolete1): do not trust the client.

Create a leaderboard on your website, and keep track of the progress of players in their account. Players can claim they have finished the game all they want, but unless their account reflects this, everybody knows they've been cheating...

... this is called social pressure ;)

1 Except the texture positioning file, which we used to prevent a program from guessing the key and yet make it possible for a user to obtain it.

  • Thanks for you thoughtful answer. You make good points. Though I would like to add that the key/solution doesn't need to be stored in the game like you said. It could be hidden in the html of game webpage for example, maybe you want to reward people looking through stuff like that. But even in the game you could be more creative like using riddles as a solution, geometry that reveals information when viewed from an angle, use context related things that you probably wouldn't get unless you have read through a lot of the lore of the game. Like how Skyrim has books or logs in computer terminals.
    – Christer
    Commented Feb 7, 2016 at 17:19
  • I didn't mention this in my question so don't worry. How I was imagining this was that you would play through an entire game and it felt like a complete game. However there were this hidden door which had a strange lock on it that you never got past. It would hopefully get people curious and talking, maybe even get people working together to figure it out. Since no one has figured it out, it is also be a kind of glory to be had for figuring out too. Maybe if enough time pass the door's elusive secrets will spawn legends! Sucks having that ruined by someone just looking through the game assets.
    – Christer
    Commented Feb 7, 2016 at 17:32
  • @Christer: Sucks having that ruined by someone just looking through the game assets. => this is solvable by using secret files to describe the place indeed (reusing existing textures mostly), once the secret is out once though, it's out... Commented Feb 7, 2016 at 17:59

It's an interesting idea; a variant on the puzzle discs and enter-the-word-from-the-manual copy protection systems. I think some of the "ARG" games work like this, where it's sort of understood that the players are acting collectively against the game designer.

Obviously once the first person decrypts it they'll publish it on the internet.

Generative or procedural content can work the same way: you don't see the same world as another player unless you share a "seed".

I can't see any legal problems with it, although Apple may reject it from their App store and you may have to provide the solution to get it approved on games consoles.


Contemplating extra security measures is entertaining, but it doesn't add concrete value to your product – it demonstrates your niftiness to the crackers that encounter your product. By principle, your antagonist will catch up with you.

Contrary to developers who thrive in creativity, crackers are analytic people – they can intuitively exploit your program. When developers tend to excessive security measures, they are in denial – that the cracker could reverse their protection scheme, again.

Whether you want to participate in this background-competition, that is your call – but don't let it distract from your end-product, which must please the customer. A quirky encryption scheme which turns the game into a slug doesn't help.


Mason Wheeler has it right: you can't do it. Someone can always reverse engineer your game if they want to.

You do not need to "protect" your game anyway in the way you describe. As soon as one person finds the Easter egg the secret is out of the bag. If each copy of the game has a different Easter egg, then only the hacker copy will be known. Do you really care that one hacker out of 1000 people found the Easter egg without going through gameplay?

Copyright law is such that noone can make money off your game without risking a serious lawsuit, so copyright protects you.

As far as random users putting your textures on their forum avatar, so what? Consider it grass roots advertising.

Getting obsessive about "protecting" stuff will just distract you from difficult realities like: making the game.

When I see people with no product talking about their IP protection schemes for things that don't even exist, its kind of a walkaway moment for me because it raises a huge bullshit red flag over the whole project.


Some possibilities:

  • Plain old code obfuscation. It won't make the code impossible to decode but at least it will be hard.

  • Server-side solution. You send some special commands to the server and the server can send you the code... or even download a DLC.

  • You can use Steganography to hide executable code in other content.

This won't make your secret 100% secure but it seems that nobody will even loose money if the secret is revealed.


It is useless just as any other schema where you store both key and algorithm on client. If you ask "where's the key, I rely on users's input and don't store it myself?", remember that your puzzle have rules and resources by its definitions - it is solved by some algorithm, not by bruteforcing. This exact algorithm and its resources IS the key generation algorithm that you've just hardcoded into the game in obfuscated state. Anybody can retrieve your "non-existent" key by just writing a small program that solves your puzzle according to your rules.

  • 1
    But not every puzzle is easily solvable by a computer, like a riddle that hasn't been made before. It's also hard for a computer to read through all the dialog in the game and process all of the textures. Even if it did, how would it know when something related to this puzzle popped up? The full key doesn't even need to be stored in the game, maybe there's a clue to read the backside of the box where the key is, the computer can't do that. Even if the puzzle was something the computer could solve, like Sudoku, at least it would be solving the puzzle not circumventing it.
    – Christer
    Commented Feb 9, 2016 at 16:03
  • @Christer, it is no different that figuring out any other "security by obscurity" homemade encryption. "On the box" - you just wrote key to the "paper cover" resource that you give to user instead of "file" resource that you give to user. Big deal. Commented Feb 9, 2016 at 16:05
  • @Chriser, i.e. solving "a riddle that hasn't been made before" is exactly equal to "solving a homemade encryption algorithm that hasn't been made before". Commented Feb 9, 2016 at 16:16
  • Don't you see how you could generate a decryption key based on user-input? Don't you see that this user-input could be anything? What's the correct user-input that generates a good decryption key you ask? Who knows, it's hidden throughout the game in all kinds of interesting ways. Hope you find it as that is the entire point of it! Good luck getting to that content otherwise though.
    – Christer
    Commented Feb 9, 2016 at 16:26
  • How exactly the hell it is different from reading source? You perform task according by set rules -> you get key. That's all. Except you can take shortcuts by just reading your "clues" from other game resources instead of actually playing the game. Commented Feb 9, 2016 at 16:29

Not the answer you're looking for? Browse other questions tagged or ask your own question.