But, you're wrong.
The top rated post on Hackernews right now is a bunch of people gushing about how cool it is to see the source code for the Apple II LOGO language[0]. Your code has value beyond whether or not someone is going to pick up a new game-dev trick for their next title. It's a window into how games used to be built. It is a tiny composite piece of gaming history, and history is not just about how Mario was built, it's also about how small games were built, and what trends across the entire industry looked like.
Your code has value beyond just publicly releasing the source. Maybe you would never revisit it in a million years for a million dollars, but the overall gaming industry is interested in remakes and remasters right now, and if you've ever worked for a publisher or sold the IP rights to one of your titles, it is not out of the question that the publisher might want to do a remake without you. That's the entire premise of this article, and if you have the source code, even if it's not portable, even if it's using hardware-specific hacks, even if it's written in an obscure language, your publisher will be in a better position than if you didn't.
To be kind of blunt, this attitude is exactly what I was getting at above. Game devs don't understand why they should even care about history. If your takeaway is, "I don't care about old games unless they make my new PS4 game run faster" you have missed the point. If your takeaway is, "archival only matters if my game is successful, and I don't know if it'll be successful yet", you have missed the point.
I completely, 100% understand that game dev is stressful. Zoom out a bit from that; working in the games industry in general is kind of hellish right now. If you're putting 80 hours a week into building a game for (on average) less pay than you'd get as a general software dev, and you're not doing it because you genuinely care about what you're making... that's a stupid career choice. And if you do genuinely care about what you're making, then try to make sure it lives longer than you do.
Bear in mind, what I'm asking for doesn't have to take much work. You don't have to go crazy building out your source-code in a special way if you don't have time. Change nothing at all about your dev process -- just take 3 minutes when your game ships, stick your raw source code, assets, and a DRM free binary on a flash drive, and then mail it to Jason Scott.
That's it. Just by doing that, you're now ahead of most other companies in the games industry right now.
My takeaway is that you did not even read what I wrote:
a) I said I quit the circus 15 years ago. I did not claim 15 years of game dev experience.
> If your takeaway is, "I don't care about old games unless they make my new PS4 game run faster" you have missed the point. If your takeaway is, "archival only matters if my game is successful, and I don't know if it'll be successful yet", you have missed the point.
b) Neither of those are points I tried to make or that someone reasonably could read into my statements. So I am not going to address those directly nor into your ideas of why I might worked as a game developer.
You are missing the point: Just because you would like to have an introduction into resource-conscious development based on the games you enjoyed as a kid, this is neither the easiest nor an in any way appropriate way to study the topic. Go, read and understand some programs written in the late 60s and early 70s and you'll be 80% there - for 10% of the reading time. The other 20% are obsolete anyway.
c) I completely, 100% understand that game dev is stressful. Zoom out a bit from that
I did that, 15 years ago in a radical way - it is called "leaving the industry".
> Bear in mind, what I'm asking for doesn't have to take much work. You don't have to go crazy building out your source-code in a special way if you don't have time. Change nothing at all about your dev process -- just take 3 minutes when your game ships, stick your raw source code, assets, and a DRM free binary on a flash drive, and then mail it to Jason Scott.
d) That's called IP theft.
> a) I said I quit the circus 15 years ago. I did not claim 15 years of game dev experience.
Just a note on this misunderstanding: you wrote "I have been part of this circus 15 years ago", which was ambiguous because 'have been' is normally used for an action or state of affairs that is ongoing (or has just finished). So the reader either skipped over the 'ago' and read the sentence as 'I have been part of this circus [for] 15 years', or noticed that you'd made an error and had to guess whether it was 'ago' or 'have been'.
The point of preserving history is not to get good at making modern games. This is like claiming that we don't need any silent films because any modern film techniques class will already teach you how to do a long shot or a dutch angle anyway. Hence my original statement: If your takeaway is, "I don't care about old games unless they make my new PS4 game run faster" you have missed the point. We're not preserving history because we're worried we'll forget how to build games.
> d) That's called IP theft.
Of course IP owners and publishers are allowed to send code to the Internet Archive. It doesn't have to be (nor should it be) an individual dev stealing from the company; I'm not sure where you would get that idea. What I meant was that if Sony and Naughty Dog as companies don't have the resources to keep content around on their servers, there are 3rd party nonprofits that will happily do it for them for free.
This is not a new idea, the UK has gone so far as to mandate that every published book needs to be submitted to a national vault for preservation[0]. The US tends to avoid legislative solutions like this, but I know digital archivists who would like to see laws like this passed for games.
This is 100% a problem of dependency management, i.e. a problem common to software everywhere at all times that has never gone away. Whether more work survives is ultimately a factor of whether it's whether it's easy to make it survive, not on the "blame them for lacking effort" angle. Some folks will take the extra time, some won't.
The software that still has its dependencies, we can do something about. For most games that equates to "emulate the release platform, and we get the playable release back" - which is the defacto standard, since it's relatively easy to get copies off a ROM or CD, and it's the single artifact that is most representative of creative intent. It absolutely makes sense that almost all the effort would go towards that. We like seeing Leonardo Da Vinci's plans and studies, but he was focused on results, and we mostly know him for those results.
The source is more specialized, and not as easy to subject to the emulator model. A lot of shops "back in the day" did not even have good backup or version control practices and the game's build system involved a whole custom software project of its own, and only one person knew how to make it go. Getting it even to the point where all the code and assets were accounted for would incur a person-weeks expense, and studios then as now would finish a release with layoffs to shave off salary expense, which in turn gave an incentive to jump ship before finishing to dodge the layoff, leaving certain knowledge about the project in limbo. And employees are often not trusted enough by the management to let them bring in an external drive and dump the project: the optimism of "preserve the art for the future" goes right up against the pessimism of "i'm building a business, not art", and the psychopathy of "if they can't dump the project, they can't steal it". (yes, it happens - on both ends) There are numerous barriers in those crucial weeks around the ship date that can cut off this aspect of archival right at the start, and many a preserved game is the result of some hero who went against the direct wishes of their bosses and made copies in secret.
Nowadays, project tooling tends to fall a little more along standardized lines, and if you start with the goal of minimizing dependencies, you can feasibly have a smooth path to restoring the build without incurring the same overheads that make managers give up on archival to save a dime. So while commercial conflicts of interest remain, it's gotten easier, relatively, if your project scope is not so large that you need to bring in the custom tooling again(which, of course, is what happens in AAA). It's not "sneeze and you've preserved history" easy, but we can work on that.
And what if we're talking about an online game? That's the preservation nightmare taking place today. All the MMOs, mobile games, and so on - those are living things. You can't reconstruct a userbase. So even having running code and assets, it gives you a part of the experience, but it will be empty, fossilized. You will have to fall back on video footage to see it in contemporary context. That said there is the occasional revival effort, such as with Habitat[1].
tldr; if you want better archival, support game labor, support projects that improve basic software infrastructure.
[1] https://en.wikipedia.org/wiki/Habitat_(video_game)#Revival
Everything you're talking about is a legitimate problem. I agree with you completely. However, source access helps with the majority of it -- even with making better emulators.
But even disregarding source code entirely, the game industry is also not particularly great at preserving final releases. If you're a big, popular title, sure, that'll probably be available. If you're a smaller title, or you saw a limited regional release, or you're a demo for an unreleased game, it's not a given in our industry that you actually do end up in vault somewhere. And that's the first step -- you can't run a game in an emulator unless you have the game to run.
The easiest question is, "do Sony, Microsoft, and Nintendo have an official archive where they preserve the release binaries of every single game that is released on any of their platforms?" The second easiest question is, "how about source code?" And then after that things start to get complicated and all of the concerns you're talking about come into focus.
In the film industry, there are cross-studio efforts to make sure that raw footage isn't lost. That's the result of prominent directors and studios taking the industry to task for many years, often after they had been personally bitten by film degradation. Nothing like that exists in the games industry. On the contrary, if you read over the comments on this article, you'll find multiple instances of devs arguing that preserving history is less important than shipping the next title, a kind of weird throwback to the same philosophy that led to old film studios destroying film reels from unsuccessful movies so they could be reused on the next project.
Of course, that's not a problem with Crash. It is, luckily, famous, so lots of copies exist. But apparently very few of the raw assets do. And it seems to me that if Sony can't even solve that problem, when Sony seems to have a clear financial incentive to solve it, they're not really in much of a position to start tackling MMO community preservation yet.
There's a problem with that argument, though. Sony et al have an incentive _now_ to want the content for older games. But it wasn't until much later that the idea of rereleasing games, much less archiving bits of them for future use, was a common thought.
I'm not arguing that the industry has gotten particularly better at that in the interim, just that there wasn't an incentive for it historically, and concluding that they can't do it when incentivized to doso doesn't follow.
* A lot of things "missed" is what further research proved to be "obvious" conclusions of exactly the groundwork laid by these games.
* Between 80h/week, personal life and the permanent question whether your game will sell at all, considerations what you should do in case your game becomes a cultural heritage are moot.
I have been part of this circus 15 years ago and while I definitely am proud of what I did, I do not think any lessons I learned are directly relevant today. Not only that, but I can not imagine to revisit my old code for any amount of money. Yes, my build system increased build speed by a factor of 200 over industry standards, but no, I am not going through those 2.5k loc gnu-make ever again. Or to even document the tricks we used to deliver a 80k jar, including assets.
A lot of the stuff was done to deal with hardware limitations that are irrelevant today. Why go through a lot of pain when the resources today are sufficient to play 100 instances of an unoptimized rewrite in an emulator?