Talking about procedural content, Bobknight asks:
wouldn't the vast majority of the content be(by definition) random? or do you mean that instead of specifying each individual â€˜box' they just point to an area and go â€˜mountain here.' or â€˜desert here' and use the appropriate algorithm for each one? If that is true, wouldn't he algorithm become increasingly/impossibly more complex if you want to put any kind of detail(the kind of detail that most RPG/sandbox games demand) in it?
I mean, how does this help to make something like fallout?(where you have the dead janitor on the ground with his two bits of meat and a can of beer)? Would the resulting game world be merely a HUGE collection of randomized terrain that has absolutely nothing on it?
So far my approach to this – and I’m sure FUEL does this as well – is to make procedural systems recursive. A system produces data, and that data is used as input for another system. One level carves up the world into geographic regions. That data is used to generate the topography of the world. The topography is used to decide where to place cities. Those locations are used to build street systems. The streets are used as a guide for placing buildings. The buildings can then be filled with hallways. Hallways are filled with dudes. Rooms connect to hallways. Furniture goes in rooms. Objects go on furniture. Player is given a gun and told to go kill some dudes and get some objects.
Each system is a set of rules and depends on good input. In 2003 or so I wrote a program (and the source is gone, I keep meaning to re-write it, dangit) to take some topographic data and attempt to plot a road across it. The rules governing roads – while not set in stone – are fairly reliable and observable. Roads will curve in response to hills to keep from becoming too steep. When a road is navigating around a hill, the inside of the curve should bite into the hill and the outside should lift it up. (In the real world, engineers displace dirt from one side to add to the other, which produces the familiar banks on either side and the distinctive not-dumping-you-into-a-ravine horizontal flatness for which roads have become so popular.) In my system, the road was willing to go up and down steeply in direct proportion to how far off course it was. My road wanted to go north, but would veer to either side to avoid hills. But as it came closer to heading due east or west, it would be willing to climb or drop to a much greater degree. This produced a very convincing road. (However, the system would occasionally encounter topography that was not solvable with the given rules, and the result usually looked hilariously bad.)
You can see this at work in FUEL. If you go out to the perfectly flat zone in the northeast you can see the roads basically form a grid. In the hilly parts of the game, the roads bend around quite a bit. In the really hilly sections, the roads get crazy twisted. Sometimes you’ll see a road get “trapped” by unworkable input data and it will either climb a sheer cliff or simply give up and end abruptly. Note that the roads in FUEL had the added challenge of needing to intersect with one another at reasonable angles, which was something I never attempted.
The point is, FUEL is recursive. It generates topography. (And I suspect even the topography generation is a multi-stage deal.) Then it places roads. Then it places debris on the roads and buildings alongside them. If you’re trying to make “procedurally generated Fallout 3”, the next step is to add more stages. This becomes really easy if you decide to take the Bethesda shortcut and make exterior doors into magic teleporters that will move the player into the building without needing to worry about a smooth transition between the two. (This solves tons of problems. You don’t need your interior floor plan to precisely match the exterior of the building, and you don’t have to worry about the complex culling problems you get when the player starts seeing through multiple windows at once.)
As for the “dead janitor” problem: You can have artists design special set pieces and simply make their placement exceptionally rare. The artist will make a group of objects like the janitor, his mop bucket, and his beer, and specify rules like “this thing only goes in hallways” and “this should never appear more than once in the same building” and “this should only appear in 1 out of every 50” buildings. Then the game will drop in the janitor every now and again. As far as the game is concerned, he’s just “furniture”.
The move to a procedurally generated would wouldn’t mean that the world would have to be dull and sterile. With the right rules you can make places just as vibrant and interesting as those in Fallout 3. You just need to make the up-front investment of building the system (no small thing, I’ll grant you) and change how your artists approach their work. If the world feels monotonous then it means your rules aren’t robust enough or your artists haven’t added enough variety yet.
I’m convinced this this has been do-able for the last several years. I just wish I could earn a paycheck proving it.
The Best of 2019
I called 2019 "The Year of corporate Dystopia". Here is a list of the games I thought were interesting or worth talking about that year.
What did web browsers look like 20 years ago, and what kind of crazy features did they have?
A look at the main Borderlands games. What works, what doesn't, and where the series can go from here.
Fixing Match 3
For one of the most popular casual games in existence, Match 3 is actually really broken. Until one developer fixed it.
What is Vulkan?
What is this Vulkan stuff? A graphics engine? A game engine? A new flavor of breakfast cereal? And how is it supposed to make PC games better?