I hear often that games can’t be remade because the source code is lost. Silent Hill 2 remake had only partial source code. Wouldn’t any old physical CD have the entire code on it?
In: Technology
No, once a game or any other computer program is compiled it is not easily reversible back into its source code.
There’s tools that can do this, but reverse engineering a game code from a compiled game is very difficult.
Game companies meanwhile don’t want the raw code to be on the disk because hackers could use that to break the game and cheat, or could just steal the code outright to make their own games.
No, because code is compiled into executable files and it is usually not easy to convert these back into code.
Imagine the code like the recipe how the game is assembled and built together just like the recipe for a fancy, complicated cake.
What you get as a copy of the game is the cake. You can taste it, look at it, and make guesses what the recipe was. But it is quite hard to really replicate the recipe just from having the cake alone.
Nope.
Shipped software products usually contain only the production variant of the machine readable compiled program code. This program code will be optimized and possibly even obfuscated.
Debug and testing versions of the machine readable program code will still contain some human-readable information such as the names of particular locations in memory, the names of functions, etc… this is generally stripped out of what’s released to the market because computers usually don’t need to the names of symbols.
The human readable source code is usually stored on workstations and servers belonging to software companies. If a company closes shop or clears out old equipment then the proprietary contents will generally (but not alway) be erased.
There are software products that can convert compiled machine code back into human readable source code. These are aptly called decompilers.
Decompiled source code will not be the same as the original source code. There won’t be any comments, function names, parameter names, or variable names. Data types may be incorrect, inlined functions will be copied all over the place, etc… this is because decompilers work backward rather than forward and they can’t accurately restore information that was stripped out by the compiler.
However, decompiling is a start and given enough time it can be useful in reconstructing something similar to the original source code.
A good example of this is Super Mario 64 for the N64. The original ROM was decompiled, reverse engineered, and extensively patched to improve performance over the original release from 1996.
This involves a lot of time and effort because software tools will only do so much. Remasters of old games often use the original source code as a launching point and don’t dedicate a ton of manpower to the project.
Imagine source code to be the blueprint. What you have on the CD is the thing that’s built according to the blueprint.
You really want the blueprint and you don’t really care about what’s already built. Yes, you can reverse engineer what’s built to what should be the blueprint, but that takes a long time so it’s not worth it.
Imagine a muffin. If I create a recipe for my own special chocolate chip muffin, and then I give you the muffin, can you make the muffin? Do you have the recipe, because I gave you a finished muffin? No. And that’s how video games, and basically all software works.
The code game devs write, is compiled, or changed from human readable code in a language like C++, into a machine readable code, that reads like nonsense to humans, but runs on computers/consoles.
Source code from a lot of older games is missing, because in the 90’s studios were pumping out games, and didn’t have the foresight to believe they’d ever need the source code to release remasters/ports years/decades later. The mindset was different.
The whole reason it’s called “source” code is that it’s what you start with. The finished game on the CD is what you end up with. A few games have shipped with source code by accident because somebody screwed up and accidentally copied the folder to the wrong place. But in-general there’s no reason to include the source code because that’s not what the CPU is running. The CPU only runs the finished game which is made by compiling the source code and other assets through a build process.
Imagine a cook who bakes cookies. They keep their special (and ultra complicated) cookie recipe on a card, and it’s the only copy. One day their dog eats the card. You might as well ask how they could lose the recipe, don’t they still have the baked cookies?
The source code is like the recipe; the compiled copy of the software is like the cookie. The source has all the information needed to make the compiled software, but the compiled software is “baked” (that is, compiled) in such a way that a lot of the information that was in the source code really isn’t there, or can only be inferred with some guesswork. A very clever person might be able to figure out the recipe with a lot of work, but it’s not likely to be exactly right and it would be a big pain in the butt.
No. The final version that consumers get is something that has been run through a compiler. That compiled code is what your computer/console is running, not the raw source code.
It is absolutely possible to lose the original source code that was used by the compiler. This is normally because the company did not keep it around through complete lack of care to archive their own creations or if the original coding techniques just fell out of general programming practice and/or favor. It can also just be stuff like merger and acquisitions in the industry over the accumulative years just had the original code lost due to the shuffle of people and computers. Companies are like the people they employ and can lose things when they aren’t well documented or taken care of.
While it can be possible to reverse engineer the original source code, it is very time consuming to do so.
Other people have made a cake analogy, which I think is pretty apt.
It is generally very difficult and time-consuming to reverse-engineer source code from compiled executables. It can be done, but those are the sorts of community projects that take years of effort to accomplish.
The reason many companies lose source code is the same reason they lose anything else. They didn’t value preserving it and sometimes shit just happens. I think these days, most companies are better about this, but back in the day, they were either dismissive of the prospect that these things would maintain cultural relevance, or ignorant to the very real possibility of their stuff vanishing if they didn’t make active efforts to preserve it.
High level code is compiled into instructions to be fed to the processor. That’s the binary, the executable (.exe). It’s indistinguishable from its original form and can’t be translated back. Compilers perform a ton of optimizations along the way too which make the result more efficient, but even further from its original form.
Decompilers exist but it’s not a silver bullet. They take the compiled binary and generally output C code (even if the game was written in another language). It’s a best guess, and the optimizations done in the compilation make the result extremely cryptic.
I’ve reverse engineered game binaries and it’s very difficult to interpret the result. It can take weeks for me to interpret parts even when I have a good idea what they’re doing. I’ve spent years on one game and that was just to understand key parts of it, not to flesh out workable source code from it.
Latest Answers