Why are extra assets left in the final game?

Question

I was just reading about what was discovered in the files for No Man's Sky, a lot of things that weren't used or relevant to the game. I also read a short while ago about the E3 settings being left in the Watch Dogs files. Why do game developers leave old and unused files in the final game?

Surely this just takes up extra space on a disc and means more data has to be downloaded if you download the game?

Also, aren't the developers afraid of what people could find?

Answer 1

Major games use something called a build pipeline. This is like another set of tools that handles building the game content for all the different distributions. Multi-platform games like No Man's sky and Watch_Dogs most definitely use different assets for the different platforms. So the way I see it there two possible answers to your question.

1. The devs forgot to remove certain assets from the pipeline and they got bundled with the actual game.

2. The devs intentionally left some "unused" assets in the game for later use during a patch or update, because they were unable to meet the deadline. Example Devil's Pit from The Witcher 3.

Answer 2

It can be harder than you think to find all the referenced content in a large game that is worked on by multiple people. Even when there are explicit tools in place to help (we built such tools at ArenaNet, anybody who uses Unreal has access to Unreal's version of those tools, Bungie has tools that do the same thing and even gave a talk about them, et cetera)

There are several ways content could be referenced that can defeat such systems, generally simply by referencing the content by something that system can't track (such as creating a implicit or hard-coded reference in code to some asset).

Even assuming you have solved the problem of finding all content inter-references, you have the problem of not being able to tell if something is actually used. Maybe some asset is referenced in a script somewhere, but the trigger volume for that script is incorrectly placed inside a wall and the content can thus never spawn in-game. Testing this exhaustively is quite difficult as well.

When automated (or automatable) methods for detecting and filtering out unused content fail, you are left with the old-fashioned way: human intervention. Humans make mistakes, bad assumptions (they may think a file is still used even though it isn't because somebody else made a change), and yes even sometimes choose to intentionally leave irrelevant content in the game as Easter Eggs. It's just natural human fallibility that leads to this.

It's usually not a sufficient amount of content to really move the needle much for load or file size optimizations. There are also tools for reporting the largest or slowest assets in any large build chain or engine, but the focus there is to reduce the impact of the major offenders and not find and locate every single wasted byte. Usually.

Answer 3

What's missing in the other answers is that this has nothing to do with games. It affects all applications.

There are always files, and code that isn't going to be used in any reasonably complex program. This happens because of the following 2 things:

• Programs evolve over time.
• It's requires effort to figure out if some piece of code or some file is no longer being used.
  • If you remove stuff without spending said effort, the behavior of the application becomes unpredictable

Answer 4

Adding to/ehancing Uri Popov's answer:

3. Programs may install updates packages that contain new, improved versions of existing asset files and an update to the program itself. For my part, I do not overwrite previous versions of the asset files, because I want to allow a fallback to an earlier program version (imagine, for example, the panic of having distributed a totally disastrous update :-)). The original program version may be using texture_0.dds and the updated one texture_1.dds (hence texture_0.dds is no longer needed). Overwriting (using a single name only) would prohibit a removal of the program update, i.e., the fallback to the original version, unless there was also the tricky mechanics of overwriting newer asset files with older ones. And that is not something anyone wants to support.

Edit:

Reacting on a comment to the original question,

Nobody remembered to delete them

4. I would say that nobody dared to delete them. What happens if the game lacks sufficient error trapping (by mistake, ignorance, error, key-person left the company, etc.) at the loading point of that (now missing) file X, and the problem was undiscovered despite intense testing? Say the loading occurs only "every 3rd time", only at level 35 of 36, which you reach only in 4 weeks of intense gaming :-). Lost reputation by crashing software is a brutal phenomen, and it may in the worst case end up in a bankrupt company. Better not touch that file :-).

Answer 5

Why do game developers leave old and unused files in the final game?

Surely this just takes up extra space on a disc and means more data has to be downloaded if you download the game?

Also, aren't the developers afraid of what people could find?

Game developers leave unused files in the final game because they don't want to spend the effort to find and remove all unused files. After all the games runs just fine with a bit of extra material and time is money. Cleaning up increases the costs (depending on how automatized this happens).

While it takes extra space and means more data has to be downloaded, this is usually not the developers problem and even customers usually do not care much about slightly bigger download sizes.

Not sure if developers need to be afraid of anything people might find? Why should they? As long as there is nothing compromising in the extra files (really bad artwork, jokes about their bosses or the customers, ...) they probably do not care much. Although in some cases they are actually afraid of what players might detect in the assets.

Answer 6

It's been hinted at, but it hasn't been fully touched on by the other answers: it all boils down to cost, and some of the costs are trickier than you might think.

The most obvious cost is that someone has to delete them. Now you could just put an intern on the case and have him go searching through files and whatnot to remove the ones that aren't needed in the actual game. But still, you have to pay for this and, even if you don't (because you're a monster who doesn't pay interns) you still could have had that intern doing something useful like ordering pizza for the dev team, so it still costs you.

The less obvious cost is that the resource you're about to remove was put in for a reason: are you absolutely sure that reason is obsolete? Sure, you wrote this code for a demo and don't need it anymore, but is that entirely true? Did you write a useful function that you forgot to migrate to the other libraries? Did Stacey make a really cool graphic for the demo that ended up in the real game? Does an internal simulator still make use of that old level you used for testing?

Making games is a business. Even if it isn't a money-making business, it's still a business with limited resources. Every decision requires a cost-benefit analysis, even if you don't go writing business cases for each one. And the simple fact is that cost of leaving those assets in the game is a slightly larger download, and the benefits are a significantly reduced risk of something blowing up right before release.

All those question marks in the "less obvious" paragraph represent uncertainty. You just don't know. And when you're running a business, you have to trade your unknowns for knowns. And what is known is that the package you built passed testing, even if it has a little bloat to it.

There other potential costs such as information leaks around the development process that could potentially be used to derive hacks, but you made it through the testing process as-is, you shouldn't really be worried about that.

tl;dr: No one will notice a 4% larger download, but they will notice if you broke the game by removing necessary files.