id Software is a perfect​ example of the fact that you can open source your stuff once it has done market rounds and still be wildly successful and a household name. It helps that John Carmack himself was very principled about that sort of thing, not only contributing engines as open source projects but designing them specifically to be easy to modify and extend. The WAD is as responsible for the success of doom as source availability methinks. The saving grace of it all is that disassemblers exist, so with a little knowhow and a looooot of patience, any codebase can be opened, it just may not precisely represent what the original programmer put down. It's no secret that countless significant titles have gotten this treatment already too, heck, folks have even started producing 1:1 C decompiles of some N64 titles. So at least not all is lost, but there are of course things in source code that one will never find by disassembling a binary, and especially decompiling. There is zero guarantee you've got 1:1 procedures and code, just a 1:1 binary in the end. Who knows what tools people had in their pipeline performing optimizations and such. That said, console games of the 5th gen and back are the most likely candidates for this sort of forensic preservation as they tended to be bare metal or pretty darn close to it and ubiquitous vendor libraries have leaked for many of them, so part of the reversing would just be finding the various library blobs, labeling them, and then yanking them out to just leave the engine and in-house libraries. This is one heck of a subject drift though, trying to get better about that. Down to continue following this thread but no TUHS Cc please, at least to reply to me. - Matt G. ------- Original Message ------- On Thursday, January 26th, 2023 at 2:51 PM, Andy Kosela wrote: > On Thursday, January 26, 2023, segaloco via TUHS wrote: > >> We benefit from a general culture of openness surrounding UNIX these days. We see no such openness from Nintendo, Sega, Sony, nor Microsoft in their video game offerings, neither current nor former, and similar for publishers and studios for the most part. Anecdotally, when SquareEnix went to reissue Final Fantasy 8, they had to rewrite it from scratch as the original PS1 source code had been lost. Apparently this is a pretty common problem plaguing efforts to roll older titles forward to modern systems, and is one of the reasons shoddy emulation seems to win out over intentional ports of anything. >> >> UNIX experienced the rather unique phenomenon of being able to grow legs in academia for many years before some legal types tried to put the kibosh on that. Super Mario Bros. was a closed code base from day 1 with a tight deadline and little to no reason for it to be shared outside of its own development group. The circumstances are just so wildly different. UNIX is a bit of an anomaly as far as being an iconic, ubiquitous, still appreciated design that succeeds in academic *and* commercial spheres and also has ample source code and documentation history not only available but not constantly being torpedoed by lawyers. I don't know that we'll see a willingness to open up the history of video game development like that in a timeframe that sensitive source codes and documents could still be properly preserved. >> >> Plus, to the defense of these studios, some algorithm or technique developed for management of game resources may still be very much relevant to modern engine designs in ways that OS code from the 70s simply wouldn't even have a place in modern design. I wouldn't be surprised if there are scene graph and asset manager algorithms and such down in, say, the Zelda 64 engine, that the big N is *still* using in comparable engines and considers a trade secret. Hard to say. But anywho, just to draw some comparisons to the preservation state of UNIX vs other technological innovations. We have decades of quality OS code to study, research, and expand upon as hackers, but we have no such wealth of real video game source codes to educate the masses on game design, especially embedded console/bare metal approaches. This is where the crossroads lies for me between my UNIX and game development interests, I would LOVE some day for there to be as accessible and quality of resources for those studying the history of game design/development as there are for those studying OS design. After all, the way I describe old games to people in a technical sense is its just a specific type of OS. That programmer had to abstract all that hardware into concepts like button triggers movement of VDP scrollplanes and emission of commands to the FM synth chip. The thing you're using is just a Dpad instead of a mouse and you're moving a silly little character instead of a window across the screen. > > The closest I can think of in the game industry to the open source community of Unix/Linux is Doom/Quake. Doom source code was opened in 1997 and Quake in 1999 and since then we have experienced a whole generation of programmers and artists playing with, porting and enhancing the codebase. I don't know of any other game development project that has as much longevity as those two; and all of it happened because John Carmack made the decision to open source it based on the popularity of open source Linux at the time. > > --Andy