When a game’s “code is lost” what stops a company from dumping/decompiling code from a disk or cartridge copy of the game for things like remakes and remasters?

500 views

When a game’s “code is lost” what stops a company from dumping/decompiling code from a disk or cartridge copy of the game for things like remakes and remasters?

In: Technology

9 Answers

Anonymous 0 Comments

You can’t really decompile code. Compiling takes human readable code and turns it into something a computer understands. A lot of what makes code human readable (comments, white space, variable names, function calls, etc.) is useless to the computer running it though. So all of that has to go. It’s just thrown away, there’s no trace of what originally made it readable left in the final product. You might be able to undo it to an extent, but, without that original information, what you get from decompiling wouldn’t actually look anything like the original code you compiled (even if it would perform the same functions).

Nobody likes working on code they didn’t write (I barely even like working on the code I did write), even if it’s pretty well commented and written. Its almost always a huge pain trying to figure out what exactly the coder had in mind, and trace through how everything works. Now take out anything that would help the code make sense to somebody who didn’t write it, and what you’re left with is basically as hard to figure out as just writing the code over from scratch anyway.

Anonymous 0 Comments

With all the optimizations and obfuscations done by modern compilers, the process of compiling software is generally a one-way trip. When you lose a game’s source code, you don’t just lose the thing that makes the engine work: you often also lose the most important source of documentation and insight as to how it was intended to work. Automated “decompilers” exist, but they can’t actually reproduce the original source code: they can port the machine code to a higher-level language, but this generally bears very little resemblance to the original source. That’s not to say that it’s useless -it can be an important reference tool as you rewrite the program- but in the end you’re still rewriting the program from scratch.

Anonymous 0 Comments

They absolutely can. However 99/100 times it’s a pain in the neck and more effort than rewriting the thing from scratch.

Code is written by humans for humans. It has nice human structures that make sense, it is organized in to well named files in neat logical folders, it has descriptive variable names, it hopefully has a bunch of comments so that developers can communicate with both each other and their future selves, functions have clear markings what they are intended to do, all that nice stuff.

The computer doesn’t care: it neither needs, understands, nor wants any of that. In the process of compiling the code from human-code to machine-code the compiler will discard anything that it believes isn’t useful to the final product. Comments are thrown out, file structures pressed to single files, variable names replaced with shorter pointers, all of the human element vanishes.

Decompilers can’t bring any of that back. They don’t know what the compiler threw away and have no way of recreating it. What it will do is create its best approximation of “human-readable” code that does the same thing as the original code. However it will still have all of that awkward computer-preferred structure and meaningless variable and function names. Working with the de-compiled code as a human is extremely tedious and you’ll need to put in a lot of work just understanding what each section of the code is meant to be doing. And remember we’re talking hundreds of thousands of lines of code: Libraries worth of nonsense.

At some point it’s better just to give up and do it again from scratch.

Anonymous 0 Comments

decompilation is not a perfect process especially on really old games where the original devs likely stripped all debugging symbols(hooks where you can associate variable names to memory as the name suggests used for debugging) to save space.

in this case a dump/decompilation will be guess work at best where you’ll end up with code that likely will work about aswell as the original, but it will be near impossible to maintain as all non essential information simply isn’t there anymore(stuff like comments simplified data structures etc..). this is clearly not the level of material you need ot remake a game with modern tech.

also “code” isn’t just necessarily the game logic, this also include stuff like the original assets that in the retail version are compressed/redone to be compliant with the engine limitations often meaning original quality/model readability/sound quality is just gone and trying to upscale this is a waste of time and effort where it’s arguably easy to remake from scratch(which brings the last point remaking these assets might not be possible anymore due to “life”).

Anonymous 0 Comments

Decompiling isn’t all that easy, and if it works at all you’re left with bare code that contains no notes about how anything is supposed to work. Millions of lines of code that someone wrote years ago with no explanation about what they do or why.

While it’s theoretically possible to reverse engineer a program that way, it is much too time consuming to be practical for a product you’re trying to make money on.

Anonymous 0 Comments

Decompiling is like figuring out a recipe from an already baked cake. Yes, it’s totally possible to produce a recipe that enables you to replicate the cake, but you lose all the supporting information like how long and hot to bake it, what alternatives there are, and other bits and pieces that make working with it just plain difficult.

It’s hard enough to keep source code of that size tidy and useable. It’s 1000x harder if it’s code from decompilation.

Anonymous 0 Comments

Software developer here, former game developer (not that it matters),

Compilation is a one-way transform. Take, for example:

bool less_than_seven(int x) {
return x < 7;
}

This is code, a text document written for humans, by humans, and only incidentally for computers to possibly compile and execute. Computers don’t need to know what a `bool` data type is, it doesn’t need to know that this is a function, and specifically, it doesn’t need to know that it’s named `less_than_seven`. It doesn’t need to know the variable is called `x`. It probably doesn’t even need the variable. It very likely doesn’t care that we’re doing a `<` comparison.

All this information can and likely will be lost when translating to machine instructions. You can’t search an executable program for `less_than_seven`. That information is gone. This code, this function, very likely won’t even generate machine instructions for a function call – the compiler might determine the cost of pushing and popping the call stack is more expensive than just performing the comparison in-place where this code is used elsewhere in the source. In place of a variable stored in memory, the compiler will probably store the value in a register. The compiler might even deduce that there are more clever tricks, faster instructions to use than the built-in less-than compare instruction; the program will produce the same result, but it won’t be intuitive.

So gone is all the context – function names, variable names, variables, and data types; gone is the intent as it was expressed for humans in the source code.

There are tools to decompile executable code, but it’s tricky at best for other technical reasons. And of course, the tools don’t know what it’s decompiling. So how does it know that some particular piece of memory stores hit points, or bullet counts? All the tool is going to do is deduce what might probably be a variable, and call it `variable_1234_`, and that’s all you’re going to get. And typically, these tools CANNOT produce reversible code – that is to say, what they generate won’t compile again back into the same binary from which it was deduced.

The best you can do is reverse-engineer an approximation of what the original source code might have been. And I emphasize *approximation*, because it won’t be exact, and it won’t be correct, and it won’t be a faithful reproduction. It is incredibly challenging.

Anonymous 0 Comments

The code may have been originally obfuscated via one of the available tools for that language. It wouldn’t prevent decompilation, but the result might not be very useful in human terms.

Anonymous 0 Comments

Part of it these days is literally the scale of the code you’re dealing with even if you have a decompiler that can output readable code.

Code that’s being worked on tends to be heavily commented, and most compilers will strip these comments out to save space in the release build meaning that whilst you have readable code you don’t have access to the details of minutiae or workarounds that make the code work.

Add in to this that identifiers can be references to old systems that were renamed or cut or even in jokes for the original team you can see why the lack of the comments can be a major hindrance.