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.
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:
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.
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.
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.