21
\$\begingroup\$

How would I make a password system for a single-player game like the ones used in older console games?

For example, Mega Man X saves work by giving you a series of numbers that you can enter later to load your save.

\$\endgroup\$
10
  • 3
    \$\begingroup\$ Don't do what Donkey Kong (NES) did - which is let you save to the cartridge but NOT PRESERVE THE LIVES COUNT - so you'd have loads of lives from the first level (like 24) save, go to bed, WAKE UP WITH 3 - I hated that \$\endgroup\$
    – Alec Teal
    Jul 26, 2015 at 2:08
  • 11
    \$\begingroup\$ Pedantic note: a password system does not save a game state, it loads a predefined one. \$\endgroup\$
    – Lilienthal
    Jul 26, 2015 at 10:08
  • 5
    \$\begingroup\$ @Lilienthal not necessarily. Maybe it is just some sort of "dump" of some variables state, shuffled with a deterministic two-way algorythm. \$\endgroup\$
    – o0'.
    Jul 26, 2015 at 12:10
  • 2
    \$\begingroup\$ @Lohoris Yes, if you have sufficient entropy in your password you can consider it a sort of saved state that's close enough to resemble current savegames. After all, both require a way to export and import the game's state. However, the entropy required for anything resembling a true save (exact location/checkpoint, lives, enemies slain, ammo counts, ....) would require both a very long password and a very complex algorithm. For cases where the decision to use passwords over savegames makes sense (if there even are any), the maxim should hold true. \$\endgroup\$
    – Lilienthal
    Jul 26, 2015 at 15:06
  • 3
    \$\begingroup\$ @AlecTeal What exactly whould be "stupid"? I'm evaluating a password against the amount of data stored in contemporary games, where they are clearly unsuitable for the vast majority. \$\endgroup\$
    – Lilienthal
    Jul 26, 2015 at 20:56

4 Answers 4

33
\$\begingroup\$

First, break down your game state (or rather, the aspects of the state you want to save). In the case of a Mega Man style game, you might track which of the end-level bosses you've killed, the number of energy-tank-like powerups you have, and so on.

Pack all of that data into a bit field, that is, assign an appropriate number of bits to each value:

  • Killed boss 1 (one bit)
  • Killed boss 2 (one bit)
  • Killed boss 3 (one bit)
  • Killed boss 4 (one bit)
  • Energy tanks (x of 5 total) (3 bits)
  • Unlocked some achievement (one bit)

Our example has 8 bits total, which means a single character can represent a password. In practice, your game is likely to have more state and thus require more total bits and thus more characters. As noted in the comments here and elsewhere in this question, this approach works for "retro" games or other games where the size of the captured game state is reasonable. Beyond a certain point, you may discover that the complexity of the passwords necessary to encode your state is too large.

To decrease the likelyhood of casual observation cracking the password, you can transform the bit layout so that you introduce dummy bits (which have no effect on the game state but which make the password look different when you interpret all the bits as characters) or run it through some reversible hash-like operation to scramble the bits around so that all the "killed box X" bits are not right next to eachother, making corresponding sequential-state passwords look very different, or introduce checksum values.

If you dig around, there's a fair bit of information on the systems employed for some of the more-popular passworded games out there:

You could read up on those for additional inspiration.

\$\endgroup\$
12
  • 4
    \$\begingroup\$ Remember to make sure that the "save state" password is all easily type-able and, preferably, unambiguous (eg., use '0' or 'O' but not both). \$\endgroup\$
    – minnmass
    Jul 25, 2015 at 21:16
  • 4
    \$\begingroup\$ @minnmass bonus points if you implicitly convert similar characters to your standard, so that typing 'O' instead of '0' still translates to '0'. \$\endgroup\$
    – user39686
    Jul 26, 2015 at 1:37
  • 8
    \$\begingroup\$ @NPSF3000 Because in this case the "password" isn't an authentication measure; the "password" is the storage medium itself. \$\endgroup\$
    – Schilcote
    Jul 26, 2015 at 16:41
  • 6
    \$\begingroup\$ @NPSF3000 if it's not clear to you from the question then you need to reread the question or learn the background material. \$\endgroup\$
    – hobbs
    Jul 27, 2015 at 0:32
  • 2
    \$\begingroup\$ @NPSF3000 OP clearly says "Retro Style" and references Megaman to confirm, which is not ambiguous. Learn about the subject matter, understand that this is not related to security, and please stop trying to defend what started as an honest and forgivable ignorance. \$\endgroup\$
    – MickLH
    Jul 27, 2015 at 15:58
3
\$\begingroup\$

Those games did only save a state I believe. The password just references a level to load. Just use a dictionary for something like this.

If it is a little bit more complex like having a certain weapon or booster you can encrypt the state to a short (but long enough) hash code.

But I strongly advice you to not use this. Password will spread fast on the Internet and soon everyone had won your game.

