Why do video games have unused data on discs?
video description
Like you said though, there's a good part of it is due to many teams working separately, so when they want to make the final product, they have to make decisions and rearrange things. One example of this is FF7. There are a few cases in that game that are of interest.
There's a whole scene that was scrapped out in Midgar's Slum 7. Normally it's triggered by Cloud exiting the Seventh Heaven, but the game doesn't normally let you do it. But the code and scene are still there if you cheat your way. The japanese text is still there. The scene itself is more or less a retelling of events later explained in the game, so they probably removed this scene for story cohesion.
Another case of interest, entering Nibelheim the first time will have comments from your party members. All of your party members have comments, even translated... EVEN if they are not supposed to be in your team yet, like Cid or Vincent for example. This could be a case that they reworked in which order the events happen or which order the villages are visited.
Another thing is Aerith has animations for all attacks in the game, even spells and abilities that you couldn't get at the point she's still in your party. Again it would be troublesome to either code her to not have those animations, or removing them. She also has translated lines in areas after she leaves your party, if you hack or use the debug room to add her to your party. One such example is the mountain lodge. So it's quite possible that events were coded ahead of time, but the final product changed the order of things.
The last point of interest is that famous scene where Aerith meets Sephiroth. Sephiroth's gloves disappear, the angle of the sword, the lack of blood... it's possible that they took several CGI scenes and made a single larger one with it, since it doesn't seem consistent. The remake will hopefully make it more cohesive.
Date: 2022-03-21
Related videos
Comments and reviews: 9
--
Dislike for disagreeing on how you think things works.
For game bugs, well, bugs are always there, you can't fully eliminate it. According to software engineering theory, you can estimate the amount of bugs in a software and then know how many bugs you need to fix, in order to eliminate X percent of bugs. Since that X can never be 100, well, developers have to make a decision on how stable their games should be without taking too much time on debugging. Oh and, evaluating the potentially gain for debugging a bug is quite important, which also makes the not-so-broken bugs being left behind a lot, I guess.
For unused assets, giving that Bethesda has made 2 talks in GDC already, it's pretty sure that, in their workflow, they build assets in kits most of the time, which means that kits should be able to cover the need but doesn't necessarily be used completely. If there are certain asset in the kit that didn't get used for some reason, well, for future compatibility it would be best to leave them behind. It's not like they couldn't clean those up, it's the age of computer so why bother doing that job manually anyway.
For unused rooms, well, in the case of Bethesda and other modern game companies I guess they just don't bother removing it. For games in an older platform, where storage capacity is finale, since they got to test the game on real hardware anyway, they'd just leave unused rooms in the ROM file. Not every ROM contains a proper file system, I guess, some might just be a giant blob anyway. And therefore, they might mark those unused areas -available- but there's no reason to manually write in tons of zeros to fill the place.
reply
Dislike for disagreeing on how you think things works.
For game bugs, well, bugs are always there, you can't fully eliminate it. According to software engineering theory, you can estimate the amount of bugs in a software and then know how many bugs you need to fix, in order to eliminate X percent of bugs. Since that X can never be 100, well, developers have to make a decision on how stable their games should be without taking too much time on debugging. Oh and, evaluating the potentially gain for debugging a bug is quite important, which also makes the not-so-broken bugs being left behind a lot, I guess.
For unused assets, giving that Bethesda has made 2 talks in GDC already, it's pretty sure that, in their workflow, they build assets in kits most of the time, which means that kits should be able to cover the need but doesn't necessarily be used completely. If there are certain asset in the kit that didn't get used for some reason, well, for future compatibility it would be best to leave them behind. It's not like they couldn't clean those up, it's the age of computer so why bother doing that job manually anyway.
For unused rooms, well, in the case of Bethesda and other modern game companies I guess they just don't bother removing it. For games in an older platform, where storage capacity is finale, since they got to test the game on real hardware anyway, they'd just leave unused rooms in the ROM file. Not every ROM contains a proper file system, I guess, some might just be a giant blob anyway. And therefore, they might mark those unused areas -available- but there's no reason to manually write in tons of zeros to fill the place.
reply
JoSilverNG
Hell, another good reason is just that people forget it's still in there. Simply put games are big and take a long time to make and if someone had to go through every asset in a game and see if it's in the final game would take forever. While there are automated systems to tell if an asset is referenced some how that doesn't mean it's possible to know it's being used or remember if it's being use.
Imagine your making a shooter and there is some kind of beach level, your artists make a sand being shot particle system and the game play programmer adds the functionality when a sandy surface is shot use that particle system. Later on in development they decided the beach level is cut and no other level has sand in it. Now as the game play programmer, is the thought -I'd better remove the sand particle system- in your mind. Probably not, you have more important things to worry about.
Hell you might even do a quick look to see which particle systems should be removed and you come across -Wizard Spell- particle and think we cut the wizard long ago and take it out and then you come across -sand shot- particle and think nothing of it because it seems like something that should just be there.
reply
Hell, another good reason is just that people forget it's still in there. Simply put games are big and take a long time to make and if someone had to go through every asset in a game and see if it's in the final game would take forever. While there are automated systems to tell if an asset is referenced some how that doesn't mean it's possible to know it's being used or remember if it's being use.
Imagine your making a shooter and there is some kind of beach level, your artists make a sand being shot particle system and the game play programmer adds the functionality when a sandy surface is shot use that particle system. Later on in development they decided the beach level is cut and no other level has sand in it. Now as the game play programmer, is the thought -I'd better remove the sand particle system- in your mind. Probably not, you have more important things to worry about.
Hell you might even do a quick look to see which particle systems should be removed and you come across -Wizard Spell- particle and think we cut the wizard long ago and take it out and then you come across -sand shot- particle and think nothing of it because it seems like something that should just be there.
reply
David
I'm a developer myself, specifically a web developer, but I can bring in some incite. The process of changing the project that won't directly affect the end user experience is called refactoring. There are many reasons one may refactor a project such as minor improvements, bug fixes, optimizations, code readability and maintainability but the way I tend to approach this is to get a working product up an running that fits the project specs, and then go back and do all of my refactoring once the product is up and running and I'm not as pressed for time. The idea behind this workflow is to start generating the business money to better justify having me work for them and then doing the grunt work later while revenue is coming in. There are some things that you may need to get out of the way before deployment such as making the program as secure as possible/required (some projects like a medical prescribing software may need to be virtually bulletproof because of HIPPA regulations for instance) but generally things, like removing old assets or legacy code and making them as efficient as possible, can usually wait. This would be a good reason as to why games leave unused code/assets in a game.
reply
I'm a developer myself, specifically a web developer, but I can bring in some incite. The process of changing the project that won't directly affect the end user experience is called refactoring. There are many reasons one may refactor a project such as minor improvements, bug fixes, optimizations, code readability and maintainability but the way I tend to approach this is to get a working product up an running that fits the project specs, and then go back and do all of my refactoring once the product is up and running and I'm not as pressed for time. The idea behind this workflow is to start generating the business money to better justify having me work for them and then doing the grunt work later while revenue is coming in. There are some things that you may need to get out of the way before deployment such as making the program as secure as possible/required (some projects like a medical prescribing software may need to be virtually bulletproof because of HIPPA regulations for instance) but generally things, like removing old assets or legacy code and making them as efficient as possible, can usually wait. This would be a good reason as to why games leave unused code/assets in a game.
reply
MrSysdump
Coder here (Objective-C, C++, C#, Java) You are right i sometimes work on huge projects (Have worked on some games but mainly software) And we leave in huge chunks of code all the time. Weather it be for time or 1 thing is dependent on that section of code and it would be a waste of time to rewrite the entire code just to shrink it down a few lines. Yes it took a lot of time to write the original code but when you start adding revisions to a piece of code that does not bother anything you start adding massive amounts of time. And you are right in my early days of coding i used to be a perfectionist however as time went on i noticed it wasn't worth it. We always used to call it Ghetto code just the term we used for code that was put together in such a way that only the original developer knows what the hell it did, or how to use it right. There is no payoff to writing a streamlined piece of code when no one is going to see it (Unless you are doing API or SDK work for another company wanna make your work look good so you get more contracts). Your argument is %100 valid and true from my view and experience.
reply
Coder here (Objective-C, C++, C#, Java) You are right i sometimes work on huge projects (Have worked on some games but mainly software) And we leave in huge chunks of code all the time. Weather it be for time or 1 thing is dependent on that section of code and it would be a waste of time to rewrite the entire code just to shrink it down a few lines. Yes it took a lot of time to write the original code but when you start adding revisions to a piece of code that does not bother anything you start adding massive amounts of time. And you are right in my early days of coding i used to be a perfectionist however as time went on i noticed it wasn't worth it. We always used to call it Ghetto code just the term we used for code that was put together in such a way that only the original developer knows what the hell it did, or how to use it right. There is no payoff to writing a streamlined piece of code when no one is going to see it (Unless you are doing API or SDK work for another company wanna make your work look good so you get more contracts). Your argument is %100 valid and true from my view and experience.
reply
Zach
As someone who does QA, I completely understand why it's in there. It is a pain in the ass when even fix a normal bug, that can completely break unrelated system thanks to code dependencies. We have had situations where fixing a weapons damage has broken crafting another. I wouldn't complain about extra stuff on the disc or bugs, we try our best and at the end of the day if money isn't made than we don't get paid. So sometimes games are shipped buggy because you have weeks or even months from the time of submission to the time of actually release to the public, hence day 1 patches. A game can take many weeks to be pushed through sony and especially disc based games. Where you have to manufacture everything and have it shipped globally. All the while those weeks and months that process takes you are still finding new game breaking issues everyday. So give the devs a break, we try really hard.
reply
As someone who does QA, I completely understand why it's in there. It is a pain in the ass when even fix a normal bug, that can completely break unrelated system thanks to code dependencies. We have had situations where fixing a weapons damage has broken crafting another. I wouldn't complain about extra stuff on the disc or bugs, we try our best and at the end of the day if money isn't made than we don't get paid. So sometimes games are shipped buggy because you have weeks or even months from the time of submission to the time of actually release to the public, hence day 1 patches. A game can take many weeks to be pushed through sony and especially disc based games. Where you have to manufacture everything and have it shipped globally. All the while those weeks and months that process takes you are still finding new game breaking issues everyday. So give the devs a break, we try really hard.
reply
Patrick
Basically, and to use a game like NBA 2K18 for an example: the developers are building entire buildings, like for the aforementioned NBA 2K18, or NHL 18, EA and 2K are, for those games, fully modeling, the Wells Fargo Center in Philadelphia, for example, they want (almost) everything you see in the real life Wells Fargo Center to be in the virtual Wells Fargo Center, same with Sony and MLB The Show, they want everything you see in the real Citizens Bank Park in the virtual Citizens Bank Park, going back to EA, they want (almost) everything you see in the real Lincoln Financial Field in the virtual Linc (except for the fact that you can still see the old home of the Philadelphia Flyers and 76ers, the Spectrum, which has been in the code for Lincoln Financial Field since the Madden and NCAA Football games since 2003) but they obviously have to not give us everything
reply
Basically, and to use a game like NBA 2K18 for an example: the developers are building entire buildings, like for the aforementioned NBA 2K18, or NHL 18, EA and 2K are, for those games, fully modeling, the Wells Fargo Center in Philadelphia, for example, they want (almost) everything you see in the real life Wells Fargo Center to be in the virtual Wells Fargo Center, same with Sony and MLB The Show, they want everything you see in the real Citizens Bank Park in the virtual Citizens Bank Park, going back to EA, they want (almost) everything you see in the real Lincoln Financial Field in the virtual Linc (except for the fact that you can still see the old home of the Philadelphia Flyers and 76ers, the Spectrum, which has been in the code for Lincoln Financial Field since the Madden and NCAA Football games since 2003) but they obviously have to not give us everything
reply
John
Speaking as someone who has a game development degree, my final project in college was to write my own game. I ran in to a lot of these issues even though I was the only one developing my simple game. There would be times where I would add something to the game's code and it would break the entire game. I remember going to fix a minor glitch in the code that once I fixed prevented the game from even running. Creating games is a difficult process so there are bound to be problems.
As far as hidden/inaccessible rooms, I remember playing around with the original Doom and finding rooms that were inaccessible to me, the player. They were used to hold the monsters that would teleport into areas that were playable. It was pretty awesome to see how the game had been put together and how the monsters were already in the area before they spawned near the player.
reply
Speaking as someone who has a game development degree, my final project in college was to write my own game. I ran in to a lot of these issues even though I was the only one developing my simple game. There would be times where I would add something to the game's code and it would break the entire game. I remember going to fix a minor glitch in the code that once I fixed prevented the game from even running. Creating games is a difficult process so there are bound to be problems.
As far as hidden/inaccessible rooms, I remember playing around with the original Doom and finding rooms that were inaccessible to me, the player. They were used to hold the monsters that would teleport into areas that were playable. It was pretty awesome to see how the game had been put together and how the monsters were already in the area before they spawned near the player.
reply
BROBOTS
So I code websites, and this is very much the case. But there's other reasons why I'll leave extra code in the server, and thats when I use code previously made (not like stolen code but like older code I made, rubygems, etc) and paste it over to implement a certain feature, it's often that the code doesn't fit quite right the way I want. So instead of trying to write the code again, I'll stitch together and add to the code I have. But there will likely be code thats not used, and I may not know it even exists. It's not worth my time to look for it, so I publish it like it is. If it works, and it works well, why the hell would I change that.
reply
So I code websites, and this is very much the case. But there's other reasons why I'll leave extra code in the server, and thats when I use code previously made (not like stolen code but like older code I made, rubygems, etc) and paste it over to implement a certain feature, it's often that the code doesn't fit quite right the way I want. So instead of trying to write the code again, I'll stitch together and add to the code I have. But there will likely be code thats not used, and I may not know it even exists. It's not worth my time to look for it, so I publish it like it is. If it works, and it works well, why the hell would I change that.
reply
ktcd1172
Much easier to comment out a call to a sub or procedure that you have decided to not utilize than it is to just remove the called procedure and then discover that -Oh hey, Bob six months ago found that procedure to be really useful and used it 400 times in his parts of the project.- Which now ceases to function entirely or freezes inexplicably because someone removed that code because it was -Not needed after all-.
reply
Much easier to comment out a call to a sub or procedure that you have decided to not utilize than it is to just remove the called procedure and then discover that -Oh hey, Bob six months ago found that procedure to be really useful and used it 400 times in his parts of the project.- Which now ceases to function entirely or freezes inexplicably because someone removed that code because it was -Not needed after all-.
reply
Add a review, comment
Other channel videos
