3 ms·

Did he still have access to the source?

tombert 5y ago
I think he must, because on his YouTube channel he'll show different development iterations and "what if" scenarios throughout the games he has worked on. I suspect that he cannot legally release the code, so he had to do the Director's Cut as a ROMHack where you supply your own copy.
laumars 5y ago
Everyone does because most games back then were written in assembly so the raw code is there on the ROM. Games written in C slow in comparison, as seen with Sonic Spinball, so I’d wager Sonic 3D would have had to be assembly too given the technical achievements involved in that game. There’s some YouTube videos from various developers of that era and you can see them stepping through the assembly of those games too.
- mrob 5y ago
  A disassembly of the ROM is not the same as the source code because it's missing the human-readable labels for memory addresses. It's more like the source code after using an obfuscator to remove variable and function names.
  - deleted 5y ago
    [deleted]
  - laumars 5y ago
    Technically yes. But it’s still usable on a platform like the Mega Drive / Genesis and it’s how ROM hackers would generally work. They might still have the original code though given they wrote the game. But I wouldn’t be at all surprised if they just worked off the ROM instead.
- Jetrel 5y ago
  I was really surprised to discover that quite a few games in the SNES/Genesis era actually weren't written in assembly. They were usually "touched up" in assembly; there would be inlined assembly stuff for a lot of core loops and hardware interaction, but apparently quite a few games actually used "high level languages" for large tracts of the code. I'm merely relating hearsay here, but at least one primary source (Secret of Evermore) suggested this was the case. The thing is that once it's compiled down to a final rom, all the scaffolding used to build it is gone, so there's so little evidence left that it's pretty plausible for people to think it was just done completely in assembly (particularly since there's significant evidence of hand-crafted assembly routines in such a product, since they did that for parts of it). I think there's a lot of "transposing of knowledge" there, where people know how 8-bit games got built, and assume it was the same for the 16-bit era, but I suspect the 16-bit era was where the transition away from that started, so there was a bit of both.
  - laumars 5y ago
    As I said, C code did exist but it was slower so it wasn’t the norm. I don’t know of any other languages being used on those systems (I think C++ was supported on the following generation of consoles, albeit SDKs took longer to be released on some consoles than others). If anyone knows of non-C languages being used I’d love to hear about it. Back then compilers weren’t as good at writing optimised machine code as they are now and the consoles of that era were built with assembly in mind anyway so it was an easier job writing assembly for them than it would be on modern architectures. That all said, it seems to be a lot more common these days (ie with the homebrew community) to use higher level languages even on easier platforms like the GameBoy.
    - ndiddy 5y ago
      The Koei strategy games on NES ran in a bytecode virtual machine. The actual game program would be written in C and compiled to the virtual machine. This allowed them to use the same codebase as the computer versions of their strategy games. As for why they use a VM rather than compiling to 6502, my guess is it saved ROM space (for example a 16 bit memory + memory add would be one instruction instead of 7) More information: https://forums.nesdev.org/viewtopic.php?f=2&t=15931 https://forums.nesdev.org/viewtopic.php?f=2&t=15931
- kingcharles 5y ago
  Having the machine code from the ROM isn't the same as having the original assembler files, even if it's close. I would over-comment my assembler just because it is an order of magnitude harder to scan over than C code. You also lose all the labels on your subroutines and jmps, all your variable names, all your data block labels.
  - laumars 5y ago
    Another commenter made the same post and my reply to that is here: https://news.ycombinator.com/item?id=29815491 https://news.ycombinator.com/item?id=29815491
joneholland 5y ago
The guy is actually the cofounder of the studio that wrote the game (Travelers tales)
- jonny_eh 5y ago
  I know, but that doesn't mean he was allowed to leave the company with source code.
- kingcharles 5y ago
  Video game source code is very poorly archived, from experience in the industry. Ask practically anyone who worked on any games pre-2000 and I bet they can't find the source for any of their games.

I think he must, because on his YouTube channel he'll show different development iterations and "what if" scenarios throughout the games he has worked on. I suspect that he cannot legally release the code, so he had to do the Director's Cut as a ROMHack where you supply your own copy.

laumars 5y ago

Everyone does because most games back then were written in assembly so the raw code is there on the ROM. Games written in C slow in comparison, as seen with Sonic Spinball, so I’d wager Sonic 3D would have had to be assembly too given the technical achievements involved in that game. There’s some YouTube videos from various developers of that era and you can see them stepping through the assembly of those games too.

mrob 5y ago
A disassembly of the ROM is not the same as the source code because it's missing the human-readable labels for memory addresses. It's more like the source code after using an obfuscator to remove variable and function names.
- deleted 5y ago
  [deleted]
- laumars 5y ago
  Technically yes. But it’s still usable on a platform like the Mega Drive / Genesis and it’s how ROM hackers would generally work. They might still have the original code though given they wrote the game. But I wouldn’t be at all surprised if they just worked off the ROM instead.
Jetrel 5y ago
I was really surprised to discover that quite a few games in the SNES/Genesis era actually weren't written in assembly. They were usually "touched up" in assembly; there would be inlined assembly stuff for a lot of core loops and hardware interaction, but apparently quite a few games actually used "high level languages" for large tracts of the code. I'm merely relating hearsay here, but at least one primary source (Secret of Evermore) suggested this was the case. The thing is that once it's compiled down to a final rom, all the scaffolding used to build it is gone, so there's so little evidence left that it's pretty plausible for people to think it was just done completely in assembly (particularly since there's significant evidence of hand-crafted assembly routines in such a product, since they did that for parts of it). I think there's a lot of "transposing of knowledge" there, where people know how 8-bit games got built, and assume it was the same for the 16-bit era, but I suspect the 16-bit era was where the transition away from that started, so there was a bit of both.
- laumars 5y ago
  As I said, C code did exist but it was slower so it wasn’t the norm. I don’t know of any other languages being used on those systems (I think C++ was supported on the following generation of consoles, albeit SDKs took longer to be released on some consoles than others). If anyone knows of non-C languages being used I’d love to hear about it. Back then compilers weren’t as good at writing optimised machine code as they are now and the consoles of that era were built with assembly in mind anyway so it was an easier job writing assembly for them than it would be on modern architectures. That all said, it seems to be a lot more common these days (ie with the homebrew community) to use higher level languages even on easier platforms like the GameBoy.
  - ndiddy 5y ago
    The Koei strategy games on NES ran in a bytecode virtual machine. The actual game program would be written in C and compiled to the virtual machine. This allowed them to use the same codebase as the computer versions of their strategy games. As for why they use a VM rather than compiling to 6502, my guess is it saved ROM space (for example a 16 bit memory + memory add would be one instruction instead of 7) More information: https://forums.nesdev.org/viewtopic.php?f=2&t=15931 https://forums.nesdev.org/viewtopic.php?f=2&t=15931
kingcharles 5y ago
Having the machine code from the ROM isn't the same as having the original assembler files, even if it's close. I would over-comment my assembler just because it is an order of magnitude harder to scan over than C code. You also lose all the labels on your subroutines and jmps, all your variable names, all your data block labels.
- laumars 5y ago
  Another commenter made the same post and my reply to that is here: https://news.ycombinator.com/item?id=29815491 https://news.ycombinator.com/item?id=29815491

joneholland 5y ago

The guy is actually the cofounder of the studio that wrote the game (Travelers tales)

jonny_eh 5y ago
I know, but that doesn't mean he was allowed to leave the company with source code.
kingcharles 5y ago
Video game source code is very poorly archived, from experience in the industry. Ask practically anyone who worked on any games pre-2000 and I bet they can't find the source for any of their games.