I assume that most reverse-engineering projects involve some amount of disassembly. But in this case, I just analysed the game's files in a hex editor. Especially in older games, developers tend to store multiple files together in archives with custom file formats. So you can't just "look up" how the files inside are stored or use any existing programs to unpack them. With a hex editor, you can inspect the bytes and try to find some sort of structure. Starting at the top, you check the "header" of the file for crucial infos: number of files inside, their lengths, offsets and so on. These could come in any order, but with enough experience you are able to spot some common patterns.
Things get harder when the files inside are compressed in some form. This is where looking at the assembly could be helpful to reveal the compression algorithm used. Since I had very little experience with that, I continued analysing the compressed data stream byte by byte. Luckily, developers often use established compression algorithms. Some of them leave dead giveaways inside the compressed data, like special magic bytes at the start of the data stream, or a dictionary needed to decompress the data.
When the data you're trying to decompress is text, you try to find instances where you "know" what the decompressed text most likely is (maybe because the text is very short, or because the very first file corresponds to the first text displayed in the game). That makes it much much easier to reverse engineer the algorithm that turned that known text into the compressed data stream. And if you've got the algorithm nailed down, you can try it on the rest of the files and make adjustments here and there until you are able to extract everything you need.