How do people lose the source code to their own game?

So, today I was watching a video that had examples of game developers losing the source code to their own game. What I want to know is, how?

Before I start, I just want to let you know that seeing things like this happen to other games, it makes me very thankful that we have the source code to my favorite games like Doom, Wolfenstein 3D, Duke Nukem 3D, and other FPS games in that era.

So, for a really long time, I believed that every company had a vault of any kind that stored information that was very important to the company. Secrets that have not been revealed to the public. Unreleased content (cancelled media is a good example of what might be in there). But after hearing that it is common for game development companies to lose the source code to their own game, I kind of stopped believing in the whole "secret place with lots of stuff hidden away" thing, and made me think of the one question I have about this: HOW!? Oh wait, I've said this already.

How does a source code to a game that a company most likely values very importantly gets lost in the middle of nowhere? If a game developer goes bankrupt, then it would make more sense for the source code to be lost in my opinion, cause it's probably not easy to liquidate EVERY asset when a company goes under.

I do not know if you've tried doing your own doom mod, doing that you'll see why

because when you make a mistake you can even corrupt the game, and with it, if you do not have backup copies

goodbye game

Source code gets stored on archive, say a backup tape, then the tape goes missing or is destroyed. And the internet couldn't always be used for bulk storage at the time.

Any more easy questions, @crazyflyingdonut?

Just now, Edward850 said:

Source code gets stored on archive, say a backup tape, then the tape goes missing or is destroyed. And the internet couldn't always be used for bulk storage at the time.

Any more easy questions, @crazyflyingdonut?

Are you mad? You're mad, aren't you? Did I do anything to upset you? I'm sorry!

... I'm confused. I'm not mad about anything. What is it about that answer you don't like?

2 minutes ago, Edward850 said:

... I'm confused. What is it about that answer you don't like?

This might just be my autism freaking out (yes, I am autistic), but for whatever reason, I thought that your answer was kind of rude. Of course, it could just be sarcasm (which I also have a hard time understanding due to my autism).

When you said "Any more easy questions", I started panicking, thinking that my question was more common than I thought because of what you said.

I don't think Edward was having a go at you, just highlight one easy way that code gets lost.

The reality is it's very easy to lose digital data if you're not vigilant about it, especially in a company with multiple people.  It just takes one case of "that's someone else's responsibility" and crucial backups are either lost or not made.  In a company I used to work for, we discovered there were no backups of any of our data because the two IT managers both thought the other one had handled it.   Luckily we didn't have an emergency, but it was a scary moment.

When you're working on code, it's not uncommon to make a few changes and suddenly everything breaks.  Sometimes it's easier to just delete the whole version, go grab a backup and start again from a version you know works.  I once heard a story about a guy who did that to a company's website, went to get the backup, and realized there wasn't one.  Basically someone, once, had forgotten to tick the "schedule back-up" box.  They literally had to build the company website from scratch.

With something like an older games' source-code.  I suspect it's a case of people just kind of thinking they've got a copy safe somewhere, and then when they come to actually find it, suddenly realize for one reason or another it's long gone.

3 minutes ago, Bauul said:

I don't think Edward was having a go at you, just highlight one easy way that code gets lost.

 

The reality is it's very easy to lose digital data if you're not vigilant about it, especially in a company with multiple people.  It just takes one case of "that's someone else's responsibility" and crucial backups are either lost or not made.  In a company I used to work for, we discovered there were no backups of any of our data because the two IT managers both thought the other one had handled it.   Luckily we didn't have an emergency, but it was a scary moment.

 

When you're working on code, it's not uncommon to make a few changes and suddenly everything breaks.  Sometimes it's easier to just delete the whole version, go grab a backup and start again from a version you know works.  I once heard a story about a guy who did that to a company's website, went to get the backup, and realized there wasn't one.  Basically someone, once, had forgotten to tick the "schedule back-up" box.  They literally had to build the company website from scratch.

 

With something like an older games' source-code.  I suspect it's a case of people just kind of thinking they've got a copy safe somewhere, and then when they come to actually find it, suddenly realize for one reason or another it's long gone.

