Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I'm working on a rather simple 2D game, with a pretty small set of values that will need to be preserved for a user to pick up where they left off last time they played.

Rather than saving/loading the state of the game for users to leave/return, I'm considering something akin to what MegaMan did, where a user enters a "password" to resume from their previous state, like so:

megaman image

How is something like this generally implemented? My two thoughts were

  • Build list of all valid passwords and their corresponding states. Reject anything not on the list, and load the corresponding state when correct input is received.
  • Represent the state as a binary string, and make that the password. If the user's input parses validly, assume it to be valid and set it to the state.

What are the concerns with each of these approaches, and is there another way to go about this that I've overlooked?

Note: If this question is tagged poorly, it's because this is my first question on gamedev.stackexchange, and I'm not yet familiar with the ta

share|improve this question
6  
It's a pain from ages ago: please don't do it, unless it's really the only choice. If you think it's the only choice, please think again, very carefully, to be sure. –  Lohoris Feb 3 '12 at 10:01

2 Answers 2

up vote 3 down vote accepted

Here are some Pros and Cons for each approach:


List

Pros

  • No predictable pattern for users to exploit
  • You don't need to generate an encoding/decoding

Cons

  • Only represents pre-defined states
  • Gets messy/large when storing many states

Binary representation

Pros

  • Represent a wider variety of data/states (create a password for any given state of the game)

Cons

  • Difficulty of implementation

If you are going to use binary representation, I suggest you use something like base16/base32/base64 values depending on your data size.

share|improve this answer
    
Thanks. Your analysis makes the first one seem a lot more promising, since the game is simple enough that the cons you've listed won't be a huge issue. –  Jim Feb 3 '12 at 0:30
    
@jim remember to hard-code the list if you are using that method, it's easy to unlock data files. –  Ali.S Feb 3 '12 at 0:51
3  
Note that in that 5x5 matrix with only one way of marking each space, you only have 25 bits of data. That is, there are 33,554,432 possible game states that can be represented. That sounds like a big number, but it's actually not. That's only enough to encode three bytes of data, plus one extra bit. –  Trevor Powell Feb 3 '12 at 2:51
    
or you can put it into a 5 base_32 characters. –  Ali.S Feb 3 '12 at 11:33

In my experience the games that use passwords only have one password per level, so you end up with a couple dozen passwords which can be random, or, in some cases, recognizable words.

There are some exceptions though; populous, lotus and sentinel come to mind. All of those use procedurally generated levels, and the "password" basically just encodes the seed for the generation.

From usability point of view, the passwords are a horrible solution. Automatically saved state on exit and "do you want to continue" when re-starting the game is probably the best choice for a simple 2d game. The only positive side that I can think of is being able to take your game state with you and continue playing on some other computer..

But let's say you ignore all of the above and want to store your game state in a password. Let's say you end up having, say, 40 bits of state (or 5 bytes worth). This is short enough so you could just give it as five numbers the user has to input - IP addresses are 4 numbers, and people seem to be able to do that just fine. But let's do some encoding.

Let's say we have an alphanumeric space - 0 to 9, A to Z. That's 36 possibilities. Let's simplify that down to 32 by removing four possibilities that are the most probably confused with other letters - o, i, l and 1. The remaining 32 is 5 bits, so you can encode your 40 bits in 8 characters. Whether this is easier for the user than 5 byte-range numbers, that's up to you. =)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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