Jump to content
  • Advertisement
Sign in to follow this  
Nicholas Kong

Why do unused game assets get stored in the game?

This topic is 1433 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I never understood this and never questioned until now. You might have seen people who know how to get into the game code and find a lot of interesting things that the average gamer would not be able capable of tampering with.

 

Unused assets makes the game file size much better, so what is the point of it? Won't RAM or CPU power be used in some way? Won't there be inefficiency or optimization issues?

 

Why not just take the unused game assets out?

 

 

Share this post


Link to post
Share on other sites
Advertisement

I tend to leave everything in because when I backup my project to whatever repository, I'm never 100% sure if I'm going to need that asset down the line. It beats having to remake assets. Whether it's a little audio file, or some placeholder art, it might come in handy, and it saves a ton of time to not have to recreate the asset. If I ever actually ship something I'm sure I'll parse down the unused files a bit, but it can be tricky figuring out exactly which ones are used/not used without quite a bit of trial and error, especially when you're dealing with dozens or even hundreds of assets.

Share this post


Link to post
Share on other sites
There are two parts to this. One is a technology weakness of most game engines. The other is just a fact of game development.

For unused assets, this mostly boils down to most engines lacking the ability to really filter down which content they're using. e.g., if there's a script or other code that loads random assets from the data directly there's no way for a tool to reliably cull out unused assets. An approach that can solve this is to only allow code to reference asset lists that are themselves stored in data and in which the asset store is attached to the code via data. This allows a relatively reliable process in which a tool can scan all assets to find precisely the ones that are needed, and precisely the ones that are needed at which times, hence allowing automatic culling of unused resources.

Another technological approach to culling unused assets is to keep a log of all used assets during a game session. Similar to profile-guided optimization, these logs from QA tests can be accumulated and used to filter out unused assets. e.g., if the RTM build 83936 only loaded assets A, B, and C after extensive validation playtesting, you can be reasonably sure that only assets A, B, and V are needed.

With both methods you can allow explicit overrides by content creators, though as soon as you do this you create the possibility for unused assets to be shipped. You still want tools to at least scan this list and give a report on whether they're actually used according to the game's other means.

Ultimately, this illustrates Sean's "First Axiom of Games Engineering": it's all about the tools, dummy. This is also strongly illustrated by the popularity of Unity or Unreal which are just really polished complete-package tools for making games.

So far as code that ships with the game with unused features, this is harder to solve automatically. There _are_ tools that can find unused blocks of code and help you strip them out. You can also just be smarter about removing features; I've noticed many developers are far too reticent about stripping unused code despite having a perfectly functioning Git/P4/SVN/whatever server carefully keeping track of every version of the file. This is less common for Git users and more common for P4 or SVN users, as the later do not allow you to (easily) commit in-progress private work and hence push developers to leave in old code during large refactors, just in case you need to partially roll back the changes.

The real issue usually just boils down to time: managing content or code takes up time which could be spent making the game better. If the studio didn't smartly invest in tools up front during pre-production then writing new tools is also an expenditure of time that is best spent improving the game (though investing in tools cuts down time in the long run if you're not in the death march to ship).

Share this post


Link to post
Share on other sites

We tend to integrate code into the graphics engine which does things like logging which mipmaps of a texture are actually used, and for how long.

 

It's amazing the number of times you find that a 4K by 4K texture is stored with 11 mipmaps in the chain and only the last 7 or used. blink.png

 

We also write tools that scan the games data files for repeated items, and even repeated vertex buffers.

 

But the single most important one is a texture scanner. It looks for textures that have zero pixel variance.  I.E. they are a single solid colour.

 

When it finds one, it gets shrunk to 4 by 4.

 

Modern tools often expect a texture set rather than a texture. So the engine looks at the object and says "ah it's a dynamic object, so it needs a diffuse map, specular map, normal map, ambient map, and tangent map."

 

Often an artist will just stick in a 1K or 2K texture filled with rgb 128,128,128.

 

What a waste! What a waste!
What a waste! What a waste!

 

Because I tried to play the fool in a six-piece band
First-night nerves every one-night stand
I should be glad to be so inclined

What a waste! What a waste! But the world don't mind

 

I could be a lawyer with stratagems and muses
I could be a doctor with poultices and bruises
I could be a writer with a growing reputation
I could be the ticket-man at Fulham Broadway station

Share this post


Link to post
Share on other sites

If you are talking about full release games, then probably a few things are happening here.

 

It's "Downloadable Content". And that term is used very lightly. It's actually a rampaging paradigm with big companies that's slowly growing. They claim it's DLC content, but the reality is that everything is already on the disk. This means the models, the level data, the story data, scripting, everything. And if hacked into, little effort is needed to run it. This simply means that around the time of the release, game companies decided to try and squeeze out a few more bucks by cutting down what was already in the game. After all, with their average consumers being believed to have little technological knowledge, they wouldn't find out about it.

 

The other part of it is, that it's too buggy to be released with the game content, and with scheduling dates, they had to cut it out. So they don't completely remove it from the game, they just left it because they can afford the space loss if it's a PC game, or they have plenty of space on the disk to waste.

 

Or simply, just a project or model data that was never used.

 

It actually isn't uncommon really.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!