[HN Gopher] Making Crash Bandicoot (2011)
___________________________________________________________________
Making Crash Bandicoot (2011)
Author : davikr
Score : 236 points
Date : 2025-11-25 12:05 UTC (1 days ago)
(HTM) web link (all-things-andy-gavin.com)
(TXT) w3m dump (all-things-andy-gavin.com)
| chollida1 wrote:
| Oh man, this has been posted probably 100 times now but this is
| still a great blog.
|
| I guess today another 10,000 people will learn about how crash
| bandicoot was made.
|
| https://xkcd.com/1053/
|
| I was in video game development at the time and it was really
| exciting due to the switch from 2D to 3D for most games which
| made the math a programmer was required to know go way up in
| complexity.
|
| And you hade new things called graphics cards that had their own
| apis to program to and drivers that didn't always do what they
| were supposed to do so you were always feeling around in the dark
| a bit when working with a new console or new graphics card. I
| remember so many bugs that weren't necessarily our fault, but the
| fault of buggy drivers or a misimplemened OpenGL call by the
| driver or console provider.
|
| I couldn't imagine layering on top of that a lisp dialog to
| program your game in given that we were doing incredible things
| to shave off milliseconds. It seems counter intuitive to put a
| high level interpreted language ontop of that but these geniuses
| pulled it off!!
| _kb wrote:
| There was a great conversation with Matt Godbolt on CoRecursive
| recently [1]. It was a bit of a dive into how some of those
| abstractions are a lie and, particularly in early game dev, how
| you can create magic by realising that then exploit how the
| hardware actually works. Highly recommend a listen.
|
| [1]: https://corecursive.com/godbolt-rule-matt-godbolt/
| socalgal2 wrote:
| The dialect of lisp used in those games is not interpreted
| monocasa wrote:
| The version in crash 1 is fully interpreted, and subsequent
| crash games only compiled a few very hot path expressions.
|
| The full compiler came later with GOAL.
| kazinator wrote:
| Crash Bandicoot used a Lisp meta-language called GOOL which
| translated to assembly for the game target. The translator was
| in Common Lisp, runnng on development/build machines not on the
| target (and and itself would have almost certainly been
| compiled, not interpreted).
| monocasa wrote:
| Well, the first crash interpreterd GOOL, and the subsequent
| ones only compiled some common expressions.
|
| A full compiler for the target came with GOAL in Jak &
| Daxter.
| chollida1 wrote:
| > Crash Bandicoot used a Lisp meta-language called GOOL which
| translated to assembly for the game target.
|
| This is incorrect but I see someone else already corrected
| you. It wasn't until later on that they created assembly
| compilation.
| tomhow wrote:
| For those not aware:
|
| One of the developers of Crash Bandicoot, Dave Baggett, is a
| longtime HN contributor:
| https://news.ycombinator.com/user?id=dmbaggett.
|
| It was his royalties from Crash Bandicoot that enabled him to co-
| found/angel-invest in ITA Software, the flight search platform
| that Google acquired to be the foundation for Google Flights.
|
| https://mixergy.com/interviews/david-baggett-ita-software-in...
| joecool1029 wrote:
| Posts tagged with Dave on this blog: https://all-things-andy-
| gavin.com/tag/dave-baggett/
| leviathant wrote:
| I was taking to a woman at a party a couple of years ago (an
| event related to a choir composition that my wife had done), and
| at some point she mentioned her son was a developer, specifically
| that he made video games. When I asked if she knew which games he
| worked on, she said Crash Bandicoot and suddenly I felt like I
| was talking to Ned royalty. I gushed a bit about what I had read
| on this blog post, but kept the conversation going so as not to
| dwell on it.
| amypetrik8 wrote:
| I am personal friends with Ned "The King" Royalty and
| appreciate Ned's contributions to games such as Crash bandicot
| jihadjihad wrote:
| A little tangential/OT, but one of the things I admire about Andy
| Gavin and the Naughty Dog team is that they were capable of doing
| things on a brand new system that few ever figured out how to do.
|
| Usually when a new system/console comes out it takes a while for
| developers to get used to its quirks and figure out optimizations
| and hacks to eke out whatever little performance gains you can
| under the constraints of the hardware.
|
| One of the first games for the PS2 was _Jak and Daxter: The
| Precursor Legacy_ , developed by Naughty Dog. What is remarkable
| is that Gavin had figured out that a lot of the assets and
| textures etc. that needed to be available in order to start the
| game could be loaded while the typical splash screens were
| displayed at the beginning.
|
| I never noticed it when I played the game years ago, but I picked
| it up a while back and had a "wait, what?" moment when the PRESS
| START button appears, and _instantly upon pressing it_ you 're
| launched into the game and can interact with the world. No
| loading screen, no cutscene, just straight into the game.
|
| Anyway, mad respect for a small team that managed to produce some
| of the most beloved games from that era.
| Jare wrote:
| Jak and Daxter is as legendary for its charm and tech as it was
| for its crazy tricks. The one I cherish the most is how if Jak
| was running to the next zone before streaming had completed
| loading it, Jak would just trip and fall for no apparent reason
| to the player.
| DavidPiper wrote:
| Oh my God is THAT why he would randomly trip over sometimes??
| I spent a small but non-trivial amount of time trying to
| figure out how to do it again when I was younger.
|
| Thank you, you answered a 20-year-old question I didn't even
| remember I had until now.
| Jare wrote:
| I remember laughing so hard at this, during their GDC
| lecture about Jak's tech. I haven't verified it but I
| suspect it's this one
| https://gdcvault.com/play/1022734/The-Technology-of-Jak-
| Daxt...
| jlawson wrote:
| This trick was used by later games as well. It was pretty
| funny in Batman: Arkham Asylum to see Batman faceplant while
| walking down a hallway.
| rahen wrote:
| Part 9 elaborates on GOOL, the Lisp dialect they designed in-
| house to create the gameplay.
|
| This is my favorite part: https://all-things-andy-
| gavin.com/2011/03/12/making-crash-ba...
| busfahrer wrote:
| One of the interesting points to me from reading this (or
| something similar about CB) the last time was this:
|
| The PSX had no real 3D capability, you could just throw a list of
| triangles at it to draw. The problem here is that you have to
| sort the list of triangles yourself, since there is no such thing
| as a z-buffer.
|
| For Crash Bandicoot, since the path is essentially linear, they
| were able to pre-sort most of the triangles at build time, which
| allowed them to achieve greater visual fidelity compared to
| contemporary titles that allowed for freer movement.
| corysama wrote:
| Note that the pre-sorting wasn't just for drawing. It was for
| loading as well. The PS1 only had 2MB of RAM and a 2X CD-ROM
| with a seek time of a 1/4 second or more depending on the
| distance traveled by the drive head. So, straight-line physical
| layout of data to be loaded throughout the level was critical.
| toast0 wrote:
| Rail shooters in the early CD era made pretty impressive
| visuals by layering real time sprites or whatever rendering
| was available on top of FMV from the disc. When it was done
| well, it looks and plays great (as long as your CD isn't
| scratched!). Silpheed on Sega CD is a prime example of what
| can be done.
| dmbaggett wrote:
| Sort of. While it was helpful to have the delta-compressed
| polygon list for each part of the level in its own 64KB
| chunk, the minor miracle of fitting >10MB levels into 2MB of
| RAM (half of which was VRAM as I recall) was down to two
| things: 1) Andy wrote this insane dynamic layout/loader thing
| that optimized the CD's bandwidth (which was of course
| pathetic by today's standards, as you point out); 2) I wrote
| a tool that packed the chunks into pages so that we never
| needed too many active at any given point in the level. This
| is an NP-Complete problem and we didn't have solvers back
| then so the tool just tried a bunch of heuristics, including
| a stochastic one (think early simulated annealing). The
| problem with the latter was that if you "got lucky" you might
| never achieve the required packing again after the artist
| changed a turtle or something...
| monocasa wrote:
| > 2MB of RAM (half of which was VRAM as I recall)
|
| Separate 2MB of main ram and 1MB of VRAM for 3MB total.
| dmbaggett wrote:
| Thank you. Too many startups ago. :)
| djmips wrote:
| How long did it take you guys to write the dynamic
| layout/loader and packer? How long did it take to run it on
| a level when an artist changed a turtle or something?
| dmbaggett wrote:
| I don't know how much time Andy spent building the "poor
| man's VM" system, but I know it was a significant effort
| that underpinned the rest of the game. The packer was
| something I probably put a few days into in the beginning
| (greedy and other trivial heuristics) and then kept
| improving in my "spare time" over the next year or so.
|
| The packer was the final step after a level was pre-
| sorted and otherwise processed. It was quite fast, so it
| added only a little bit of extra time to the primary work
| of pre-rendering every frame of the level to recover the
| sort order (which typically took around an hour).
|
| I did experiment with solver algorithms but they were so
| obviously going to be too slow that I abandoned the idea.
| dmbaggett wrote:
| Exactly right! I had been working on a prototype for a Doom-
| style game in the summer of 1994 for the 3DO and built out the
| beginnings of the "sort polygons AOT" concept. While the idea
| was conceptually simple, the details were a bear. I guessed
| that using keyframes with the entire polygon list plus deltas
| would "just work out" and fit in the limited storage and
| computational budget of the PS1... and I was very relived when
| it was clear my intuition was right. (Otherwise we would have
| needed to redo the entire game engine.)
|
| Another challenge was dealing with foreground objects: you have
| to somehow sort these into the pre-sorted background polygons.
| This mostly worked with bucket sorting but we had to use the
| gross hack of allowing each foreground object to have tunable
| "push-back" to fix sorting glitches. This required manual work
| for each level.
|
| Finally, while precomputing the per-frame sort order for a game
| like Crash would be trivial now, in 1995 we had to build our
| own Beowulf cluster thingy and farm the level precompute out in
| pieces to the artists' SGI workstations, and levels typically
| took an hour to process. The artists LOVED that. :)
| danbolt wrote:
| The Nintendo 64 has a z-buffer, but the slow fillrate means
| that depth-checking can hamper your frame time. _World Driver
| Championship_ sorted their polygons PS1-style with unique
| microcode, and got a very nice framerate.
|
| I sometimes wonder what the Nintendo 64's library would have
| been like if they had sorted polygons on the CPU like other
| consoles of the era.
| theturtlemoves wrote:
| Crash Bandicoot, loved that game! Especially the levels where you
| had to run backwards, those were amazing fun
| doubled112 wrote:
| I've always hated running to the left and running toward the
| screen in games.
|
| Neither feel natural but perhaps it is only because it is not
| what I am used to.
| theturtlemoves wrote:
| I didn't say it felt natural haha. It was so incredibly
| difficult. But I was, what, ten, twelve? I fell into those
| holes so often but I kept going at it until I could run those
| levels. Difficult, yes, unnatural, yes, but also very
| satisfying to master (in the context of being that young, I
| never managed to get a full score or get all the gems and
| whatnot, so it wasn't exactly mastery, but I could eventually
| get through the level. Good times)
| sillywalk wrote:
| Related / Past discussions:
|
| https://news.ycombinator.com/item?id=9737156
|
| ( How Naughty Dog Fit Crash Bandicoot into 2MB of RAM on the PS1)
| 934 points|ekianjo|10 years ago|247 comments
|
| https://news.ycombinator.com/item?id=32663433
|
| How Crash Bandicoot hacked the original Playstation (2020)
|
| 325 points|agomez314|3 years ago|71 comments
|
| Crash Bandicoot: An oral history
| https://www.polygon.com/2017/6/22/15820540/crash-bandicoot-a...
|
| https://news.ycombinator.com/item?id=14613982
|
| 152 points|Tomte|8 years ago|40 comments
| ElCapitanMarkla wrote:
| Guess it's time for my annual reading of Andy's Crash blog :D
| ebbi wrote:
| I've never come across this site before, but I remember watching
| a video on YouTube and one of the creators was talking about
| making Crash Bandicoot. As someone non-technical, but who grew up
| playing Crash Bandicoot, it gave me insight into the crazy amount
| of work that goes into making a game, but also just how much of a
| genius these people were that tried to push the limits of what
| the early gen consoles could do!
| jonny_eh wrote:
| https://www.youtube.com/watch?v=izxXGuVL21o
| ebbi wrote:
| That's the one! Thanks for sharing :)
| bsimpson wrote:
| If you'd prefer to watch a video, the author was interviewed on
| YouTube 5y ago:
|
| https://www.youtube.com/watch?v=izxXGuVL21o
|
| I thought that video included one of my favorite programming
| legends, and apparently a bunch of people on Reddit remembered
| that too. Instead, it was published on Gamasutra about a "late
| 90s PC title." Still very worth the quick read:
|
| https://www.gamedeveloper.com/programming/dirty-coding-trick...
| djmips wrote:
| We used to do that back in the eighties. We likened it to
| working out with weights or saving for a rainy day. Keeping
| some memory preallocated so that when you really needed it
| during the final push, you'd have some on hand.
| imjacobclark wrote:
| Now I need to grab my PS1 from the attic and give this a play!
| lastdong wrote:
| "Hitting the hardware directly was against the rules. But by the
| time Sony saw the results they needed a Mario killer. It was too
| late for them to complain."
|
| Great read!
___________________________________________________________________
(page generated 2025-11-26 23:02 UTC)