I know that storing data is harder than it seems, even with the new technology that's out.

On one hand, you've got physical media that is slowly decomposing.

And then you have the digital side of things. Sure, it's less likely to decompose because it is on the cloud. But it's at a risk of security because cloud storage is one of the many things that hackers try to get into. Look what happened to the iCloud back in 2014. Almost 500 nude photos of celebrities leaked out for the public to see forever.

It is probably one of:

* We lost the backup/archive

* We rid of it because it was taking space

* We don't legally have it 

59 minutes ago, Bauul said:

With something like an older games' source-code.  I suspect it's a case of people just kind of thinking they've got a copy safe somewhere, and then when they come to actually find it, suddenly realize for one reason or another it's long gone.

This happened to a lot of my old source code from when I was younger.  I'm sure it'll happen again, regardless of how well I take care of it now :-P

Actually, this reminds me of a talk about the original Prince of Persia's source code.

2 hours ago, Edward850 said:

... I'm confused. I'm not mad about anything. What is it about that answer you don't like?

It's not the world's responsibility to perceive you properly. The way you are perceived is your responsibility. Remember my suggestions from the other thread(s)? In one ear and out the other?

If you can't sense the condescension in your reply, you're not trying hard enough, or it was intentional. Either way, good luck with that, over time.

3 hours ago, crazyflyingdonut said:

So, today I was watching a video that had examples of game developers losing the source code to their own game. What I want to know is, how?

Before I start, I just want to let you know that seeing things like this happen to other games, it makes me very thankful that we have the source code to my favorite games like Doom, Wolfenstein 3D, Duke Nukem 3D, and other FPS games in that era.

 

So, for a really long time, I believed that every company had a vault of any kind that stored information that was very important to the company. Secrets that have not been revealed to the public. Unreleased content (cancelled media is a good example of what might be in there). But after hearing that it is common for game development companies to lose the source code to their own game, I kind of stopped believing in the whole "secret place with lots of stuff hidden away" thing, and made me think of the one question I have about this: HOW!? Oh wait, I've said this already.

 

How does a source code to a game that a company most likely values very importantly gets lost in the middle of nowhere? If a game developer goes bankrupt, then it would make more sense for the source code to be lost in my opinion, cause it's probably not easy to liquidate EVERY asset when a company goes under.

It's funny, a lot of software houses have no strict policies on how their projects are stored. I've seen programmers storing their code on their local hard drives! At a minimum, code should be stored on the company's server, which is supported by online and offline backups.

Sometimes, code is stored on media that falls out of favor, like floppy drives (ugh!). When's the last time you saw a floppy drive in a PC? Tape backups were notorious for this.

Also, code is updated often, so if you don't have good version control, you just might overwrite old versions. Or worse, overwrite new versions while looking at an old version.

When companies leave their employees responsible for their code, and then subsequently fire those employees, code can "disappear". Or it can be stored deep within a folder structure belonging to some other project, which gets moved, and subsequently deemed unnecessary, and deleted.

Today, there are lots of options for ensuring that your code is safe. But, in the recent past, online storage was but a dream.

Suggestions:

1. Develop a scheme for storing projects, including source code, resources, data, documentation, etc. Stick to this scheme unconditionally, no matter how small or big the project is. Use it even for little test rigs.
2. Use version control.
3. Keep a log of changes, and store the log with the documentation stored with each version of each project.
4. Do regular backups on a schedule. Figure out how much development time you can stand to lose, and backup that frequently. Do not only incremental backups, but also full backups. Don't always overwrite your backup data - also continually introduce new media.
5. Take some backups off-site, in case of physical damage (like a fire), theft, or other disasters.
6. Test the backups, and make sure you can retrieve data off of them. Plenty of people do backups, but not often test them.
7. Make sure at least two people understand the project storage scheme, and test that they can find and open each project regularly.
8. Maintain physical and virtual security, to your networks, servers, backups, and to the building.
9. Keep your employees happy. This one might be the most important of all.

