{"id":542,"date":"2006-08-08T11:52:22","date_gmt":"2006-08-08T16:52:22","guid":{"rendered":"http:\/\/www.shamusyoung.com\/twentysidedtale\/?p=542"},"modified":"2009-08-06T14:19:56","modified_gmt":"2009-08-06T18:19:56","slug":"the-procedural-world-part-2","status":"publish","type":"post","link":"https:\/\/www.shamusyoung.com\/twentysidedtale\/?p=542","title":{"rendered":"The Procedural World, Part 2"},"content":{"rendered":"

In my previous post<\/a> I mentioned the way .kkrieger<\/a> uses procedural objects, instead of using pre-fab objects built by an artist. <\/p>\n

I guess I should warn you that I have a passion for this subject. <\/p>\n

A few years ago I made a program that made procedural trees. I got tired of the fact that all of the trees in our software looked identical. (Because they were all copies of the exact same object.) So I came up with some code that would let you plug in some numbers and it would spit out a tree object. By adjusting the numbers that controlled the distance between the ground and the lowest branch, the length and thickness of the banches, how much they sagged, how crooked they were, how tall the tree was overall, and what textures to use, you could come up with all sorts of different trees. You then just change the random number seed to come up with more trees of the same type. So, you could design an “oak”, and then generate an unlimited number of unique oak trees. On top of this the program could make the trees smoothly grow from sprout to full-size, although I never got around to adding seasonal changes. <\/p>\n

It was a cool little project, but in the end I found out other people aren’t nearly as excited about these sorts of ideas as I am. Sadly, it ended up as a novelty that was never put into use. Sigh.<\/p><\/div>\n


\nProcedural methods have a lot to offer game developers, not because they save disk space (which is cheap and plentiful) as in the case of kkreiger, but to save on development time<\/em>. Generating textures, weapons, and monsters is amusing but impractical for a real game, but procedural gamespace<\/em> is something worth looking into.<\/p>\n\n\n
\"Wolfenstein
Wolfenstein 3D, 1992<\/small><\/center><\/td>\n<\/tr>\n<\/table>\n

At the release of Quake ]I[ Arena, I remember an interview with John Carmack where he said that the levels for Wolfenstein 3D (1992) took 6 weeks, the levels for Doom (1993) took nine months and the levels for Quake (1996) took two years. Keep in mind also that while the time required to create these game worlds was going up, the number of people used to accomplish the task was increasing, and the total real estate being produced was decreasing. Old-school shooters could boast about 40 hours of gameplay, but modern games often only last between 10 and 20. Having messed around with level editors for the various generations of games, I can see this inflation of man-hours is still going on, and that ever larger teams are needed to produce that same fifteen or so hours worth of territory. <\/p>\n

So we started with one guy working for six weeks to make 40 hours worth of gameworld, and we ended with (say) five people working for two years to make 15 hours of gameworld. This is obviously a bad trend. When people talk about “barriers to entry<\/a>” and “the increasing cost of game development<\/a>“, this is a big part of what makes the new games so expensive. Creating gamespace is horrifyingly time consuming, because the job is so much larger and more complex than it was at the dawn of 3d gaming.<\/p>\n\n\n
\"Doom\"\/
Doom, 1993<\/small><\/center><\/td>\n<\/tr>\n<\/table>\n

In the oldest games the designer could just place simple building blocks together and call it a level. The floors were level and featureless and the world had no real lighting. There was almost nothing you could do wrong. Now level design is part architecture, part construction, part interior decorating, and part scripting. Today the artist must design the building, the floorplan, the doorframes, place furniture, set things so that the wood floor sounds different from the concrete floor when you walk over it, and arrange the lights. They have to set up moving doors and elevators and also the controls the players will use to manipulate them. They must place ambient sounds and write scripts to animate the various NPC’s in the game. They must set path markers or other invisible cues for the enemies in the game to use so they don’t get lost or stuck while chasing the player. They must do all of this with an eye on performance, making sure they pull all of this off without unduly harming framerate.<\/p>\n\n\n
\"Quake\"
Quake, 1996<\/small><\/center><\/td>\n<\/tr>\n<\/table>\n

In Wolfenstein, you could make a playable room in under a minute. In today’s games, you might spend several hours or more on a room. This is going to continue to get worse as graphics engines get more advanced. Every new feature requires some work from the artist to put it to use. This explains why games are getting shorter even as budgets are getting bigger. Even with more people and better tools, it’s still an uphill battle to build game worlds as large as they used to be.<\/p>\n\n\n
\"Quake
Quake 4, 2006<\/small><\/center><\/td>\n<\/tr>\n<\/table>\n

Part of the problem is that for the most part level editors offer too much<\/em> freedom. I can sit down with the Doom editor and make a house. Or a space station. Or a nightmarish Tim Burton world of sloped walls and crooked doorways. But for the most part the level designer is only going to be making one of these types of spaces. While you can imagine a game that would require the artist to make all of the above, for the most part a game needs only a few distinct doors, used over and over again. A good level designer can handle this with copy & paste, but that misses the point. If your level designer is making a warehouse, then he’s going to be making lots and lots of plain-jane two-meter doorways. Since this is such a common thing in game worlds, it could be worth the time required to handle it procedurally. So, the artist would have a “door” tool. Click on a wall, and the tool cuts the hole in the wall, adds the doorframe, places a door with a doorknob in it, sets the hinge parameters, adds the sound effects, and places the markers that will tell the NPC’s how to use the door. <\/p>\n

Now take that same idea and apply it to the rest of the job. I’m looking forward to the day when level design is just about designing the layout<\/em> of a place, where the artist can throw down a floorplan of simple lines and let the software worry about setting up the floor, ceiling, carpet edges, archways, pillars, baseboards, doorframes, doors, windows, and all of those other little details that make the world more real but devour so much artist time. <\/p>\n\n\n
\"Tamriel\"\/
The world of Tamriel.<\/small><\/center><\/td>\n<\/tr>\n<\/table>\n

But procedural development has even more to offer “outdoor” worlds. I’m actually astounded there are still game houses out there which are building their outdoor worlds by hand. Huge worlds like the one in Oblivion are brutally time consuming and expensive to build. An artist must sit down and create the terrain, and then populate it with flowers, trees, mushrooms, rocks, and so on. When you’re dealing with an area of sixteen square miles, manually placing every rock and shrub becomes a daunting task. We’re talking many hundreds of hours of artists’ time. <\/p>\n

But the whole thing can be made in about ten minutes if you’re willing to write some code first. If I’d been given the task of realizing the world of Tamriel<\/a>, I wouldn’t have even looked at the editor. I would have written a program that let me divide the world into regions. Then I’d add some code to control plant placement. Such as: This plant likes to grow in tight bunches, near rocks, and it only grows in the swampy regions.<\/em> Or: This plant likes to grow sparsely by the water in the coastal region.<\/em> Similar code can be used for spreading rocks around, placing the wildlife, and so on. Once this code is written, it can crank out a whole new version of the world every couple of minutes if you like. Or – more importantly – it can make a much larger version of the world at no additional cost. Suddenly you can decide how much gamespace you need for the game to be fun (you can<\/strong> have too much of a good thing) instead of how much you can afford.<\/p>\n

Once the world was generated, then<\/em> I’d turn artists loose and let them use it as a canvas on which to build the game. Istead of starting with a blank slate, they would start with a world full of detail where they could just clear stuff out to place cities, castles, wrecked spaceships, or whatever the particular game called for. <\/p>\n

I’ve been expecting game tools to move in this direction for some time, but it hasn’t happened yet. It takes some investment up-front, but I’m convinced the time spent will pay for itself by the end of the project. Several months ago I was messing around with the DOOM engine, working on a proof-of-concept of this idea. The levels are stored in a lovely text format which makes it easy to have an external program (like mine) generate a level. Sadly, I got stuck on an implementation detail: The DOOM maps use some bizzare system for defining UV values (the values that tell the game how to put a texture on a wall) and I couldn’t make any sense of it. I may dig that project out of mothballs now that I’m thinking about it again. <\/p>\n

Even if I don’t get it working, sooner or later someone<\/em> will make this idea work, and then everyone will be doing it.<\/p>\n","protected":false},"excerpt":{"rendered":"

In my previous post I mentioned the way .kkrieger uses procedural objects, instead of using pre-fab objects built by an artist. I guess I should warn you that I have a passion for this subject. A few years ago I made a program that made procedural trees. I got tired of the fact that all […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[66],"tags":[523],"class_list":["post-542","post","type-post","status-publish","format-standard","hentry","category-programming","tag-game-design"],"_links":{"self":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts\/542","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=542"}],"version-history":[{"count":0,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts\/542\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=542"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=542"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=542"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}