Project Frontier #8: FAQ

By Shamus
on Jun 22, 2011
Filed under:


Projects slow down over time. It’s inevitable. Partly it’s because the more you add, the more complex the code becomes, and so the harder it is to make headway. Swapping out a part on a lawnmower is easy. Changing that same part on a fully-loaded 2011 automobile is likely to be an order of magnitude more complex. But mostly it’s because we tend to go for the low-hanging fruit first and tackle the thorny problems later.

I began writing this series of posts a week into the project, and I’ve been gradually catching up. To wit: I’m adding features more slowly than I’m writing posts about features. Now that I’m out of new stuff to show off, these posts are naturally going to become less frequent.

While we’re waiting for the next breakthrough, I thought I’d take a minute and answer a few of the questions I keep seeing again and again…

1. So what kind of game ARE you making? What is this? Adventure? Platformer? Dating sim? RTS? FPS? Puzzle game?

I’ve been avoiding this question because I don’t want to sidetrack this series. If I describe the game in mind, it will only spawn a thousand more questions and objections. “But how is THAT supposed to work…?” “That doesn’t sound like fun to ME.” I’ll have to explain, and clarify, and defend, and I’ll end up writing a design document in the comments. We’re here to talk about procedural content for now.

I’ve been talking about procedural content for years, and this is my way of putting up or shutting up. “Yes, this is possible, games industry, here is my proof-of-concept.”

The project will probably die before I reach the gameplay stage anyway, so it’s best to not get too worked up about it.

2. Do you plan to release a build that we can try?

Yes. I’m not sure when, but I’m very curious how this technology will work on all those computers out there. Also, I think the project will be easier to understand if you can walk around in the world yourself. More on this later.

3. What are you working on next?

My priority list. (Which is by no means a guarantee that I will work on things in this order.)

  1. Day / night cycle. Not just light / dark, but sunrise, sunset, changing sky colors and fog effects based on time AND environmental conditions AND climate.
  2. Trees. Procedural trees with distinct species. I’m working on this one now, and it’s a biggie. Much larger than rivers in terms of complexity and challenge.
  3. Avatars. I want 3d animated figures.

    I’ll be honest. This is probably where this project will die. This is such a bitch of a problem that I can’t even begin to describe how much I’m dreading it. In my previous job, the 3D-character animations were handled for me by a third-party engine. (Renderware, the same engine used in Grand Theft Auto III.) I’ve tried twice before to make my own animation system, and both times it ended in frustration. It’s just a huge thing. It requires a well-defined art path. “Okay, you make the model in Blender and make sure to follow these steps. Then save it in this format. Now make the animations and save those in this other format. Maybe run a converter on them. Then my engine imports them. Then I’ll just move the character around using this nested hierarchy of transformation matricies that were probably devised in a foreign coordinate system and saved into a poorly-documented file format. And then I’m going to bite down on the barrel of this gun and we’ll see what happens after that.


  4. Move to vertex (and MAYBE pixel) shaders. There are things I’m going to want to do: Make the land curve away in the distance to hide terrain popping. Have trees and flowers gradually fade in. Replace the two-pass rendering I’m doing on grass with a single pass. I need vertex shaders for all of these. It’s going to be a big step, and it might mean relinquishing SDL. That will once again tie me to windows. It will also turn my tidy 100 lines of SDL code into a sprawling 700 lines of Microsoft-flavored Windows API calls. It will eat time, bloat my code, take away my portability, and generally annoy the hell out of me. I’m putting off this step, obviously.
  5. Weather. Particle effects.
  6. More environments. Lakes. Swamps. Forests. Sandy deserts. Steppes.
  7. Undergrowth. This might simply be an extension to the existing grass system, or this might be another, more advanced system.

4. Why does [feature] look so crappy?

Obvious answer: Because We’re still in the most early stages of the project. This is long, long before even the most hype-obsessed developer would let screenshots into the wild.