Idiocy. In the old days, people didn't make backups until specific benchmarks. Then PC crashes happen and data gets lost. Misplacing backups. With old hard drives, sectors can get lost. If only 1 person had a copy, that game is lost. Anything you work hundreds to thousands of hours on should always be backed up on multiple sources. There are of course ways to get the deleted data back, assuming the hard drives haven't been reformatted. I've dealt with lots of programmers who know nothing about that... they just program.

Bitterness. There have been cases where 1 company gets sold to another and rogue employees delete code or give the wrong code such as old, outdated code. This is different than idiocy as it's done to spite someone else. Also in the case of bitterness, there was one game that was destroyed by someone's wife, fiance or girlfriend that was jealous of the time spent by the programmer. So she destroyed everything... and the PCs. Then again, the "jealous over your programming career" might be code for "cheated on me."

I see a few posts from idiot Steam devs specifying well... sorry guys, game can't be updated, I lost the source code. Followed by dozens of comments how to restore things.

Also, over on Steam, there was a collection of 4 games... sold from 1 publisher to another. The problem is the 4 game source codes managed to get lost by the new publisher due to what I refer to as "idiocy." Then the old publisher chimes in to say "as specified by the contract, we had deleted our own copies of the source code." It makes me think well the source code was probably emailed or stuffed somewhere to transfer it from the old publisher to the new publisher.

I remember my day job company took in an offer from a science lab as a client. The science lab's contract had all sorts of interesting specifications, such as we needed to have MILLION DOLLAR INSURANCE against data loss without recovery. Also... a different MILLION DOLLAR INSURANCE against data breach being caused by vehicle crash in the theft of physical data. Anyway there were so many hoops with that company that my company bailed. They thought of everything. It was amazing to read. I need to check to see if I still have a copy.

As someone who has lost days or hours of work... it's always quicker to do it the second time than the first. Get back on that horse immediately, before you forget.

11 hours ago, geo said:

Idiocy and Bitterness

At work, I was tasked with a strange programming request. The company had sold subscriptions for this monthly data CD that the customers would receive each month. The data on the CDs was encrypted, and each customer had the decryption program. So, each month, the company would compile the data, encrypt it, and burn it to a bunch of CDs that were mailed to each customer.

The guy that wrote the encryption/decryption system left the company suddenly, and stole the source code to the encrypter. We were able to recover the source code for the decrypter, but did not have the encrypter source. This really put the company in a bind, as they couldn't create any more data CDs, and there was only about a week left before they were due. So I was asked to reverse engineer the process, using the decryption source, and an encrypted CD, and create a new encrypter that could be decrypted on the customer's PCs.

Luckily, the guy was not very educated in encryption. The decrypter code was about 60 lines long, and consisted of a bunch of string manipulation that shifted bytes around, followed by an exclusive-or (XOR) against a 100-byte text key.

This was fairly obvious when looking at the raw encrypted data on the CD. The original data had a lot of zeros in it, so, when encrypted, that 100-character text key could be seen repeated all throughout the data.

Anyway, in the decrypter, I was able to "algebraically" reduce the string manipulation to a single line of code, followed by the XOR process. I was told that my new decrypter was 100x faster than the version shipped to the customers. At this point, creating the encrypter was pretty easy: reverse the process, and determine what text key was used. I determined that with statistics, combined with a copy of last month's unencrypted data. I was told that my version of the encrypter was so fast that my contact over the phone thought the process had failed. He was expecting a 2 hour wait, and my code was done in a few seconds :)

The text string turned out to be a sentence in Spanish that translated roughly to "The professional work that I am now doing would make my father proud."

I wonder if his father would be proud that he stole company property after having left on bad terms...

Anyway, that was a case where an employee was directly responsible for the loss of source code. I've seen this a lot: Programmers obfuscating their processes as a means of "achieving job security." In reality, all it really accomplishes is pain for the people hired to replace them. These new hires, eager to impress their new employers, work extra hard to recover from the damage done by these criminals, and the company itself often doesn't miss a beat.

Quote

As someone who has lost days or hours of work... it's always quicker to do it the second time than the first. Get back on that horse immediately, before you forget.

I used to have a computer that, after 4 hours or so, would overheat, and lock up, causing me to lose unsaved work a lot. This quickly teaches you to save often, and make backups!

