The R-PI uses a different processor than the systems these old games ran on.
That means that in order to make them run, we can do either two things:
1) Translate the game code for another CPU, that means we need the games code (blueprints) to be able to translate (compile) the code for a new CPU. Obviously we also need (equivalent) hardware services that the game depends on, such as a 3D video card if the game code demands one.
2) If we do not have the blueprints, there is only one other alternative, and that is to "fake" the old system, including its CPU by using specially written software, (emulation) but that is a very slow process, as every instruction that the old CPU executed must be mimicked with software by the new CPU, and the new CPU probably needs to execute dozens of instructions for each instruction of the old CPU. Additionally we need to mimic the hardware of the old computer too, in software.
If the older computer was -much- slower than the new one it might be possible to end up with a workable solution, but the new CPU has to be at least dozens of times faster than the old one, and the old computer should not have had too complex hardware.
In practice this means that the R-PI can run games such as quake 3 for which the source code was released at more than full speed, but for old games for which no source code is available we can only run things like old DOS games that used to run on (say) a PC equipped with a 33 MHz i386 CPU and a VGA display.
The nice thing about this "emulation" trick is that just as we could emulate one system, we can also emulate another, so it is (for example) also possible to (try to) emulate a Nintendo 64 game console, or a cray-1 supercomputer, that is as long as we have enough time (to wait for the result) and memory (to store the emulator code AND the software of the emulated system).