As I’ve alluded to before, I’ve been working on a new programming project. Like most of my other projects, this one is tied to procedural content generation. While the Good Robot project turned into a real video game, most of these projects are intended to be experiments, educational projects, or proof-of-concept demos. I guess this project is all three.
What are we Doing?
Our goal is to make a procgen shooter level. It probably won’t matter, but I’m aiming for something that would work as an immersive simYes, this is a confusing and awkward name for this genre. It was named back in the 90s when a lot of genre boundaries hadn’t settled in and we were still calling shooters “Doom Clones”., not a turbo-charged run-n-gun shooter. Games like System Shock, System Shock 2, and Prey are some of my most beloved games. I like how the space station setting allows for open-ended exploration without needing to contrive a silly wall around the world to keep the player in the playpen. I like how the isolated setting creates a quasi survival horror vibe, where you’re all alone in a haunted box full of monsters. I like how combat is slow-paced and risky, and I like having to balance my supply of ammunition, weapons, tools, and healing items.
I also give partial credit to games like Thief, Deus Ex and Dishonored for being Immersive Sims, even if they don’t take place in my favorite settings or feature the open-endedness I’m looking for. I give partial-partial credit to the BioShocks for being watered-down examples of the formula.
You can argue over genre boundaries all day, but you don’t need to haggle with me that game X should be included or game Y should be excluded. It’s fine. You can decide for yourself what Immersive Sim really means, but it’s not going to change my design. I’m just trying to make something I’d like, which means a procgen space station / space ship setting.
I’m not going to be adding AI or monsters to fight, so this focus on “Immersive sim levels” is mostly academic. I just want to head off objections that the stuff I’m building wouldn’t work as a shooter because it’s too constrained to allow for insane run speeds and rocket-jumping.
So anyway, back to defining our overall goals…
We want to design a level layout, turn it into polygons, fill it with stuff, light it, add some sort of basic interactivityProbably moving doors and other simple moving objects., include some basic sounds, and let the player explore it all. I don’t expect to add real gameplay, but to keep with the spirit of the project the end product should be capable of working from a gameplay sense. The space should be coherent in the sense of having a complete route from the starting point to the ending point. It should be something that an AI could navigate. A few things should emit sounds to prove that the program is capable of it and has a way of placing correct sounds in sensible locations. The lighting should make sense, and there should be proper collision detection on everything.
While visuals don’t matter in a tech demo, I’m going to strive to make something vaguely presentable. It certainly won’t look like something you could ship to consumers, but it should be something that could be made cool with the help of an artist that knows what they’re doing.
Another goal is to limit complexity of the code. I’m normally inclined to do things “the right way” the first time, but for this project I’m sort of trying to find out what the Right Way is. So instead of building complex and optimized code, I’m going to focus on writing as little code as possible. The idea is that when I change my mind, I want to feel free to throw old code away and do something completely different. That’s hard to do if you’re thinking, “No! I spent two weeks on this! I can’t just throw it out!”
An additional bonus goal is that it should be possible to change the procgen parameters without changing the code.
See, every game runs on “magic numbers” to some degree. Maybe you’ll see the number 1.655 in the code. If the programmer is responsible and sane, then they’ll assign this number to a variable with a helpful name like “playerHeight” so you understand what the number is for and even have a chance to figure out what units this number is inIt’s meters, BTW.. If the programmer is lazy or inexperienced, then they’ll just name the variable “height” and you’ll be left wondering “Um. Height of WHAT? A font? A jump? Screen size? What scale are we dealing with? Miles? Feet? Pixels? Megapascals? Building stories? Parsecs? Giraffes?”
You end up with a lot of numbers like this in a game. You need numbers for height, speed, hitpoints, weapon accuracy, monetary value, volume level, damage inflicted, sight distance, weight, friction, cooldown time, mana cost, magazine capacity, font size, stack size, particle size, effective duration, and gluten content. The thing is, these numbers control gameplay, and that usually isn’t the programmers’ job. If the team decides that the AR-15 needs 15% more gluten, then the gameplay designer shouldn’t need to make a request to the programmers asking them to set aside their long and highly technical work so they can find a number somewhere in the code and change it.
So you put all the magic numbers into some sort of settings file where the design team can fiddle with them as much as they want without dragging coders away from their jobs.
You won’t be able to use these numbers to turn a shooter into a Minecraft clone or a 2D platformer into a visual novel, but you should be able tweak the behavior of the game. In the case of this project, that would mean fiddling around with procgen parameters to make different kinds of spacesI’ll probably use XML to store these numbers. so we’re not trapped with a hard-coded system. When I worked on Good Robot, Ross Zevenhuizen was able to do a lot of things that had never occurred to me using the settings files. It’s a little more work, but it can really pay off if your art team is up for experimenting with things. Of course, I imagine I’ll be the only one working on the project. But still. It’s nice to be able to make quick changes without needing to re-compile whenever you want to iterate over a new idea.
This project is the product of many inspirations. In chronological order:
1) System Shock 2
Way back in 1999, I got sorta hooked on System Shock 2. I have no idea how many times I’ve played through the game, but it’s probably at least a dozenDisclosure: I never cared for the end section where you enter the fleshy tunnels to face the Many. I think I’ve only played through that four or five times. I usually get to the point just before the Many, and then declare the game over, quit to the main menu, and start a new game.. At some point I had to stop playing because I’d memorized all of the loot and gotten stuck in the rut of an overly-optimized run. I wished there was a way to randomize all the loot and enemy positions so I could return some sense of mystery and surprise to the experience.
Also, I noticed that the levels were actually pretty simple. Unlike the convoluted multi-level maps of the late 90s, System Shock 2 was designed to look like a reasonable human-designed space that could be depicted on a 2D map. It didn’t depend on labyrinthine tunnels, winding corridors, or stacked room designThere was a little vertical movement, but it was very simple compared to contemporaries like the Unreals, the Quakes, or Half-Life. System Shock 2 was mostly a main corridor that branched off into cuboid side-rooms. Procgen systems code ought to work really well with that sort of thing.
2) The Lost Project
Back in 2015, I worked on this project:
You can see additional screenshots of the project in my OpenGL series. That project served multiple purposes. It was a failure on all counts, but it was an educational kind of failure. I wish I’d written about it at the time, because I’d love to read through that process before embarking on this project.
The main purpose was to experiment with blending modern rendering techniques with retro styling to see what it would look like. That didn’t work out for the reasons I explained in the middle of this post.
The secondary purpose was to experiment with procgen level design. I was trying to make something really open-ended that could generate a 90s style deathmatch level, and the lack of structure made it impractical. The space would end up being boring, cluttered, non-sequitur rooms. I found myself gravitating towards using prefab pieces, but I felt like that went against the intent of what I was trying to do. I discovered that you need some limitations and structure or the whole problem becomes too abstract. So now I want to take those lessons and try again with a different approach.
I liked the idea of a procgen level, but in the end a level was mostly a chain of prefab pieces. I’d walk into a room and go, “Oh yeah. This one again.” That’s not bad or anything. It’s more than other games attempt. But I still felt like there was more that could be done with the idea. Authors of 2D side-scrolling roguelikes have gotten really good at making procedural 2D gamespace, but very few people are trying for that sort of limitless variety in 3D. Yes, it’s true that 3D is many times harder than 2D, but I think it’s a reasonable idea to strive for.
4) System Shock Remake
I’m still following the development of the System Shock remake, and every time I see a new video or screenshot I find myself thinking how good this particular grid system would be for procgen levels.
In the original System Shock, spaces are built on a 2-meter grid. You can use any cube or wedge shape that fits in that grid. That would work really well with a system that branched off corridors into smaller corridors into rooms.
I’m not going to actually use this grid system, but seeing the screenshots makes me want to do procgen stuff.
5) Project Hammertime
Earlier this year I did that weird project where I tried to load Half-Life levels from the Hammer editor into my Unity game.
That was fun and made me want to do more programmy-type stuff. And yes, it was actually called “Hammertime”, even though I never confessed that during the write-up.
For the Unity!
If you’ve been following my site for the last few years, then you probably won’t be surprised to learn that I’m going to be doing this in Unity.
Before Unity, I did all my projects by hand in C++. That’s cool, but I dropped a lot of projects because I was sick of needing to constantly build infrastructure for myself. C++ is really barebones. No built-in rendering pipeline. No support for 3D models. No sound, no physics, no collision detection, no font support, no controller support, no skeletal animation, and no support for image loading. Yes, there are free libraries for all of this stuff out there. But finding them, figuring out how they work, and getting them to inter-operate gracefully is still a monstrous task. It’s perfectly normal for me to spend far more time building infrastructure than working on the problem I’m interested in.
At the other end of the spectrum, Unreal Engine is way too heavy for small experimental projects like this. Also, I’ve never seen anyone doing serious live procgen content using the engine. Unreal seems to be built around the idea of loading premade assets. Okay, there’s this one video that’s one of those insufferable live training sessions. The end product was needlessly convoluted and impractical and in the end it was basically a randomizer for a Doom 2016 snapmap setup. That’s… completely inadequate. If Unreal has any real tools or even basic allowances for making your own assets at runtime, I’ve never seen it documented or demonstrated.
I was hoping Jai would be out by nowIt was supposed to be available at the end of 2019., and I’ve been sitting on this project for months in the hope that Jai would come out. But it’s late in 2020 now and we still don’t have a revised date for any kind of public release. I’d love to try Jai, but I think I need to move on and come back when Jai is available and the community has worked out a rough set of standard practices, documentation, and maybe some quasi-standard libraries. Waiting until the first round of bug fixes would probably be smart too.
So that’s the plan. We start next week.
 Yes, this is a confusing and awkward name for this genre. It was named back in the 90s when a lot of genre boundaries hadn’t settled in and we were still calling shooters “Doom Clones”.
 Probably moving doors and other simple moving objects.
 It’s meters, BTW.
 I’ll probably use XML to store these numbers.
 Disclosure: I never cared for the end section where you enter the fleshy tunnels to face the Many. I think I’ve only played through that four or five times. I usually get to the point just before the Many, and then declare the game over, quit to the main menu, and start a new game.
 There was a little vertical movement, but it was very simple compared to contemporaries like the Unreals, the Quakes, or Half-Life
 It was supposed to be available at the end of 2019.
Project Button Masher
I teach myself music composition by imitating the style of various videogame soundtracks. How did it turn out? Listen for yourself.
The Middle Ages
Would you have survived in the middle ages?
Silent Hill Origins
Here is a long look at a game that tries to live up to a big legacy and fails hilariously.
Grand Theft Auto Retrospective
This series began as a cheap little 2D overhead game and grew into the most profitable entertainment product ever made. I have a love / hate relationship with the series.
Quakecon 2012 Annotated
An interesting but technically dense talk about gaming technology. I translate it for the non-coders.