
A remaster with no old code: Crash Bandicoot was rebuilt nearly from scratch - Tomte
https://arstechnica.com/gaming/2017/06/a-remaster-with-no-old-code-crash-bandicoot-was-rebuilt-nearly-from-scratch/
======
danShumway
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 team here, because it must
have been a _huge_ amount of work, but even with that amount of work this
recreation ended up having problems with collision detection that changed the
entire feel of the game. I don't think that's because the devs are bad, but
just because the task they were trying to undertake was so unbelievably
impossible -- of course they missed stuff.

If you're in the games industry, please put some effort into preserving your
work for history. It does actually matter.

~~~
user3359
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 are still more or less viewable in
their original format today, but that's because things are designed that way.
Gaming platforms were more or less abandoned entirely and rewritten - I might
be wrong here but games from PlayStation 1 are not playable on PlayStation 4
are they?

~~~
danShumway
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 of a console specific hack -- well, is that hack
encapsulated? Is that hack mentioned anywhere in your internal documentation?
Do you _have_ internal documentation? I think you're mostly right that the
thought was, "why would we care about building a game that runs on PS2, we'll
just make a new game for that console."

You can do a lot with even really bad source code if the other stuff is good
-- if you still have uncompressed assets, or your build process isn't
completely reliant on some weird third-party proprietary dev kit. Bear in mind
that with this project, they didn't even have access to the source code, and
they had to manually decode 3D mesh data. So platform-specific logic was the
least of their problems.

I suspect that part of that is that the games industry is just really young.
And maybe some people were yelling about archival back then, but there weren't
any real tangible consequences. Now that remasters are a big thing, you've got
situations like this, where companies want to leverage old IPs and are
suddenly realizing that doing that is twice as complicated as it should be.

~~~
wild_preference
It just sounds like you underestimate the difficulty of building games and,
especially, overestimate the certainly that they will be successful.

It’s easy to preach how software should be written in the hindsight of a
successful project that you had zero stake in. I doubt the developers of games
that flop (so, most of them) wish they’d spent more time and money ensuring
their unwanted flop of a game was easier to archive.

~~~
danShumway
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.

~~~
dmbaggett
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 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).

~~~
techopoly
You wrote the Crash Bandicoot collision detection in MIPS? You deserve a
medal.

------
corysama
The only method I’ve seen work semi-reliably for archiving console game source
is to grab the physical machine that made the final build, spray paint “Do Not
Dispose! Build archive!” on its side and stick it in a back room. Even that
has a 2% chance/year to end up in a dump.

Otherwise, console game build systems were far to finicky to repro later (at
least up to the 360/PS3 generation). You would need a huge collection of
confidential tools from the manufacturer and those tools sometimes had
OS/driver/hardware dependencies that can be reproed reliably with a VM. Think
USB driver for the GameCube debugging connection. IIRC, the PS1 and N64
required add-in cards to connect a PC to them. Then there was the propriety
test disc/cartridge burners.

~~~
le-mark
All true, yet for PS1 there was the net yaroze dev system that was distributed
for some time. I actually had a copy at one point.

Seems inconcievable it wouldn't just been easier to use a software emulator
and the original data from the cd. But then I don't know if there is a good
software emu for the PS1?

