I converted two more levels to FBSP format – map02 and map03, the biggest levels that form the core of the game world. I can report that map03 runs fine and dandy after some additional vis blocking (ie making sure areas are physically well separated). As you can see in the above shots, map03 is so well structured that only small parts of it are rendered at once, even though the map consists of 17,000 brushes. No performance problems, I’m at the point where I can just tweak the lighting and take full advantage of q3map2’s features.
Map02 is a different story:
Despite a brushcount of only 9,000 (physically half as big/complex as map03), this level brings the engine to an almost total halt. Obviously the entire map is rendered even if it shouldn’t be visible from the point where I’m standing. It has practically broken vis blocking – the entire level is open towards the sky, which is just a big box encasing the map.
There are two noteworthy things about that.
The first is that the same map in Quake 1 BSP format runs fine in the same engine. This tells me that Quake 3 does visibility in a different way which is a lot less robust than Quake 1’s. That’s regrettable, but not enough to make me switch back.
The second is that the way I’m mapping, the type of world I want to create, is incompatible with the BSP (binary space partition) format itself. BSP works with a scheme where the world is sliced into “leaves” on the proverbial BSP tree. It assumes that the world is simple, made of rooms and corridors, and that there is always a simple way to calculate what leaves are visible from what other leaves, and that there are never too many leaves anyway. That is the case in which BSP operates well – rooms and corridors with 90 degree bends in them. It then renders the geometry that’s touching the visible leaves, culling the rest to keep performance up. So much for the theory.
In practice, the world I create is a little too complex for BSP. There are a little too many leaves that are visible from too many other leaves. My world isn’t necessarily made up of well defined rooms and corridors, but rather from stuff inside a volume. My rooms might have multiple holes and connections in them, and my corridors might be their own areas instead of just tubes. I might have very large outdoor areas in which these open rooms are situated. It ends up with a scenario where everything is potentially visible (PVS = potentially visible set) from everywhere, and BSP’s entire leaf-visibility thing is broken. You might as well not use BSP at all.
BSP in itself is a technology that limits content creators with a thousand kafkaesque rules. Technology rules over design; if you create something that’s outside the norm, you are punished by failing map compiles, cryptic error messages and the engine refusing to run your content. It rubs the lotion on its skin, or else…
This is why they say that idtech engines are good for making corridor shooters. It is true; even if some of the corridors might look like outdoor areas, they are subject to the same limits.
Scout’s Journey is too far along to completely exchange the underlying technology (beware Daikatana Syndrome); but I’ve learned the lesson. I’m unlikely to continue using BSP or idtech for future projects.
As for map02, I will adapt; I will make it into more of a room and corridor type of thing. You will no longer be able to run all across the roofs or base-jump off its central tower. Such are the rules. Those things will have to wait for another project using a friendlier technology.
Apart from that, but in part inspired by it, I have decided to allow even more platforming elements into Scout’s Journey. I mean, if you have to seal certain passageways to conform to BSP’s iron nazi rules about visibility, you’ve got to provide alternatives right? Right, and why not make the alternatives more interesting by requiring some creativity of the player in order to navigate them. That’s where we quickly arrive in platforming land. I’m gonna throw in a couple extra obstacles, too, so you’ll do the old Super Mario stuff a little more than previously. Scout’s Journey inherited walljumping from RMQ after all (which inherited it from Warsow and Quake 2), and I intend to make ample use of it. Yes, there will be plenty of wall-jumping in the singleplayer campaign. There already is, even. And yes, players will be required to learn how to use the grappling hook. If someone can’t deal with the learning curve, they can go and play Call of Duty and have everything spelled out to them. Press button to advance.
I also want to go for a slightly more modern / abstract look and feel with more pronounced contours to the game world. This is a bit of a Warsow and Mirror’s Edge influence (the latter deserves its own review), both of which demonstrate that a game doesn’t have to look excessively dark, grimy and dirty to evoke some atmosphere. I’m not going to use cel-shading, but a slightly clean, comicky look is entirely in order. I’m actually detecting ample amounts of comic-ness in Quake itself, an observation which the “keepers of the one true flame” are no doubt going to contest. Luckily I don’t need to care anymore. It’s not Quake, and that’s OK.
Rock on dear readers, while I go mapping.