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…
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?
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.
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. :)
I don’t know about other developers at the time, but we had quite a lot of hand-written assembly code in the Crash games. The background and foreground renderers were all written in assembly by hand, as was the octree-based collision detection system. (Source: me; I wrote them.)
And this thread comes full circle: Mark Cerny actually significantly improved the performance of my original version of the Crash collision detection R3000 code. His work on this code finally made it fast enough, so it’s a really good thing he was around to help out. Getting the collision detection code correct and fast enough took over 9 months —- it was very difficult on the PS1 hardware, and ended up requiring use of the weird 2K static RAM scratchpad Sony including in place of the (removed) floating point unit.
GOOL was mainly used for creature control logic and other stuff that didn’t have to be optimized so much to be feasible. Being able to use a lisp dialect for a bunch of the code in the game saved us a ton of time. The modern analogue would be writing most of the code in Python but incorporating C extensions when necessary for performance.
Andy made GOAL (the successor lisp to GOOL) much more low-level, and it indeed allowed coding essentially at the assembly level (albeit with lispy syntax). But GOOL wasn’t like this.
I've never seen the Crash source code, so was making my statements based on second hand knowledge. So thanks for that clarification. I do think it's worth pointing out that Naughty Dog and Insomnia were two companies well known for making highly optimized software for the PSX; so probably not a standard most other companies matched.
Additionally, I have written my own PSX software as well as reviewed plenty of contemporaneous PSX software. While many have some bit of assembler, it's usually specifically around the graphics pipeline. About 90+% of all code is C. This is in line with interviews from developers at the time, as well.
The point wasn't that ASM wasn't used at all (in fact, I specifically acknowledged it in my original post), it was that the PSX was in an era passed the time when entire codebases were hand massaged/tuned assembler (e.g. "the 16-bit era" and before).
Many years ago (circa 1993) I ported the original Colossal Cave adventure by Crowther and Woods to TADS, a language created by Mike Roberts specifically for authoring text adventures. (Colossal Cave just came up recently here.)
Graham Nelson ported my port to his Inform language, and Inform is probably your best choice if what you actually want to do is write a (plain text) adventure game.
If you want to learn C programming, writing a text adventure in C would be a fun learning project! But aside from pedagogy there’s no real reason to write a text adventure in anything other than Inform, TADS, etc. Not only is it much easier to use one of these purpose-built languages, with Inform you get multi-platform compatibility going back to the 8-bit era for free!
Personally if I had any free time, I’d be more interested in looking at how to use a frontier LLM like llama as an integral part of a text adventure. There was something like this using GPT-2 circulating on here a while back, but it was pretty rough.
However, it’s clear that if you figured out how to precisely control the LLM so it didn’t produce crazy stuff, you could realize the dream of truly realistic NPCs in these games. Text adventures would seem to be a perfect laboratory for experimenting with this.
cave is the first game i remember feeling immersed in. it was so good. its awesome you ported it!
Im playing with an LLM to remake drug wars. i pretty quickly changed it to more of a spiritual successor because i wanted to add more features and then had a hard time with them and the drug mechanic so i switched to financial trading and that made more sense. the i changed it to crypto coins in a dystopian future instead of stocks cuz the ascii art needed some lore to help flavor it now that gritty drugs were out
with Puny Inform6 or limiting Inform6, yes. If not, it's suicidal, even for v3 games.
But, from Amiga and Atari machines, most v5 and v8 games if not all will run great.
You would probably do better on 8-bits by using ZIL which is actually feasible these days thanks to ZILF (and the leaked ZIL source code of the original Infocom games to look at).
I wrote StoryHarp for creating speech-interactive choose-your-own text adventures back around 1998 (in Delphi for Windows desktop), and ported it to the web about seven years ago (with some limitations) using TypeScript and Tachyons: https://storyharp.com/v3.0
Realistically, StoryHarp might be most fun to use as an authoring tools for kids making short idiosyncratic adventures to share with friends. StoryHarp could help people practice creative writing and learn just a bit of logic to set up puzzles (without getting bogged down in more computing complexity like writing C code or even just the conceptual demands of TADS or Inform, as amazing as those tools are).
I recently added a option (inspired by "flems.io") where you can create a StoryHarp link that includes the entire world definition in the hash. For example, here is a URL for a game that just says "You are visiting the Hacker News website" when you click "look":
https://storyharp.com/v3.0/#world=N4Ig7g9gTgNgJgMQJYwKYDkCGB...
Otherwise the game stores data only in the browser (not the server) which can be exported or imported as files.
While I can see how LLMs might make for more realistic interactions with text adventures, writing text adventures is its own sort of puzzle (like coding programs manually), and I am not sure adding LLMs will really make creating such adventures a much more joyful experience. But maybe it could. I agree in general though that text adventures make a great playground for experimenting with new ideas (as with StoryHarp as an experiment in bringing browser ideas from Smalltalk into interactive fiction design).
Anyway, that is the sort of idiosyncratic short experiential interactive fiction I am talking about. Just spend five or ten minutes and make something that captures an emotion or a theme or a concern or an moral conundrum or whatever.
It depends on when you do the query. Years ago (mid 2000s) at ITA, Carl wrote code to find the longest possible shortest route between any two airports with scheduled flights. At the time the winner was Wasu, New Guinea to Peawanuck, Ontario, which took a minimum of 90 hours and many flights. There are airports you can only get to at the end of a long line of stops; this drives the number of stops way up.
Ditto with the N64. I think there's a WIP backport of Super Mario 64 for Irix 6 by reusing the decomp and the PC source port. The PC one can run under GL 1.3 and GLIDE, nothing fancy.
However, interpreting this data properly is decidedly nontrivial (>1M LoC).
Pricing does not imply booking is OK, though. And even circa 1999, Southwest hassled us (ITA Software) about even showing their fares, without us offering any way to book any flights on any carrier.
Full disclosure: I worked with Andy on Crash and am an angel investor. If you’re interested in AI and gaming I recommend you reach out. This is an extraordinary team and opportunity.
Yes, for Crash Bandicoot we had to entirely skip the C SDK for everything performance-critical; pushing arguments onto the stack and the SDK popping them off for each function call used more cycles than the underlying operation in many of these SDK calls.
Sony explicitly forbade this, presumably because they envisioned the API established by the C SDK as a way to ensure future backward-compatibility. We just ignored the rules and hoped the superior performance we could achieve would overcome any bureaucratic obstacles.
We also had to reverse engineer some of the PS1’s really nice capabilities. I only learned the hardware supported vector pipelining for strip rendering by noticing the coordinate values move from one register set to the next in the debugger.
Seeing that was a revelation: when rendering a polygonal mesh, you naively have to project three coordinates for each triangle. But if you convert your mesh into sequences of polygonal strips where each triangle shares an edge with the next triangle in the mesh, you only need to project a single additional vertex for each additional polygon in the strip. Observing the behavior in the debugger, it was obvious to me that the Sony hardware had in fact been optimized for this approach. But not only were we not given any documentation on this, we were instead told to use the C SDK, which didn’t expose this capability at all.
The PS1 also had 2KB of “scratchpad” that was slower than registers but much faster than RAM. Hearsay was this was a way for the CPU designers to make use of the physical space on the die meant for floating point instructions which the MIPS CPU in the PS1 didn’t have.
I used the scratchpad to store projected 2D “stamps” of the 3D world (stored in an octree) and Crash: a kind of low-res Crash Flatland. I could then check for X/Y collisions between Crash and the world very rapidly by inspecting the flatland bitmap stored in the 2K scratchpad. This was Mark Cerny’s idea; he was our producer on the Crash games and has also been responsible for PS2 through PS5 hardware.
Hey I just wanted to chime in and say that I spent a lot of time in my infancy/youth playing crash bandicoot, thank you very much.
Also, i’ve seen many videos on YouTube about all the crazy things you had to do to make stuff work. And every time i get to read some additional detail it’s always super intriguing…
Have you considered doing something like a documentary? Like, a series of long form videos on the topic? With interviews to people involved etc?
Hopefully you’ve read the Polygon article and seen the videos with Andy Gavin talking about the underlying tech. I was going to do part two of the video series but COVID killed it. Maybe we’ll revive that; it would be fun.