\$\endgroup\$
6
  • 10
    \$\begingroup\$ Passwords spreading on the internet can be good. Cheating can be fun, and in a single-player game, players only cheat themselves. \$\endgroup\$
    – Anko
    Jul 25, 2015 at 19:14
  • \$\begingroup\$ @Anko Yeah, I dislike cheating and barely did it so I am biased. But from my own experience my games would gather dust a lot quicker and sooner when I cheated my way trough. \$\endgroup\$
    – Madmenyo
    Jul 25, 2015 at 19:17
  • \$\begingroup\$ "... just references a level to load." Not true in all cases by far. Some passwords also reference bosses, killed, powerups gained, etc. Secondly, advising that the password can be spread is one thing - an issue in our hyper-connected world. Saying that cheating options should be removed because YOU don't like cheating is another. What you like isn't exactly what others like. Its not about what you like, it's the consumer. Cheating/shortcuts are an important option - especially for single player games. \$\endgroup\$
    – WernerCD
    Jul 26, 2015 at 3:00
  • \$\begingroup\$ @WernerCD firstly I talk about more complex systems I just start with a simple password system. I am NOT claiming anything. Secondly, I am not saying anything about cheating in the answer. I am just giving my BIASED reply on a comment and even saying that I am biased and aware of your point that it is not what I like. But if nobody says what he likes or dislikes how would you know what others like? I still think a system like that is due time and 21 century cheating is achieved differently. Next time you should read more carefully before you write a comment like that IMHO. \$\endgroup\$
    – Madmenyo
    Jul 26, 2015 at 8:59
  • \$\begingroup\$ If you have savegames, people will share savegames, too. \$\endgroup\$ Jul 27, 2015 at 1:47
2
\$\begingroup\$

Well you could basically do it this way:

Bosses killed = 7

Amount of coins = 36

Owns Sword = 0(No)

Owns Heart = 1(Yes)

Current Level = 6

Current World = 9

Health = 100

Code = 7V36R0A1T6O9A100

Basically every letter separate The Types

\$\endgroup\$
-3
\$\begingroup\$

While solutions like Josh Petrie's character-to-state system have benefits (small save size, works on all copies of the game), they couple the games design and state system to be intrinsically to the password system. Any change to the password or state or design and the entire system falls apart.

A far simpler solution would be to build your save system as per normal, and simply add a password system over the top. This can be as simple as saving the password in the save (possibly doubling as file name) and validating it on load, or as complex as using one of the many encryption libraries around (which is pretty trivial).


There seems to be some confusion around this answer.

1) The op has simply asked for a password that let's them load a save... there is no requirement that the password be the save.

2) Many games today have significant save storage requirement, we just built a quick save/load system internally that was producing 10MB files... for a quiz game! Josh Petrie's save system, while valid is very limited - as soon as the store system becomes non-trivial the passwords would have to be of enormous length to persist all pertinent data.

For example, what happens if there are 30 bosses? 20 achievements? Are we halfway through an achievement? What level is he at? How many bits are we putting aside for health, lives, coins, xp? What if the snapshot is not of state between levels... but half-way through a level - the positions of the player, enemies, projectiles, destructed/altered terrain suddenly add up to a lot of state that needs to be stored.

For perspective, assuming a 30 character alphabet and a ten letter password we have roughly 50 bits worth of information to store. It's not uncommon to see a game/engine use up to 320 bits just to store a single object's position, rotation and scaling. Sure, you can do all kinds of optimisation tricks to do more with less... but ultimately you're using up the time dedicated to making the game fun - one of the worst optimisations you can make.

\$\endgroup\$
10
  • 4
    \$\begingroup\$ I think the problem here, and with your comment above, is that cryptographic security is not the goal of saving the game's state as bits within a password. Passwords composed in a such a way are easily reversible but difficult to guess hashes, and nothing more. And for that same reason, it doesn't cause undue coupling in the way you are imagining; if the game state becomes more or less complicated, so does the hash (which does invalidate previous hashes), but the system works equally well before and after. \$\endgroup\$ Jul 26, 2015 at 12:54
  • \$\begingroup\$ @Seth Battin "it doesn't cause undue coupling in the way you are imagining" Oh cool! So a game I am working on right now had a save file measured in the megabytes... all I need to do is do some basic obfuscation and display it on a screen and voila! We now have a perfectly good password system? \$\endgroup\$
    – NPSF3000
    Jul 26, 2015 at 22:18
  • 4
    \$\begingroup\$ It sounds like your game is not appropriate for this method. \$\endgroup\$ Jul 26, 2015 at 23:59
  • \$\begingroup\$ @NPSF3000 What's the point of passwords in this case? If it's to prevent others using the same machine from using their savegames without permission, why not just have a once-per-game login with username/pass? If it's to specify which save they want, that's a "savegame id", not a password, and should likely be made friendlier. As it is, if I read you right, you're requiring a different, non-user-specified password every time they load a new save? WHY? What useful advantage does that give to anybody? \$\endgroup\$ Jul 27, 2015 at 1:55
  • 1
    \$\begingroup\$ @DewiMorgan I'm not requiring anything, I'm purely giving an answer to op's question: "How would I make a password system for a single-player game? For example, Mega Man X saves work by giving you a series of numbers that you can enter later to load your save." My solution does that, without coupling the save system and the password system together. The top voted answer has the same downsides as mine, with the addition that it requires the entire game to be designed to suit the method. \$\endgroup\$
    – NPSF3000
    Jul 27, 2015 at 2:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .