|
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 release a game with readable source code, but if that was the only problem the games industry had with archival, I wouldn't honestly have much to complain about. The sort of second problem I have with this is the idea that flops aren't worth archiving. I want flopped games to be archivable. If you're a studio and you're saying, "we don't have time to worry about this", fine, that's your choice. What I'm advocating is that preserving history is important, not just for Mario, but also for games like ET. I want people in the future to be able to play your failed games. Of course caring about archival makes developing games harder, just like caring about accessibility does, and just like caring about framerate does, and just like caring about localization does. These are all different concerns that we try to balance, and widely the games industry has decided that archival is not a concern that it cares about balancing. |
But it was absolutely not written well from the standpoint of maintainability, abstraction, documentation, testability, etc. This is partly due to the insane time constraints we were under, partly due to the primitive nature of the development tools at the time, and partly due to the intrinsically low-abstraction methods required to achieve the necessary performance -- e.g., the entire renderer and collision detection system were written in MIPS assembly (by me).