Anybody who did PS1 dev back in the day will have had to do some crazy hacking stuff to get performance or memory. The first project [1] I worked on I had a C version of my graphics engine and animation system, and in parallel I'd have a MIPS assembly version which was super optimised (the C version was effectively a reference).
I made the whole engine and animation system fit in 4K so it would fit into the instruction cache of the CPU. The whole frame update cycle wouldn't need to touch main memory (for the code).
Also, because loading from main memory was slow (4 cycles) and the chip was RISC (1 operation per cycle), you'd need 3 NOPs after the Load-op for the register to be loaded. The C compiler (if I remember right) never really filled those 3 NOPs with useful stuff. So, I'd do hand written concurrency (in MIPS assembly) by loading other stuff I'd need into those NOPs - this was particularly effective when working with 3 dimensional vectors or 4 dimensional matrices.
Trying to keep super-optimised hand-written concurrency in assembly, in my head, was a challenge and not something I'd recommend! Still, the engine had more throughput than Sony claimed of their machine. Every bit of performance gained would mean an edge over the other games.
Then the game was canned by Eidos. Pretty devastating for my first industry job :/
My first “tech job” was supporting DOS games at EA in the late 90s. Post windows 95 they still had some bargain flight sims that seemed popular. I can’t remember the exact numbers but one of the sims checked for sufficient RAM. I think you needed 16MB but there was a bug where if you had more than like 512 it would think you didn’t have enough (pre-internet so no real patches). The “fix” was a “boot disk” (on a floppy) that would create a RAM drive to partition off some of your RAM getting your available total under 512. RAM had just started to get “cheap” enough that some folks had 1GB and we were able to use the RAM drive (which worked like a physical HD) to install the game and play it from RAM instead of the old slow spinning disks.
But yeah memory hacks in those days were rampant.
Side note the most common problem for the PS support queue was PlayStations not reading disks properly. The fix was to turn the machine on its side or even upside down to get the CD closer to the laser.
>Side note the most common problem for the PS support queue was PlayStations not reading disks properly.
I laughed when I read the following quote from Andy Gavin's blog, now I'm crying after seeing yours.
"Kelly asked how many of these CD hits Andy thought a gamer that finished Crash would have. Andy did some thinking and off the top of his head said “Roughly 120,000.” Kelly became very silent for a moment and then quietly mumbled “the PlayStation CD drive is ‘rated’ for 70,000.”
>The fix was to turn the machine on its side or even upside down to get the CD closer to the laser.
Was this the precedent for marketing the PS2 vertically?
Afaik putting PSX on a side fixed the issue of worn out plastic slider/sled. Early laser beds were plastic and would wear leading to slop and misalignment, later ones were die cast. People used to shim worn out sled with razor blades/other thin metal pieces.
> Post windows 95 they still had some bargain flight sims that seemed popular.
The golden era of flight/space sim !
I miss my wing commander(s) (don't you dare mention/reply Star-Citizen !)
I think I played/broken through 2 crappy-cheap joysticks via the whole series. That perfect point in time (when you were young enough not to pay taxes, but old enough to get a soundblaster-card-kit with free wingcommander games)
Wing Commander series, Chuck Yeager's Air Combat, Falcon 3.0, X-Wing series, Descent 1 & 2. Thrustmaster flight stick and throttle. Good times, good times.
I never really mastered flying the F-16 in Falcon 3.0, but I at least got to the point where I could take off and land OK. The mission planner for custom missions was very sophisticated too.
For Descent, I had also tried out the Logitech Cyberman 2 controller:
In theory, it is ideal for flying your spacecraft in Descent, allowing you to move or turn in any direction in a a sort of intuitive fashion. However, it wasn't that satisfying in practice.
I also had at one point a steering controller that resembled a RC car controller. That worked a lot better for me than racing wheels that were much more common.
Pairing that with the original ReVolt RC racing car game (don't buy the ripoff version that was just released to Steam!) and you're talking many hours of fun.
It just takes time. For me it was a few weeks, with longer and longer sessions each time. I’m someone who gets sick from spinning in circles a few times, so if you can stomach that, probably less.
Car sims took the longest. There’s just too much hard wired in there.
> turn the machine on its side or even upside down to get the CD closer to the laser
I'm confused by this, doesn't that seem backwards? If it was sitting normally wouldn't it naturally be helped by gravity to be as close to the laser as the mechanism would allow? Upside down, gravity would be pulling it away from the laser. Right?
I don't have a Playstation myself on hand, but from memory, these mounts usually had a certain amount of play in them - if you touched it, you could press it a bit lower, for instance. Whereas the clamp that grabs the disk on toploaders tended to make a very secure connection. So it's probably not bringing the disk closer to the laser, it's bringing the laser closer to the disc.
> I made the whole engine and animation system fit in 4K so it would fit into the instruction cache of the CPU
That's an impressive feat. The screenshots in the linked article look pretty nice particularly for the a PSX-era game, it has a good futuristic, but dirty industrial cityscape thing going on. Did you manage to utilise any of the tech in another project, or was the whole thing just completely binned?
> Did you manage to utilise any of the tech in another project, or was the whole thing just completely binned?
At that time we used to bin everything and start again (from the engine point of view at least). Usually it was so complex and hacked together by the end that there wasn't a generalised system to extract. We'd obviously take what we learned into the next title, but less so the code.
PS2 was probably the first time I remember reusing engines.
It sounds like Gavin went beyond that, cutting into Sony's forbidden library space; it helps that he was a lisp head and didn't respect the existing C prefabs.
I don't remember if it was the blog or the extended video but he also got into some of the close to the metal choices they made, like sharing variables and rolling dice on the compiler each build to fit with only a few kb spare in the whole cd space.
> It sounds like Gavin went beyond that, cutting into Sony's forbidden library space
Sure, this wasn't an exhaustive list of every trick we had to do, it's just another war story. This is the one that I remember the most vividly, but there were myriad tricks to bend the system to do what it didn't want to do :)
This is effectively what younger generations that praise C don't get, the kind of tricks that most game developer had to do 20 - 30 years ago in home computers and game consoles, given the bad quality of C compilers in regards to code generation.
I've seen this pattern so many times in my time doing development (although I haven't done game development professionally), and why I tell people to avoid early development optimization. Trying to get things working correct and fast at the same time is an insane ammount of work, by the time you're done the requirements probably changed or the project flops, you'd be better off just getting something to satisfy minimum requirements first then make it fast.
To a certain extent I agree with you. But when the game doesn't even fit in the RAM of a development system (4mb), never mind the 2mb of a real Playstation, or movement is 5 frames a second rather than 30/60 it's still very hard to get gameplay aspects right. And when the graphics engine, level editors, etc. don't even exist yet, you're not making any game!
In the 10 years I was in the industry (pre the era of off the shelf engines) I never saw a single title in a playable state until the last 6 months of the project, and sometimes later. My era was PS1, PS2, Dreamcast, original Xbox, Gamecube. I left as the PS3 was in its pre-release period.
I think for most games the dynamics are quite well known, and so it's less problematic if it's started later. But, in this case none of the dynamics of the game were worked out at any point, so it was doomed to fail.
On Lunatik I wasn't responsible for the game dynamics, I had one job: make the engine, and make it as fast as humanly possible so that the game and level designers can make a decent game. So, it's not either or, but it does take time to have the initial version that the team can work with (my C reference engine mentioned before).
One final point is that it's less about early optimisation and more about poor management, short timescales, and the balance of cash given to a team when signing with a publisher. When the money runs out, then you're in the lap of the publisher gods - it can go either way for many different reasons, some of which might have nothing to do with the game.
I suspect it's more professional now (and with better tooling), back then it was still pretty much a cottage industry: quite a large cottage industry, sure, but still pretty amateurish in terms of project management and planning. There wasn't a title I worked on that didn't overrun.
Wasn't trying to suggest it was premature (especially if you couldn't have more powerful devkit/device to prototype on) just envisioning someone burning long hours and stress to meet deadlines and then the work gets wasted because of various reasons. I've done that so often during early career - nowadays I'm much happier doing bare minimum untill it's absolutely necessary - I just don't have the 12 hours a day energy in me :)
Yes, although not a full title. It was the period between PS1 and PS2 and no publishers were committing until they knew what was happening with PS2 (because of the outrageous success of the PS1). I built a bezier-patch based engine for it and physics system, and we produced two fun little game demos to try and get publisher funding, but it didn't come.
It was super easy and fun to develop for (which after the pain of the Saturn was a relief). It's a real shame it didn't get more support, it just arrived at the wrong time.
That's interesting. Would it have been better if sega had wait until post PS2? The Dreamcast was the last console I loved. I bought one on launch day. But I think looking back it was always doomed. I can't recall properly but I think it was someone in EA or high up in sega America who tried to persuade sega Japan that they wouldn't survive with the type of games they were planning for the Dreamcast. Oh well in those two years the Dreamcast had some of my favourite games.
I'm not sure if delaying it would have made any difference. PS1 was a zeitgeist machine, especially with titles like wipEout. I remember going to underground nightclubs in London and there'd be a chillout room with Playstations in. The Dreamcast just wasn't cool enough I guess.
I think Sega also seriously fucked up with the Saturn. There were lots of claims of it being more powerful than the PS1, but nobody could extract that power really. A Saturn dev at a studio I worked at had a complete breakdown just trying to keep up with what I was doing on the PS1. I feel they burned a lot of industry bridges with that machine.
I'd have loved to see the Dreamcast succeed because I'd always been a big fan of Sega, but I think a lot of things just went awry for them.
Ha! I'm still playing wipeout (on retro arch though). I only bought a PS1 around 2010 as I'd been an N64 fanboy. I really had missed out.
I heard the Saturn was originally designed as a 2d machine, sega saw what the PS1 was going to be capable of and bolted on 3d. Hence it was a mess. Is it true it could only use quads not triangles for polygons?
> Is it true it could only use quads not triangles for polygons?
Yep, but obviously a quad could become a triangle with two shared vertices. I never worked on the machine myself, and my memory is definitely fuzzy on this, but I seem to remember one of the things stressing out my colleagues was the poor transfer rate of getting textures into the video hardware, and the space being quite limited. So, all textures ended up being down-res'd by 50%, which just made everything look terrible.
I'm sure there were other issues, that's just the one I can vaguely remember.
I see engine re-use quite alot in game development, though, so there's always the chance that if you make a really bang-up engine, it might eventually see the light of day in another project, even if the original one was canned.
In the context of Eidos, for example, I seem to recall that Gex 3's game engine (which was a mediocre game at best) ended up being re-used/tweaked for Soul Reaver (which was an amazing game).
Now for sure, but back then any generalisation would potentially cost clock cycles or memory, so an engine would be fine tuned for the game in front of us. It would be entirely possible to take that engine and use it for a similar game, but then you hit the problem of needing to extend it for the new game - which is hard when you've optimised it to the nth degree and you can't see the wood for the trees.
One thing I saw after I'd worked on 'Fireblade' for PS2 & XBox [1], we took its engine and tooling (which had also been used for 'Reign of Fire' [2] in parallel) for our next title 'Battalion Wars' for Nintendo. After 6 months of fighting the system we downed tools for 3 months just to refactor everything. It was the first time I'd seen a real aggressive, whole team, refactor - and it worked, but really the engine & tooling just weren't right for the game and shouldn't have been taken without a commitment to making it fit-for-purpose for the game we were about to build. It cost us time at the end of the project, and for a while we weren't sure if Nintendo would keep funding it - luckily it worked out (and is actually the game I'm most proud of working on).
But yeah, once the consoles got more powerful and had more memory it was possible to start building core tech for multiple games, which is what I did for the last 4 or 5 years of my time in games.
Oh, wow, Battalion Wars! I never managed to beat it (surprisingly hard, IIRC), but I remember being blown away that a developer had actually tried to implement both the top-down RTS mechanic and the grunt-on-the-ground 3PS mechanic in the same game. I don't think anyone had really tried that since Dungeon Keeper, and rarely since.
Off the beaten path here, but just for my own curiosity: did Nintendo seek you guys out when they wanted a third party to try their hand at the license, or did you go to them with the pitch for "3D Advance Wars in real time"?
It was much harder pre-release, we had to tone it down! Although that's relatively normal when you get a room full of hardcore gamers making games :)
> both the top-down RTS mechanic and the grunt-on-the-ground 3PS mechanic in the same game
Yeah, that was something I particularly liked - it took a loooooooong time to get the squad control right, but I think it worked nicely. One interesting artefact is the sweeping camera movements (when switching units) and the follow camera algorithm was something I originally invented (probably reinvented) for Lunatik and I built it into Battalion Wars - so it bookended my time in games!
> Off the beaten path here, but just for my own curiosity: did Nintendo seek you guys out when they wanted a third party to try their hand at the license, or did you go to them with the pitch for "3D Advance Wars in real time"?
I thought I remembered this, and I thought they came to us, but the more I think about it the less sure I am of that fact! I'm now semi-thinking that we pitched the idea (not as Advance Wars) and they said "Let's make it Advance Wars 3D". But, yeah, passage of time, makes me question that. Sorry!
It's too difficult to try and re-engineer at the end to make it fast. Imagine if we used this approach for making airplanes or bridges. You have to engineer to a spec from the start.
The video certainly looks impressive for 1997! ...but I can also see why it might have been relegated to tech demo. Even just watching someone else play it, it seems like you guys weren't totally sure yet how to do full 3D movement in-flight in a way that felt fluid. When the ship moved up or down, it reminds me of someone holding the space-bar in e.g. Doom/Quake with NoClip mode turned on.
It also seems like the player might get rather frustrated that they can't hit an enemy ship that is five feet in front of them because the player ship is not exactly at the same elevation as the enemy ship.
> they can't hit an enemy ship that is five feet in front of them because the player ship is not exactly at the same elevation as the enemy ship
And that in a nutshell was everything that was wrong.
How to make Defender in 3D when you can't line up with the ships in three dimensions. For a slower game it would have been less of an issue, but at the pace we wanted it didn't work.
Did you guys ever do a post-mortem on how you might have solved that problem, or even how other games solved that problem?
If this was 1997, this would've been around the same time as Star Fox 64, and while that game was mostly on-rails (like Panzer Dragoon), it did have the "all range mode" maps where your movement was fully 3D. I played that game quite frequently as a child, and I don't remember ever feeling like I was having trouble hitting the enemy ships. Maybe the game had a very generous auto-target/fudge factor turned on so that the player felt like their aim was more accurate than it truly was?
Obviously we all knew of things like Star Fox 64 which is still really just a 2D game in many ways (following a fixed route), the idea was to not be on a fixed route and be free roaming.
We tried putting the player and all NPCs on a height-map - so effectively your vertical movement was based on a height map, which meant everything was vertically aligned - it was the closest it got to being decent (not sure why it didn't make it to the demo). It did allow rapid movement, less concern about targeting, and avoidance of low buildings, etc. (which allowed some of the Defender pace). However watching your bullets going up n down along a height map was weird.
But even then the free roaming nature of the levels meant that there wasn't ever an urgency to get to a place and do a thing. Each level would have targets to get to within a certain time, but then it was going away from shoot-'em up into capture-the-flag. Really it was misguided from the start.
By the time we'd tried lots of different options we'd run out of cash. I was 21 at the time, and it was pretty much my first software engineering job (I did do some educational software before that, but nothing at this level). So I wasn't perhaps as reflective then as I am now - and I left the company not long after.
> It also seems like the player might get rather frustrated that they can't hit an enemy ship that is five feet in front of them because the player ship is not exactly at the same elevation as the enemy ship.
Ha, I even had this problem with a 'modern' game, Uncharted (2? I think?). The one with the tutorial level with you on a dock having to shoot pirates or something. Aiming was impossible on the DualShock because you'd either not move the crosshairs or the crosshairs would just way overshoot once it started moving.
I ended up having to run up to the goons to land shots.
Thank God for Gamefly, that game went straight back even though I'd spend hours already getting it installed and then mandatory patches done.
"But ultimately the project failed because the original concept (3D Defender) was next to impossible to do really well. We tried many different gameplay mechanisms to make it work, and none were working"
Hey louthy, do you still have the source code for that PS1 engine? Maybe put it on Github for all of use to gawk at and/or use in some fun PS1 hacking around.
So the CDs I have were the PC & PSX versions for an E3 demo (well the PC one was marked E3 demo, so I assume the PSX one was too - as they were together). The PSX version is actually playable on RetroArch, so I've uploaded it to github [1].
I have also found some floppy disks marked 'work backup 1..n' alongside the Psy-Q PSX drivers. I've ordered a USB floppy drive 'cos I don't have one any more. They may (if they still read!) have the source on.
It's the channel of the Jon Burton, the director of the Traveller's Tales, he worked on games like Sonic 3D Blast or Crash Bandicoot: The Wrath of Cortex. It's full of interesting stories with technical details about how things were achieved on old hardware or why were they done in some funky ways.
I always loved this interview. Great gems there. I studied the PS1 tech for a while and it's amazing how even small artifacts (polygon jittering, affine texture mapping, etc.) became looks we now try to replicate for the sake of nostalgia. Fun times!
This guy is an excellent communicator. For a modern HN audience an explanation of virtual memory paging is not exactly necessary, but he does a great job of it and I'm sure this video would be really interesting for a much more general audience.
I made the whole engine and animation system fit in 4K so it would fit into the instruction cache of the CPU. The whole frame update cycle wouldn't need to touch main memory (for the code).
Also, because loading from main memory was slow (4 cycles) and the chip was RISC (1 operation per cycle), you'd need 3 NOPs after the Load-op for the register to be loaded. The C compiler (if I remember right) never really filled those 3 NOPs with useful stuff. So, I'd do hand written concurrency (in MIPS assembly) by loading other stuff I'd need into those NOPs - this was particularly effective when working with 3 dimensional vectors or 4 dimensional matrices.
Trying to keep super-optimised hand-written concurrency in assembly, in my head, was a challenge and not something I'd recommend! Still, the engine had more throughput than Sony claimed of their machine. Every bit of performance gained would mean an edge over the other games.
Then the game was canned by Eidos. Pretty devastating for my first industry job :/
[1] https://www.unseen64.net/2020/11/16/lunatik-pure-entertainme...