1 minute ago, kb1 said:

Anyway, that was a case where an employee was directly responsible for the loss of source code. I've seen this a lot: Programmers obfuscating their processes as a means of "achieving job security." In reality, all it really accomplishes is pain for the people hired to replace them. These new hires, eager to impress their new employers, work extra hard to recover from the damage done by these criminals, and the company itself often doesn't miss a beat.

At least everyone thought yours was better. That should be something to smile about.

3 minutes ago, crazyflyingdonut said:

 

At least everyone thought yours was better. That should be something to smile about.

Thanks. Yeah, my contact was impressed, and that did feel good. Everyone else? I've found that no one really cares about what work goes into making something work well. Instead, they come to expect it. Every time someone clicks a toolbar button or menu item, they expect some result to occur within a half-second or so, and if they don't get it... "This program is a dog...man is it slow!" It doesn't matter how much work is required - if the user doesn't get a quick response, they think the program sucks.

Things like the "mouse hourglass", and progress bars usually slow down programs, just a little bit. But if you don't include them, people will complain. And, if Version 2 takes 3 seconds, Version 3 better not take any longer. Gains like this are quickly forgotten, and become the norm.

I've said it before: You have to generate your own appreciation in this business, otherwise you're going to be left disappointed.

In some cases, think of the stupidest possible reasons you could possibly imagine, and rest assured that those have definitely happened.

One case I'm aware of is Konami losing the final source code for Silent Hill 2. The HD Collection version was apparently built off of an older version of the code, and the developers had to fix many bugs that weren't present in the original game. No idea if that was Konami's mess-up or members of Team Silent taking revenge for how the company treated them by stealing/hiding/deleting it.

Maybe they just don't want others to see their old embarrassing code.

On 9/6/2018 at 4:46 PM, kb1 said:

I've said it before: You have to generate your own appreciation in this business, otherwise you're going to be left disappointed.

* most people don't know what goes into coding

* self-promotion is important in almost any profession

On vendredi 7 septembre 2018 at 2:46 AM, kb1 said:

Things like the "mouse hourglass", and progress bars usually slow down programs, just a little bit. But if you don't include them, people will complain.

Waiting 10 seconds with a timer showing you that only have to patient for 9... 8... 7... etc. seconds is psychologically much better than waiting 9 seconds without knowing if the process is ongoing or just stalled.

And the longer the wait is, the truer that is. If the process is going to take over three hours, and you don't have a progress bar showing that #1 the program didn't hang and you don't need to kill it with the task manager/a hard reboot and #2, you have time to go make yourself a cup of coffee and perhaps go on a short walk outside, well I say give the guy or gal who add in a progress bar to that the Nobel Prize for Peace.

Recently I saw traffic lights where the red light was a LED display. There was a circle looping clockwise and a number in the middle, each time the circle was fully redrawn the number decreased by one. That made waiting behind a stinking truck that much more tolerable.

