41–50 of 80 posts
Earlier quoted context omitted.
Not really. The GOOL code was used for character logic and things like the load/save screen. The majority of the code was written in C and MIPS assembly.
It was used for all of the gameplay code. The C and ASM were just the engine level primitives. On the systems I've seen, the gameplay code can outnumber engine code 5 to 1.
Earlier quoted context omitted.
I would think the lesson from this is, "don't build an in-house custom Lisp variant for all of your games unless you're willing to distribute the documentation, compiler, and dev tools with your source code."
If it's intrinsically doing any code modification (which as I understand it does in order to dynamically load and link code), even with all of that they might be up shit creek. Some of these platforms don't allow anyone, even the kernel, to make pages executable without providing signatures.
Earlier quoted context omitted.
Fun fact, when Metal Gear Solid (1) was ported to PC, the work was done by a handful of people, and they didn't have access to the original resources so they found some of them on fan websites. Some of the audio files used in the release are 30 second loops of much longer pieces of music from the original game.
Huh, that's weird. PS1 assets were remarkably transparent. Generally the audio was just CD-A tracks or ADPCM files, and the rest of the data was a ISO-9660 filesystem that showed up when you stuck the disc in a computer.
The games industry is so stinking bad at archival that it hurts. Very little consideration is paid to using architectures and build tools that can be replicated later. Source code becomes unavailable (as was the case here). Game logic is written using highly platform-specific code that's difficult to emulate. Source textures and other raw resources get thrown out. And not to diminish from the accomplishment of the te…
* 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?
The games industry is so stinking bad at archival that it hurts. Very little consideration is paid to using architectures and build tools that can be replicated later. Source code becomes unavailable (as was the case here). Game logic is written using highly platform-specific code that's difficult to emulate. Source textures and other raw resources get thrown out. And not to diminish from the accomplishment of the te…
IIRC from developer stories from this era, things had to be done "creatively" to save space, and ensure optimal runtime execution. Certain platforms may well have had undocumented bugs and platform-specific optimizations that you simply had to adapt to. Archiving wasn't a consideration - launching a playable game that would pay the salaries and lead to future projects was. We take for granted that websites but in 95…
Earlier quoted context omitted.
Architecture is the last step in this process. The low hanging fruit is "do you still have your source code and original assets? Is any of it documented?" Nobody will ever know if the original code for Crash Bandicoot was written well or not, because in all likelyhood nobody has it anymore. And I don't think you can chock that up to, "well, developing games is hard." We can debate whether or not it's possible to rele…
Well I know, because I wrote (approximately) half of it. :) It was written well in that it was a technically innovative and beautiful game that pushed the boundaries of the PS1 hardware. It was written well in that the shipped code didn't crash or have horrible show-stopping problems. (This was important because there were no streamed patches back in the days of physical media.) But it was absolutely not written well…
The games industry is so stinking bad at archival that it hurts. Very little consideration is paid to using architectures and build tools that can be replicated later. Source code becomes unavailable (as was the case here). Game logic is written using highly platform-specific code that's difficult to emulate. Source textures and other raw resources get thrown out. And not to diminish from the accomplishment of the te…
Let me hand you some binoculars, it might be hard to see the details from the vantage point of giants' shoulders: * 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 heri…
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.
The games industry is so stinking bad at archival that it hurts. Very little consideration is paid to using architectures and build tools that can be replicated later. Source code becomes unavailable (as was the case here). Game logic is written using highly platform-specific code that's difficult to emulate. Source textures and other raw resources get thrown out. And not to diminish from the accomplishment of the te…
Earlier quoted context omitted.
IIRC from developer stories from this era, things had to be done "creatively" to save space, and ensure optimal runtime execution. Certain platforms may well have had undocumented bugs and platform-specific optimizations that you simply had to adapt to. Archiving wasn't a consideration - launching a playable game that would pay the salaries and lead to future projects was. We take for granted that websites but in 95…
Yes and no. I don't really have a justification for saying this because I was never working in that environment, but I don't think the industry spent enough time thinking about how their games would be played in the future and I suspect that a lot of the "well, the platforms required us to do this" is an excuse. Yes, there are platform-specific quirks and bugs and stuff to work around, but say you're taking advantage…
And ignoring archival happened before in another young industry. The majority of silent films are lost. From Wikipedia: "Martin Scorsese's Film Foundation estimates that more than 90% of American films made before 1929 are lost, and the Library of Congress estimates that 75% of all silent films are lost forever." I don't think it's surprising that the game industry acts the same way.
Earlier quoted context omitted.
If it's intrinsically doing any code modification (which as I understand it does in order to dynamically load and link code), even with all of that they might be up shit creek. Some of these platforms don't allow anyone, even the kernel, to make pages executable without providing signatures.
Well, if your platform can't support implementation of typical Lisp/dynamic idioms, then it's frankly a shit platform and doesn't deserve to be called "general-purpose computer".