Other answer: The game doesn’t have a strong art design other than “pixelated”. So, it’s easy to look at the game and view it as something that’s supposed to be somewhat photo-realistic. Bare terrain doesn’t have a lot of personality. This will change as features appear and the style of the world takes shape. Nobody (sane) looks at Minecraft and talks about the lack of realism. The art style sets the tone, and the eyes accept things as long as they fit.

Check out Part 23 of Goodfellow’s Let’s Code series, he’s dealing with this same issue right now. Interestingly enough, he’s taking the opposite approach. He’s using tech to cover his lack of art, and I’m [planning on] using art to cover my lack of graphical tech.

For reference, I’m aiming the art style somewhere between World of Warcraft and Minecraft.

5. When will it be done?

Don’t make me slug you.

Enjoyed this post? Please share!

A Hundred!17117 comments. Quick! Add another to see if this message changes!

From the Archives:

  1. DanMan says:

    Ok, so maybe you don’t know when it will be done, but do you have a guess when it will be finished?

  2. Adam says:

    Procedural Trees == L-systems.

    Isn’t this a “solved problem” these days? (except for implementation and parametrisation…) Or am I missing something why you cant just do that?

    • Shamus says:

      I have a solution in my head already. Might as well use mine, as opposed to trying to learn someone else’s and THEN implement it.

    • Tom H. says:

      Yeah, “solved” as in “license SpeedTree from IDV for a modest sum of money”. The implementation & parameterization are huge.

    • Yeah, L-Systems are good for branching structures. I’m trying to find out more about self-sensitive L-Systems for road generation for my own project. The problem with L-Systems is coming up with all the variations and making them look right, which will surely take some time.
      I’m not sure whether Speedtree have a patent on L-System trees or just their method of billboarded leaves, but they’ve kinda become the de facto standard in Unreal Engine games at least.

      I’ll be interested to see what Shamus cooks up for this one.

  3. kikito says:

    Samus, don’t do traditional 3D avatars. Make them procedurally generated too!

    This way you will not have to spend as much time on the art production track (how do I export this from Blender?) and more time on the algorithms (how do I mane a leg with variable length do a satisfying walk? How should a procgen aerodynamic plane look?). Assuming that is what you want, of course.

    Or, just make them totally random 3d figures.

    • blue_painted says:

      I was thinking that this would be a fantastic idea too! So rather than facing identical enemies they all look different.

      Don’t mind us making it harder for you :-)

    • LVC says:

      Ooh, play as a swarm of bees! You could call the game Oblivion II: Pollinate! :P

    • Daemian Lucifer says:

      That would just make it even more difficult of a job.Spore did something like that,and movement was probably one of the toughest things to make in that game.

    • Wtrmute says:

      This is probably as good a place as any to plug this project, MakeHuman. It’s mostly geared as a design tool, but there’s a scripting API which might be used to hook up the tool as a DLL. I haven’t followed it in a while, but it allowed an impressive amount of parametrization to deform the models into mostly any design feature, which could probably allow Frontier to simply input some sort of body-code analogous to Mount & Blade’s face-codes to generate “random” humans.

      It’s a third-party solution, but on the other hand: it’s there, and it’s free, and I think it’s already properly rigged, so there’s 80% of the complexity already solved.

      EDIT: Reading further below, I realise what you really want to do is animals, and that software won’t help with that. Bummer, I guess.

  4. Daemian Lucifer says:

    #6 What about the book?

    *runs and hides*

  5. Colm Mac says:

    I’m always really interested in seeing how people do things in a procedural way. I was wondering if you had been following the ProcWorld blog. He did trees a bit recently and instead of using L-Systems, he used a Space Colonisation algorithm ( Examples: ).

    I’m curious to see how something like that looks in the kind of non-photo-real environment you are doing.

  6. Burningdragoon says:

    Ok cool… but will there be dragons?

  7. Adam says:

    I have to ask, if switching to vertex/pixel shaders would cause you so much grief, why do it? Are the benefits really worth all the headaches?

    • Kyte says:

      For one, fixed-function is, well, fixed. Any kind of custom effect will require custom code to go with it. Ergo, shaders. (For example: The “ground curves away according to distance” is a vertex transformation, which means it’s implemented as the vertex shader (Move the vertex’s projected spot on the screen up/down according to distance). “Flowers and tree fade in” needs both vertex & pixel shaders (the vertex shader takes the distance from you and gives it to the pixel shader, which can use it to regulate transparency for pixels associated to that vertex.)

      (In fact, most fixed-function pipelines nowadays are implemented as built-in shaders)

  8. Ross Angus says:

    What are the limits of procedural generation? Are there limits?

    Introversion’s work on procedurally generated cities:

    .. early in the development of Subversion fascinates me. How difficult would it be to add such cities to your landscape?

  9. S. Richmond says:

    I just wrote one and a half sentences and started again about 10 times just now. Why? This project makes me sad – It makes me sad that over 50% of your TODO list has nothing to do with procedural generation.
    I mean, seriously? Animation? Is having moving avatars we won’t see *really* that important to you? No where on your TODO is a networking implementation so I can only assume this’ll be a strictly singleplayer experience. So, where exactly are we going to see these avatar animations?
    Someone will say “Well the players arms herdurrr”. But Shamus hasn’t even begun to think about what this simulation will actually do, so there is no animation to be had.
    Oh and you’ve already got a graphics engine rewrite on your list. Are you intentionally trying to burn yourself out of this project?
    I really don’t understand your intentions Shamus – I love that you want to bring more focus to procedural generation within games, but you’re destroying any chance of doing that by trying to do *everything* from scratch. I know you know that too – Its something you hint about in almost every post you make.
    *shakes head* I dunno man, maybe I’m missing something…

    • Shamus says:

      There isn’t any code out there that will do what I want it to do. If I want it, I HAVE to write it from scratch. I’ve spent a lot of time in the past, mucking about with engines. Crystal Space. Ogre. Renderware. Irrlicht. A dozen others I’ve forgotten. All of them are too restricting. Sure, I won’t burn hours writing a terrain engine, but I’ll spend those hours and more trying to:

      * Understand the given terrain system.
      * Get it to accept data on-the-fly, instead of blocks of pre-made data.
      * Give me direct access to the back buffer between frames so I can cook my own procedural textures.
      * Let me apply procedural textures to existing geometry in real-time.
      * And much more.

      I’ve had several runs at this project now. I’ve never gone this far, this fast. Doing things from scratch was what I NEEDED to do to make this work.

      Animation system: I want procedural animals. But there’s no point in doing that if I can’t make them move.

      • Eldiran says:

        Here’s a loony suggestion to avoid the agony of 3D animating — why not render creatures as billboards, Doom-style? It’d be quite unique for a game nowadays, would certainly look pixelated, and most importantly it might bring your game into the realm of plausibly getting finished.

      • psivamp says:

        Procedural Animals sounds like a geeky band name. It also sounds freaking awesome. Are we talking about picking a random number of limbs and then using algorithms to figure out how they walk on three legs and stuff, because that sounds awesome, and also a pipe dream of mine…

      • Zak McKracken says:

        Procedurally generated animals:
        Had to think of those. I don’t know how they’re working (and if they could work in realtime), but maybe there’s some inspiration to be had.

        • Cybron says:

          While that is really cool, those are static models it’s generating. Making them capable of movement would be magnitudes more work, I’m pretty sure.

          • psivamp says:

            Also, they’re all different from each other, but none of them really exhibit recognizable features, like legs. I think Shamus wants legs — whatever, I’ll stop hiding behind Shamus — I want legs and arms.

            • Zak McKracken says:

              I’d say that most of them look like some sort of insect or sea animal.
              And while I couldn’t tell arms fomr legs or tentacles, they do have some sort of limbs.
              They’re probably not easily animated, but I wasn’t actually suggesting Shamus should use Entoforms. The method of making something biological-looking is cool, though.
              And I’d say that not trying to make some very realistic actual animal but something a little different probably makes it easier to come up with a procedural method that will accept random numbers as input.

        • MoonBeans says:

          I hope that they’re not random, but real animals, generated procedurally to add variety. Like the landscape isn’t alien, it looks like earth.

      • S. Richmond says:

        I know there are those stumbling blocks – Whole engines never quite fit. But had you considered at least looking for individual engine components? I would suggest you take a look at Thermite 3D and one of its components PolyVox before you go too much further ( Its built on top of Orge and Bullet to provide real-time creation and modification of polygonal objects and terrains, given a dataset. Its pretty much EXACTLY all you need.
        And even if its still not perfect for you, for gods sake, at least rip out some of the components. I think you’ll find a *LOT* of really good and useful code in the PolyVoz library for times when you have a procedurally generated [something] in data and want to represent it in polygons.

    • Sucal says:

      Also, if he can develop shiny enough code and systems, even if the game flops, he still has the potential to make a crap load renting out the engine. Or he will already have stupid amounts of detail in place for when he decides to develop a sequel.

      You most likely wont answer shamus, but will you be attempting to make the engine/content flexible for multiple different types/genre’s. Ie rather then just making an ‘fps engine’ will it also be just as flexible for a RTS or Spoiler Warning Season Five, Reginald Cuthbert strikes back

  10. Otakun says:

    Looking over your priority list, I think that since the goal is to show the games industry that procedural content is viable, your time would be better spent on micro-details than macro-ones. For example, weather, day/night, undergrowth, biomes – these are all things that directly impact teh user experience. Having teh distant landscape curve gently away doesn’t have as direct an impact.

    I guess what i am saying is that the micro-detail stuff is more of a platform for you to experiment procedurally on, whereas the macro stuff requiring vvertex and pixel shaders are tangential to your goal.

    Same with eth avatar system – its not going to be procedural, its going to be a giant chunk of traditional code plopped into your procedural demo.

    Of your priorities, # 1, 2, 5, 6 and 7 are all great places for you to continue innovating procedurally. # 3 and 4 are not procedural, promise to be a giant pain in the ass, and are where (in your words) the project is likely to die.

    Just sayin…

    • DanMan says:

      My priority list. (Which is by no means a guarantee that I will work on things in this order.)

      He is saying that he wants to do these things to make it a good game experience, but not that he will do it from 1 to 7 in that order

    • Alexander The 1st says:

      The thing about weather/day/night/binome is that, while they will clearly add to the user experience, they’ll only serve to deepen the uncanny valley that is render pop-in (Even Mass Effect, which tends to the more texture-pop-in as opposed to the “Hey, I can see more on the horizon from the Mako” pop-in, can’t say that “texture-pop-in” isn’t distracting.). No style, short of Silent Hill horror, benefits from fog-pop-in. This would prove that even procedural generation doesn’t have to have “Oh Hey, you need more land? Here…more land.” effects.

      It could also add something to mountains – they start off small looking, and then as you get closer, they seem to rise, because it’s actually curved in the distance.

      Binomes are sort of already there, and weather…could be difficult to look well.

  11. Reet says:

    If you think that creating avatars is going to be a really big pain in the ass then I would suggest not worrying about it. Considering that you don’t think it’ll get to the stage where gameplay will be implemented then what would you need the avatars for? and if you do need them maybe you should just stick with placeholders for now.
    I don’t want too sound dictatorial (because thats kinda what I think I sound like) but I just don’t want you to get annoyed with this project and lose interest in it like…certain other things because we may never see the end result and that would be a shame. So I guess what I’m saying is keep up the good work and good luck!

  12. X2-Eliah says:

    Can’t you move 3 and 4 to far later, in your todo list? Animations especially have no impact on your procedural world, and don’t benefit you at all as far as proc-gen is concerned. Likewise, what good will rushing the shaders do? You might aswell get more stuff done before tackling that, and think of animations even after that.

    • Shamus says:

      Like I said, the priority is no indicator about what order I’ll do them in.

      It’s more like, “These are the features I wish I had.”

      • Andrew B says:

        But… but… there are numbers on your list! That means you MUST do them in the numbered order! It’s the rules! Nrrrk!

        (P.S. Bullet points next time, perhaps?)

        • Alexander The 1st says:

          I’m reminded of the movie “I am number Four” that MovieBob reviewed once, where he was explaining that the aliens have to kill off the other aliens in order, hence the title name.

          If the aliens were any smart, they’d start on both ends. Still numerical, but you don’t get hung up on one until the end.

  13. Kian says:

    Have you considered alternatives to SDL that allow the use of shaders without sacrificng ease of use? I’m thinking of GLUT (freeGLUT on windows) and SFML, paired with GLEW. I’ve tried both, and they can both create OpenGL 3 contexts, letting you ditch the fixed pipeline without having to turn to the windows API. And they’re cross platform.

    Personally I prefer SFML since it doesn’t force you to give up control of the running of the program to the library the way GLUT does.

    • Pyroka says:

      GLUT is generally horrible and shouldn’t be used for anything that isn’t a quick hack, it’s input handling for example, is a joke.

      I’m really not sure what everyone has against setting up the OpenGL context themselves? It’s been a while since I’ve done it, but I don’t remember it being that hard.

    • psivamp says:

      I’m assuming — yes, I know what they say — that Shamus is using an SDL 1.2 release and not the SDL 1.3 beta. The SDL 1.3 beta supposedly supports OpenGL 3.3, but I haven’t actually gotten that far with it.

  14. Pyroka says:

    Project looks good, nice breakthrough on the rivers.
    Regarding 3.4 Vertex/Pixel shaders, I’m really not getting how this ties you to windows only, OpenGL can do both. Ok granted you’ll need some Win32 code to create a window and set-up the OpenGL context but that’s easy enough to abstract away to lower-levels (For example by creating a platform specific implementation of a window class and then use the Pimple idiom to select which platform-specific implementation to use at compile time).

    Also, as far as I know (I’m no graphics programmer) once you’ve set you engine up for vertex shaders you’ve also set yourself of for pixel shaders pretty much, so I don’t really think it adds that much complexity (bar writing said shaders ofcourse).

    I like the loft goal of proving to the industry that procedural is possible, although I think both Spore and Infinity: Quest For Earth (beautiful game that one) are ahead of you there but being non-space based this is a different project.

  15. Adam says:

    You should be able to use shaders with SDL because it just creates an openGL context, what you do in that context is up to you, SDL doesn’t do anything with it.
    By the way if you want shaders you have to have pixel shaders as well because the fixed function pipeline is replaced; there are plenty of places you can rip off the standard implementation though.

  16. MoonBeans says:

    Will you use your terrain engine for shadows? That would make the sunrise much more dramatic (plus people could say “the shadows are lengthening” without being wrong).

  17. Potado says:

    Ooh, procedural trees! That would be really, really neat.

  18. DrMcCoy says:

    Like I already said in another of your posts, and other people here have too, you don’t need to abandon SDL if you need shaders.
    You can always use the standard OpenGL API directly to get the newer OpenGL stuff (> 1.2). There’s even perfectly simple libraries out there that handle that in a portable manner, like GLEW and GLee that you can just pop onto your existing SDL-using code.

    • Shamus says:

      I do remember you saying that. Now that I’ve read it a second time.

      Stupid memory.

      That means adding shaders SHOULD be pretty turnkey.

      • Bryan says:

        Yeah, it’s just an extension. The most complicated bit *should* be getting the function pointers (doing the GL handshake to negotiate the extension’s presence).

        Unless I’m missing something critically important, which is possible. :-)

        (Please note, though, that the method of getting the function pointers is going to be different on different OSes. You said you didn’t want to release it open-source right away, which is fine — but if you ever do release it, it may make sense to centralize this interface in a header somewhere, to make later porting easier.)

  19. Kdansky says:

    Comment system seems to have eaten my rather long comment. Boo. :(

    What I wanted to say:

    Your list looks very uninspiring. Most of these have already been done (Day/night? Weather? Early Ultimas had both already), and often at such a high quality standard that you could not possibly hope to compete (SpeedTree).
    For such features to be interesting, you would have to (for example) make water levels be influenced by rain (which means you need liquid physic simulation, which is horrifically hard), or complex NPCs which react to the changes. Having bears go into caves at night isn’t exactly that special either, and 80’s RPGs did that already too.

    And at that point, “Complex NPC behaviour” should go on the list, which is actually a very interesting point. I am doing something in that direction myself, and it’s quite the struggle. Not from a programming point of view, but the concepts are very difficult.

    Then we got a few technical points (animations and shaders), both of which look very much unnecessary and like a lot of work, especially 3D models and animations, which most companies have full art departments for nowadays.

    Also nothing really procedural, and no gameplay mentioned. Did you forget that? ;)
    There are much more interesting things to do procedurally: NPC relationships. Companies / Jobs / Travel. Tectonic plates.

    • Shamus says:

      Yes, I’m sure the software that made the trees for the movie AVATAR is going to be just the right level of complexity and price point for my hobby project.

      • Kdansky says:

        My point still stands: Procedural Tree generation isn’t anything new, nor is it particularly interesting. There is also L-System and a quick search turned up quite a few more versions, and probably dozens of scientific papers.

        Why do what everyone else does, if trees are only visual candy anyway? Or do you plan to simulate wild fires or other events which completely depend upon trees?

        • BenD says:

          I bet he does, and I would pay good money for a game that lets me adventure in a world that can experience wildfires as part of its environmental engine. And isn’t SimCity.

          • Alexander The 1st says:

            Or more likely, the effects of forest fires. When you get there, it already decides if parts of a forest have been clear-cutted, burnt down because of some Space Marine NPC didn’t put out his cigarette with his foot properly, or if they died off from old age.

        • Drexer says:

          I’m sorry, you aren’t probably going to read this, but I just have to ask.

          Are you seriously considering that Shamus should not dedicate time to creating trees because ‘that has been done before’?

          I mean, trees are one of the most important elements of natural landscapes, they transmit information about the climate, about the world, they create shadow and block unnecessarily large lines-of-sight.

          If Shamus wants to do a procedural world it’s almost certain that he will need trees which can be nicely integrated with every part of the world and in that case, why shouldn’t he explore the program in his own way?

        • WJS says:

          You’re quite right that Shamus isn’t doing anything revolutionary with trees, however he is going to need them for comprehensive landscapes, and buying a Speedtree license isn’t really an option for him.

    • Eldiran says:

      “Your list looks very uninspiring. … There are much more interesting things to do…”

      Welcome to the early phases of game programming. ;p

    • SlowShootinPete says:

      “Also nothing really procedural, and no gameplay mentioned. Did you forget that? ;)”

      Ending a snide comment with a smiley face does not make it sound less snide.

    • Caffiene says:

      Also nothing really procedural, and no gameplay mentioned. Did you forget that?

      He specifically listed procedural weather, sky colour and fog all based on environment and climate, procedural trees, and extensions to his existing stuff (more environments = tuning the procedural generation to generate those environments). And thats just in his immediate priorities…

      He also mentioned everything he needed to about gameplay in point #1. Or did you forget that? ;)

  20. Factoid says:

    Can’t wait to see the Tree implementation. That’s definitely going to liven up the landscape a LOT.

    Have you played around with the size of the grass tufts at all? From the screenshots it looks like they’re all the same size, but it might give an interesting look if they varied a bit…maybe based on a steep bell curve. Most vary by +/- 5%, but a few vary by larger amounts.

    The cool thing about that system is that you could link the parameters of the bell curve to the region, so that in grasslands there are more tall grasses, and in forests there is more short grass.

  21. Jordi says:

    I am especially anxious to see you implement things like trees, lakes, and environments (essentially #2, #6 and #7 on your list), as I feel they have the most to do with making compelling procedural environments. A day and night cycle (#1) and weather (#5) seem cool too, but more tangential to the procedural environment goal.

    Personally, I would try to do as much of the interesting and novel stuff as possible, and worry as little as possible about unnecessary implementation details and awesome graphics. If you can make a system that can generate a plan for a compelling world/environment, even without actually rendering it, that would be very valuable. I personally see that layer as completely separate from the actual graphics. Those can be applied later, in any style and with as much polygons as you want. I realize that you do in fact have to render it in order to show (and view) progress, but if it were me that wouldn’t be a priority for me.

    But yeah, I trust your judgment and would urge you to just do whatever seems to most fun and productive to you, as you are the only one who has to work on it and we are all just along for the ride. And I really enjoy it, so thanks!

  22. burningdragoon says:

    Okay, going to try my hand at some actual input here. For the animations, you could go the way of 3D Dot Game Heroes which just had the standard handful of sprite frames except with 3D models (also dots). I’d think that’d save a lot of time/work/hassle. I don’t how good it’d look in your engine, but it looked good for that game.

    Edit: I’d like to point out that I don’t know what Minecrafts animation looks like or how fluid the animations are, so if that’s similar than whoops on my part.

    • aldowyn says:

      Minecraft’s, well, everything, are made up of 6 sided blocks. The animation for sheep with 6 blocks would be relatively simple, and it looks just fine.

    • Alexander The 1st says:


      …populated by blocky 3D sprites.

      I’m just saying it doesn’t quite fit. Can you imagine Fallout: New Vegas populated by blocky 3D Dot Game Heroes, or by Minecraft people? It’d be more than a little jarring.

      • burningdragoon says:

        It’d be silly looking, yes. Though It’d be funny to have fish out of water kind of story with either case.

        I actually just meant that depending on the art/technical direction of the 3D models, super simple animations won’t look bad. In Dot Game, there were only about 6 frames/models for each human-model and probaly about the same for the animals. If Shamus wants more realistic(ish) looking models than it probably wouldn’t look good.

  23. Rayen says:

    i dunno if anyone already asked this but, When you say “distinct species of trees” are you going to be using real life trees or just making a bunch of very different made up species? or are you going to use procedural system to have the program make up it’s own trees?

  24. Pope Comments II: When will you make an end?
    Shamus: When I am finished!

  25. JPH says:

    It’s gonna be a dating sim, isn’t it?

  26. Chris says:

    I’ve very much been enjoying this series. You sound pretty much convinced it will fizzle out. For your sake and ours, try to not let that happen. Skip 3D avatars, tie yourself to one platform, do whatever it takes to keep your energy up and let this be a happy project. Where youcan, avoid the Dark Place of undesirable development. I think what you have right now is looking quite lovely.

  27. somebodys_kid says:

    Will you be making a screen saver for this like you did with pixel city? I can’t tell you how many times my friend’s kids have been mesmerized by the soaring views of pixel city on my 55 inch LED-LCD TV. (Full disclosure: I’ve been mesmerized a few times myself.)

  28. Kelhim says:

    Funny how some commentators feel the need to call the ambitions of a one-man-project boring or not procedural enough. Surely he doesn’t mind investing all of his spare time in working through other people’s wishlists and simulating the not all overly complex human behaviour, always trying to surpass current industry standards in terms of realism in just a few weeks, when he clearly has an artistic vision for his own that in the new future doesn’t aim for realism in every possible aspect.

    It’s obvious that they’re talented programmers themselves and only want to help and that’s great, but it’s not what you say, but how you say it.

  29. Steve C says:

    Shamus said: 3. Avatars. I want 3d animated figures.

    So you want them and don’t want to do them. Fair enough. Consider this solution: Import someone else into your project. Not someone else’s code, but someone else’s code along with the author.

    I’m sure there are people out there with interesting animation/art hobby projects and no world to put them in. Preso. Avatar.

  30. Melf_Himself says:

    Shamus, I wonder if you’ve come across this fellow before:

    He’s made some pretty great looking procedurally-generated trees (as well as other things) in his voxel-based world. Some of the algorithms he uses/discusses should be of interest to you.

  31. DeroBoy says:

    I think people are missing the point of this project.

    He is trying to create a playable game all by himself.

    Everyone seems to be forgetting that with their complaints over features on the to-do list or suggestions of other software solutions.

  32. Zaxares says:

    Now, now, Shamus… Don’t let yourself turn into another Valve with your vague release dates! ;)

    Also… Am I weird for thinking that a procedurally generated dating sim would be rather cool?

  33. Arkady says:

    Making a single procedural tree probably isn’t much of a challenge (Richard Dawkins was doing it in “The Blind Watchmaker” back in the 1980s before he turned evil, and he’s not even a programmer of note.)

    Making a procedural forest on the other hand…

    It would be really fascinating (once shadows are implemented) to let local moisture, temperature and shade to affect tree growth and iterate each stage of growth in generation – the same way you do your simple erosion simulation – and see if you get real life affects: fewer, sparse trees in dry areas (root coverage may have to be modelled for this), bushy copses in temperate regions, and hot wet regions where trees are huge and form a canopy layer, and there is very little undergrowth.

    Trees are boring. Forests rock.

    • aldowyn says:

      Minecraft did this with the implementation of biomes, it makes a huge difference in how varied the trees look.

      Its system sounds more simple than what you’re suggesting, though – all it takes into account is the presence or absence of light and what biome it’s in.

      I’m thinking the hard part here wouldn’t be having the variables affect the trees, it’s HOW they would affect the trees. Forming canopies doesn’t sound like the simplest thing in the world.

      • Alan De Smet says:

        If you’re willing to burn CPU time simulating growth, I could see canopies naturally falling out: “Grow until you have enough light, or you reach your maximum height. If you can’t ever get enough light, die.” Dense areas would naturally turn into canopies with barren lower areas.

        Of course given Shamus’s goal of creating (and identically recreating) terrain on demand, I suspect it’s nowhere near fast enough. It will be interesting to see the technique he goes with.

  34. otakun says:

    Several people have already linked ProcWorld (including Shamus himself in a previous post in eth series) – but worth pointing out this specific post on generating forests according to Game of Life-style rules:

    He calls it the silver bullet for procedural forest generation. I’m sure Shamus is aware of the post but am bringing it up again anyway just for documentation.

  35. Danath says:


    I’m late to this party, but when I saw you mention trees it reminded me of something else I’d seen recently… not sure if it’s even slightly relevent to your coding but it was interesting.

    It’s her own talk about how she had to deal with trees, it doesn’t really give alot of information but maybe it might give an idea or something.

  36. Another_Scott says:

    So what kind of DRM will it have?


  37. Starglider says:

    If the focus is procedural content, why do you need to use conventional 3D modelling for avatars? Microsoft Xbox Avatars are procedurally generated meshes – albeit with canned animations, but some games e.g. GTA4 already make extensive use of procedural animation as well.

    • Shamus says:

      When it comes to avatars, even procedural ones have art assets. Moreover, I need to get the animation system working before I make avatars, because trying to make both systems at once would be Hard Mode.

Leave a Reply

Comments are moderated and may not be posted immediately. Required fields are marked *


Thanks for joining the discussion. Be nice, don't post angry, and enjoy yourself. This is supposed to be fun.

You can enclose spoilers in <strike> tags like so:
<strike>Darth Vader is Luke's father!</strike>

You can make things italics like this:
Can you imagine having Darth Vader as your <i>father</i>?

You can make things bold like this:
I'm <b>very</b> glad Darth Vader isn't my father.

You can make links like this:
I'm reading about <a href="">Darth Vader</a> on Wikipedia!

You can quote someone like this:
Darth Vader said <blockquote>Luke, I am your father.</blockquote>