Hm, I feel like it depends on the waiting time. Seeing a traffic light that says "20 seconds left" is definitely nice, it gives me a feeling that I'm just about to start moving again. But if I have to wait more than 99 seconds, I might prefer not knowing the exact number since it's kinda big and discouraging (speaking as a pedestrian here, perhaps it's different for drivers).

People just have to learn that how you perceive time is relative to your surroundings. A moment also has been scientifically determined to be 2 second.

Although not the same as programming code, I lost the code to my first website (which is no longer online). I backed it up on a CD and moved a couple times. Now I have no idea where that CD is and I haven't seen it for over a decade. Luckily I only had some bad photoshopped images and pro-wrestling midis I attempted to make. So I don't really miss it.

P.S. For anyone that is curious, one of them was Chyna's "Don't treat me like a woman" theme as I noticed it was basically the same as one of Chris Benoit's WCW themes just with some minor edits. It was bad I tell ya.

others have covered this topic well. it's also worth mentioning that it was more difficult to make backups in the past, which can lead to data being trapped in old media. This presents the problems of data rot and difficulty in transfer/digitization. then of course, accidents happen (fires, floods, earthquakes, etc), and if no one was conscientious enough to digitize/backup data, losses can easily happen.

when it comes to data, redundancy is key.

Some people, particularly people in decision-making positions in companies, are really fuckin' dumb. For the longest time Sony Online Entertainment's system of version control was an FTP server. No git or anything, you just write over your changes on the server.

Offsite backups weren't really a thing until the events of Sept 11th 2001. Organizations realized the need for disaster recovery in the event all storage is destroyed in a single geographical location. People take it for granted today with the prominence of cloud storage. 

I used to store backups on a different drive. That proved to be insufficient when a burglar made off with the machine.

On 9/13/2018 at 5:24 AM, greentiger said:

* most people don't know what goes into coding

* self-promotion is important in almost any profession

Self-promotion *is* important, but self-appreciation is what keeps me going. Relying on others to notice leaves a lot to be desired.

On 9/13/2018 at 5:47 AM, Gez said:

Waiting 10 seconds with a timer showing you that only have to patient for 9... 8... 7... etc. seconds is psychologically much better than waiting 9 seconds without knowing if the process is ongoing or just stalled.

 

And the longer the wait is, the truer that is. If the process is going to take over three hours, and you don't have a progress bar showing that #1 the program didn't hang and you don't need to kill it with the task manager/a hard reboot and #2, you have time to go make yourself a cup of coffee and perhaps go on a short walk outside, well I say give the guy or gal who add in a progress bar to that the Nobel Prize for Peace.

Very true, even if the progress bar doubles the runtime. Amazing how that works.

On 9/13/2018 at 5:47 AM, Gez said:

Recently I saw traffic lights where the red light was a LED display. There was a circle looping clockwise and a number in the middle, each time the circle was fully redrawn the number decreased by one. That made waiting behind a stinking truck that much more tolerable.

Oh, that is awesome - I've never seen traffic lights like that. I really despise the city when they paint the ring around the light black, so you can't tell when the opposing light is changing from green to yellow. This promotes road rage, as far as I'm concerned.

On 9/14/2018 at 4:26 PM, segfault said:

Some people, particularly people in decision-making positions in companies, are really fuckin' dumb. For the longest time Sony Online Entertainment's system of version control was an FTP server. No git or anything, you just write over your changes on the server.

*This* Often, I see the 'decision makers' not wanting to spend the money. Usually it takes a catastrophe to open their eyes. Meanwhile, it's the guy in the trenches that suffers, and has to save the day.

As part of my internship, we were split up into teams and each team had to design and develop a project.  Our project ended up doing really well, to the point where the company was considering making it into an actual product, but the problem was that one member of our team had been put in charge of maintaining the code, and he had stored it remotely on a virtual machine at a company server, apparently unaware that said machine was going to be shut down and deleted as soon as the summer was over.  As a result, not only was the code effectively lost forever, but the employee who had failed to back it up ended up leaving out of shame.  The lesson here was you should always take the initiative with keeping emergency backups, because even when the employees do everything right mistakes can happen.

We ended up not using the project, because the lawyers had come back saying that it was a little too close to violating a certain patent, so that employee probably would have done well to just own up to his error.  Oh well.  I hope he's doing better now.

42 minutes ago, Crawldragon said:

As part of my internship, we were split up into teams and each team had to design and develop a project.  Our project ended up doing really well, to the point where the company was considering making it into an actual product, but the problem was that one member of our team had been put in charge of maintaining the code, and he had stored it remotely on a virtual machine at a company server, apparently unaware that said machine was going to be shut down and deleted as soon as the summer was over.  As a result, not only was the code effectively lost forever, but the employee who had failed to back it up ended up leaving out of shame.  The lesson here was you should always take the initiative with keeping emergency backups, because even when the employees do everything right mistakes can happen.

 

We ended up not using the project, because the lawyers had come back saying that it was a little too close to violating a certain patent, so that employee probably would have done well to just own up to his error.  Oh well.  I hope he's doing better now.

If I may ask, what was the project about? Clearly, it cannot be confidential since whatever it was supposed to become ended up getting cancelled in any possible scenario.