New games have spoiled us. There’s this unspoken assumption: If you change zones, have a cutscene, or pass through a loading screen, you get an auto-save. But in 2003, this was not a rule. We had all three of those things happen here without getting a save. Spoiler: This comes back to bite us in this episode.
If you want to know about this Invisible War game we were talking about, there’s an Errant Signal episode for that.
I find the comparison interesting because both of these games came out the same year and both were multiplatform releases, coming out on both Xbox and Windows. The original Xbox had just 64MB of ram. For comparison, Good Robot – the 2D side-scrolling indie game I’m helping to develop – currently eats about 200MB. To be fair, a lot of that bloat comes from the third-party libraries we’re using. Over the last 12 years, a lot of software has come along to relieve coders from the drudgery of making their own code for interfaces, audio code, rendering pipeline, controller input, and a dozen other things. That’s wonderful, inasmuch as it’s made the current surge in indie development possible for a whole generation of developers who would rather focus on gameplay than building complex technical frameworks. Sure, there’s a steep performance cost to doing things this way, but like I said in the column this week, Moore’s Law was pretty sweet while it lasted, and gave us so much extra power to spend on stuff like this.
Still, it’s amazing to think that my little game uses more than three times as much memory as KOTOR. Actually quite a bit more, since certainly the Xbox operating system would have eaten into that 64MB.
EDIT: Actually Good Robot only uses 132MB. I was looking at the numbers for the debug build when I wrote this post. So Good Robot is only twice the size of KOTOR, not three times the size.
I think one of the big technical blunders for Invisible War was moving to bump-mapping and bloom lighting. Those technologies were pretty new at the time. KOTOR doesn’t do any of those fancy tricks, and has a super-primitive lighting model. Going strictly by technology, KOTOR came out in 2003 but was using technology from 1999 or so. It’s also third-person, so the camera is further away from the scenery. Which means they can get away with low-resolution texture maps.
Not only were the texture maps in Invisible War larger, but they needed double the texture maps, because bump mapping / normal mapping requires another texture. The bloom lighting would have required an extra framebuffer, which would have eaten 3 precious megabytes all by itself.
EDIT: 3MB was based on the assumption that this game ran at 720p, but it was only 480p. So the bloom framebuffer would have been just under a megabyte. I still say that’s not the best use of resources in such a memory-starved situation, but not nearly as bad as 3MB.
By not blowing memory on fancy rendering tricks, BioWare was able to spend more of their meager memory budget on game space: Rooms and corridors and such. Yes, KOTOR looks pretty barren and could clearly use some furnishings here and there, but it’s still better than Invisible War and their closet-sized cities.
id Software Coding Style
When the source code for Doom 3 was released, we got a look at some of the style conventions used by the developers. Here I analyze this style and explain what it all means.
Silent Hill 2 Plot Analysis
A long-form analysis on one of the greatest horror games ever made.
Steam Summer Blues
This mess of dross, confusion, and terrible UI design is the storefront the big publishers couldn't beat? Amazing.
A programming project where I set out to make a Minecraft-style world so I can experiment with Octree data.
The Gradient of Plot Holes
Most stories have plot holes. The failure isn't that they exist, it's when you notice them while immersed in the story.