[https://en.wikipedia.org/wiki/Net_Yaroze](https://en.wikipedia.org/wiki/Net_Yaroze)

~~~
motwera
It's likely that Vicarious Visions was unable to get the source code from
Naughty Dog due to Activision being unable to get it via Sony, though I'm not
100% sure about that since VV mentioned that majority of the original code is
virtually unusable in a blog post.

[https://blog.us.playstation.com/2016/12/03/crash-
bandicoot-n...](https://blog.us.playstation.com/2016/12/03/crash-bandicoot-n-
sane-trilogy-first-screens-in-depth-details/)

------
klodolph
This is buried in a comment but it's worth mentioning.

Naughty Dog used Lisp to write Crash Bandicoot. They had something they called
GOAL--Game Oriented Assembly Lisp. From what I understand, this was a DSL they
wrote so they could write assembly language using Lisp syntax, and call it
from Lisp functions.

[https://web.archive.org/web/20070127022728/http://lists.midn...](https://web.archive.org/web/20070127022728/http://lists.midnightryder.com:80/pipermail/sweng-
gamedev-midnightryder.com/2005-August/003804.html)

~~~
bitwize
"Any sufficiently complicated Lisp or Scheme program will eventually be
rewritten in C++, Java, or Python."

It's as true now as when I first said it in 2005-2006.

~~~
sova
Don't you mean that the other way around? "Any C++, Java, or Python, or
<insert your lang here> program will eventually be written in a Lisp-based DSL
that generates that language" ? Seems far more accurate to me than to claim
that all LISP functionality is derivable in (more rigid, less flexible)
language. What prompted you to say this in the first place? If LISP is the
mother language, of course all the rest are but a subset.

~~~
Illniyar
They rewrote Crash Bandicoot. It was originally written in lisp and is now
written,I'm guessing, not in Lisp.

The parent poster was factually correct.

Your statement while still holds true isn't the opposite of what the parent
said - you've replaced rewritten with written. If you said "Any C++, Java, or
Python, or <insert your lang here> program will eventually be _rewritten_ in a
Lisp-based DSL that generates that language"\- you would be factually wrong in
this account.

------
efrafa
Funny story about Crash: Everybody around 30 years old in Slovakia knows Crash
Bandicoot. In late 90s - early 00s there was a very popular TV show where you
could call in and play the game with your phone (basically just
left/right/jump) I spent hours watching it
[https://youtu.be/v3RYappcWZg](https://youtu.be/v3RYappcWZg)

~~~
chamakits
Oh wow this is cool.

Is this real?

Like even though the players die a good deal, it still feels like they can
play it pretty smoothly.

I’d love to know the system that got built out for this. I imagine it was
detecting tones, but would love any more insight into all of that. An rpg game
would have been a good way to overcome any timing issues games may introduce.

~~~
acct1771
Yeah, but then it's not exciting.

------
motwera
For those interested about the mesh level geometry, you can give the SDCC 2017
panel a watch.

[https://www.youtube.com/watch?v=UZAetHANJJ4](https://www.youtube.com/watch?v=UZAetHANJJ4)

[https://www.engadget.com/2017/07/03/crash-bandicoot-n-
sane-t...](https://www.engadget.com/2017/07/03/crash-bandicoot-n-sane-trilogy-
remake/)

------
acoye
They rebuilt a game in Unreal 4. So yeah from the ps1 era almost everything
had to be redone from scratch. I fail to see the problem here. Did player
expected them to package the optimized lisp virtual machine they had back then
in UE4?

~~~
jplayer01
> Did player expected them to package the optimized lisp virtual machine they
> had back then

Well, yeah? It's a remaster, not a remake. A remaster implies taking an
existing project and updating it. And it makes sense to keep the old game
logic - why write from scratch if you already have the whole game in a working
state?

~~~
motwera
It's a remake, not a remaster in the definition that you are thinking of.
Vicarious Visions did not use any of the code, likely to the fact that either
it was unusable or they did not ever have the source code.

N. Sane was done in Alchemy Engine, not Unreal Engine 4 (unlike Reignited),
although VV is likely following suit with their upcoming project.

------
kingbirdy
Interesting, wish it had more details though. Also, the title should include
(2017)

------
nicoburns
Obligatory link to this series on the making of the original (written by one
of the developers):

[https://all-things-andy-gavin.com/2011/02/02/making-crash-ba...](https://all-
things-andy-gavin.com/2011/02/02/making-crash-bandicoot-part-1/)

~~~
mmastrac
This was insanely interesting. Thanks for the link.

------
sotojuan
So was Kingdom Hearts. FFVI Steam and PS4 versions had to be made from the
original PC version by Eidos since the PSOne original's source is lost.

