Mario Helps Us Understand Procedural Generation In Borderlands
We’ve already discussed how Borderlands differentiates its many, many guns but haven’t talked too much about the programming that makes this possible.
Gearbox is using a process called procedural generation. To put it simply, Gearbox doesn’t make the guns. They make the rules that tell a computer how to make the guns.
The process is a little hard to visualize for a non-programmer like me. That’s why I found a blog post from amateur game designer Supergork helpful: Algorithm for Procedurally Generating 2d Sidescrolling Platformer Levels (say that five times fast and try not to fall asleep.)
Dauntingly scientific-sounding titles aside, the post talks about using procedural generation to create levels for a Mario-like sidescrolling game. The type of game Supergork is making is relatively simplistic, but the amount of thought behind it isn’t.
One of the tough parts with procedural generation is that computers don’t think. They just follow the rules you give them. If you don’t tell it not to, the computer could procedurally generate content that disrupts the game. Example: a wall your character needs to pass that can’t be passed.
Here’s how Supergork illustrates this.
= is air; x is ground.
==
==
=X
=X
=X
XX
The boo-boo is that Mario can only jump 2 squares in this example. The programmer needs to add a rule that prevents the generation of this terrain.
Now imagine how complicated that must get with a game like Borderlands. Instead of 2D world, it’s 3D. Mario can only run in two directions and jump. In Borderlands, the character can move in 360 degrees and drive different vehicles. The procedurally generated maps must accommodate a much more complicated range of actions.
And then there’s the guns. The many, many guns. They all have to make sense (a pistol shouldn’t be more accurate than a sniper). They also have to be carefully balanced. The last thing we want in a game with so many weapons is one “best” gun that we end up using in all situations.
I think a Borderlands dev summed this up best in a post on their forums: “Procedural generation of weapons = Pain in the posterior.” True that.
I know you said you do some game design and programming yourself. Have you ever used it any of your projects? Or is it something that only works in very specific circumstances?
I mentioned in...well probably my first post? on this website I believe, that I program.
Once again, really not that daunting a task. It definitely seems complicated to someone not coming from my background, just like I would find it dauntingly difficult to understand the conditions behind say, fishing.
If you want a key-example of masterful procedural generation on a difficult level, take a look at Spore. Just in the development stage of that game they broke a lot of barriers for technology, animation, and procederual generation for video games, and the electronic world.
That's difficult because they tried to make life-like simulation from anything. Animate ANY system in a neat way. That's complex.
Borderlands, not so much. Simple put, graphically we deal with simple animations, which don't even neccesarily depend on each other. For instance, if you were to break a gun up into its barrel, its trigger, handle, and ammo clip, you could say that a trigger, regardless of the other components will be animated the same way. So really theres no trickiness. Though there may be trickiness in say, making sure that guns stay sane, that the pieces are graphically "fitting together" and that if say it has a pump action reload, that that will work in sync with all other components of a gun.
As for the REST, it's just numbers, and thats where computers excel at, and is quite easy to program if you're in the programming realm.
If anything I said is unclear, badly phrased, or you have questions, feel free to ask. It's 1:46AM here, and I'm getting tired, so I may not have phrased this the best. ^.^
Well, that depends on your definition of procedural... I haven't coded any RPG projects where I have used procedural item generation, no. But to be honest, I haven't coded any RPG projects since middle school when we did Qbasic, and the teacher basically said "make whatever you want and I'll grade it"
A huge ammount of normal computer programming is creating procedural items. Like, if I want to take your name out of a form and format it a certain way to put it in my database, I might use a procedure that detects the way the name was entered, for example my database only needs first name and last name, so if someone enters "Roger J. Cleets", I'll have a procedure pull the single string into it's element parts, first world, middle world, last word, and then tell the data base to only save the first and last word. I might write a procedure to detect if the name format is "vonlastname, mcfirstname" by identifying the comma, then I just have the item send the data the way I want it.
Procedures are no stranger to basic programming, it can be a bit of a mind trip to get them to create things for you though. Expecially complex things, like visual assets. The acctual statistics for the guns was probably easy for the most part, but I bet it took a fair bit of brain work to make the renderer work right.
Like I said in an earlier post, to me the more interesting thing would be procedural mission generation. You have want to scale it so it's making a mission with the right difficulty, so players have the right ammount of ammo at the right times, and they are finding appropriate items to the difficulty of the mission and so forth. You need to ensure it doesn't produce repeditive encounters, you need to ensure that the player isn't fighting too much or too little (stressful game pace or boring game pace), and that's after you've even done the simple stuff, like making sure the levels all connect properly so the player can reach his destinations (like the mario example). It's about trying to mathimatically analize what makes a game fun, and then make the game create the fun for you, rather than relying on any of your artists or designers to create those elements. VERY hard.
@Shirow : No that makes sense to me. As I understand it, you're pointing out that procedural generation can be harder, can be easier. It depends on what exactly is being generated and how the components need to relate.
@Swiftspear : Agreed that procedural mission generation is a very interesting concept. If a developer could nail that on the head, they could make a game that's essentially infinite.
One question about procedural mission generation: would that also include the narrative of the mission? That is, could they procedurally create the characters, dialog and storyline? Or does that just get way too complicated?
Basically you're saying procedurally generated PLOT, which has been attempted, but its almost always shoddy in feel, and doesnt feel right. Either you have a ton of pre-programmed plots, or you have an almost "Fill in the blank" approach.
"Hey <name> Please help us save <random town> from (rampaging <monster name>/shortage of <random item>/ item delivery to <town>), we will pay generously
---<Prestigious Official>"
Undoubtedly you should recognize this just from playing games, as it is attempted every so often.
That is quite hard to pull off "realistically" IMHO.
Ya, it doesn't feel great. The procedural engines always miss minor details that a story boarder or writer wouldn't overlook. That being said, the better procedural games are starting to get better than the worse nonprocedural ones. Check out dwarf fortress adventure mode. The entire world is procedurally generated but adventure mode is still really fun once you get the hang of it.

Bleh, procedural generation is a pain in the ass, but it's simply not possible to manually make a half million guns. What makes PosGen fun is that, ya, the rules can be a brain trip to make work right, but once they are in place, you don't make the game any more, the game makes itself. Nothing is cooler than a game that makes itself.