LEGO Island 2: The Brickster’s Revenge (2001) has gained a bit of a cult reputation. Both for its legacy, but also for the insanity buried in its code. A deep dive by users on the Rock Raiders United forum revealed that LEGO Island 2 is a hilariously strange beast under the hood, loaded with hardcoded stuff and seriously inefficient in spots.

Hardcoded Assets and Redundant Files

One of the first discoveries was that LEGO Island 2 is almost entirely hardcoded. Rather than using external data files or a flexible engine, the game’s executable (.exe) contains explicit lists of file paths and object references for every asset in the game.

Textures are an exception in that they’re referenced by index numbers instead of names, but even the mapping of textures to models is actually baked into the code. This design makes the game rigid and difficult to mod, since nearly all asset relationships are fixed in the compiled program.

On top of that, the game barely reuses assets across levels. Most areas are almost complete copy-pastes when it comes to content. If the same model, texture, or sound shows up in different levels, it’s often just duplicated in each level’s files. Everything’s stored in archive files (.bob/.bod), and you’ll often find the same tree, hat, or signpost repeated in five different archives for five different levels.

Even stuff like NPC hats (of which there are a lot) get copied into every scene that needs them, usually with 3–5 LOD versions each. So the game ends up with hundreds of duplicate models, textures, and collision files, which bloats the disk size and tanks loading times since each level loads its own set of redundant assets.

It’s worth noting that loading times were made worse by another quirk: The PC version of the game prioritizes animating the loading spinning pizza graphic over actual disk loading. So you end up with this perfectly spinning pizza, but the level data loads super slow. Users eventually figured out you could fix it by changing one line of code.

To make things worse, even assets that are visually exactly the same weren’t shared if they had different textures. Instead of reusing one 3D model and just swapping the texture, the devs usually just copied the whole mesh and slapped on a new texture. Every version of a character’s head across levels is a separate model, just because the face texture is different. So Pepper, the main character, ended up with multiple identical head models that only differ in texture. Same deal with switches in one of the final levels (Brickster’s Palace): there are two switches, but the game uses four models (one for each switch being “up” or “down”). They didn’t just rotate one model for the flipped state; they made duplicates and hardcoded every version.

This kind of stuff happens all over the game.

Hundreds of Files for… Rocks in Space?

The wildest example of this is the Asteroids mini-game. In it, Pepper is flying a spaceship through a bunch of asteroids, and every single asteroid is its own 3D model. The game files have 235 separate asteroid models and 235 matching collision files, even though there are really only three basic asteroid shapes. And get this: two of those “variations” are literally the same model, just placed in different spots. Instead of loading just a couple unique asteroid meshes and reusing them, the game loads 470 files (235 meshes + 235 colliders) to build this asteroid field. All this extra stuff means longer loading times (mainly taken from just technically loading the same model multiple times) and a bigger install size.

One rough estimate says about 27% of the game’s entire data, around ~178 MB, are just these duplicate files. So if they’d cleaned that up, LEGO Island 2 would allegedly take up less space than the original LEGO Island from 1997. Kinda wild how those choices made what should’ve been a pretty lightweight game into a big chunky one for its time.

Tons of Polygons and a “UV Map from Hell”

LEGO Island 2’s 3D models weren’t just duplicated a lot, they were also pretty badly optimized. Some models use way more polygons and vertices than they need, usually because of messy exports or skipped cleanup. One example is a skeleton from Adventurers’ Island (a desert area of the game). It’s a fairly low-poly skeleton model, only 1,416 triangles, yet it has 3,065 vertices in the data. Normally one would expect the number of vertices to be in the same ballpark as the number of triangle corners (for a manifold mesh, roughly half again as many vertices as triangles). But here, the vertex count is more than double. The reason? The way the UV mapping was done.

The skeleton’s face uses a normal textured UV map (for the skull’s facial features), but almost the entire rest of the body is assigned a plain white texture. Instead of mapping the body like one continuous surface, they mapped each triangle of the skeleton’s body separately onto that white texture, resulting in a crazy patchwork of UV “islands”.

In 3D graphics, when you break up the UV map or use different smoothing groups, the engine usually has to duplicate vertices along those breaks. If two faces don’t share a smooth connection or UV space, their shared vertex gets counted twice. This skeleton’s UV layout was so chopped up that the vertex count exploded. Someone joked that the UVs had “more splits than a masochistic gym instructor”, and yeah, it looked like something straight from hell.

This inefficient mapping added a lot of unnecessary data: more vertices means more memory use and worse performance, especially on the old hardware from the early 2000s. A community member re-unwrapped the skeleton the right way, merging most of the micro-islands into solid chunks. That cut the vertex count almost in half, down to about 1,686, without changing how the model looked. And this wasn’t just one case. Loads of models in LEGO Island 2 had the same issues. No wonder the game lagged and took forever to load.

If you’re into the technical side of things, check out Guillaume Provost’s 2003 article series “Beautiful, Yet Friendly” (Part 1: Stop Hitting the Bottleneck and Part 2: Maximizing Efficiency). It’s from 2003, but it still touches on some good practices for 3D assets in games.

He explains how too many UV seams and smoothing groups can blow up a model’s vertex count. Fewer breaks in UVs and shading means fewer extra vertices. Looks like the LEGO Island 2 devs either didn’t know that or didn’t have time to do it right, and the game’s performance paid the price.

TLDR

LEGO Island 2 is packed with inefficient assets. Assets are hardcoded and duplicated (instead of referenced) across levels, wasting space and slowing things down. For example, two identical switches were made as four models, and 470 files load just to show 235 asteroids, even though technically only two models are needed. Some 3D models, like a skeleton with over 3,000 vertices from a messy UV map, are way more complex than necessary.

It’s a textbook example of what not to do in game optimization.