You can get Voxel Farm now. For more information click here.

Monday, March 5, 2012

Procedural Pixel Art

Most of us use procedural techniques to produce realistic results. It is very refreshing to see them applied to achieve a more abstract look. To pull this off is very difficult, you need to combine a very developed artistic sensibility with programming skills.

I have been following this project for a while now: Voyager3. I like very much the feel of the environments. It reminds me of beautiful game art like the one in Sword and Sworcery and Journey.

This is concept art, but it you check the site you will see they are getting close to achieving this look. The project is fairly new, but I think it has great potential.


  1. Wow! Thanks for the post and the kind words. And yes, I do follow your feed and look forward to your posts :)

    I'm pleased to report that in the past few days I've finally started to get back to working on procedural generation after a few weeks of messing around with technical things. We're going to try a voxel-esque approach for generating the base volume as described in this paper: We'll see how it goes and hopefully I'll have a blog post up by the end of the week.

    1. I'm glad to hear you are making progress. I understand this type of project can be hard to sustain. You really have a vision, don't let it go.

  2. Replies
    1. Another World is why I like doing games. Yes I'm old!

  3. Oh wow, what a unique art style. Really impressive.

    You know what pains me the most with all this work I see on procedural games? The lack of collaboration. I think we can all agree that procedural environments rely heavily a deep set of algorithms to produce detailed results. So many projects are rolling their own procedural engine, and we could benefit so much from collaboration here.
    I understand that we each all have our IP to protect - If Michael released his project as open source his ability to gain a reward for his years and YEARS of work may be greatly diminished, and I can agree that isn't very fair.

    Would anyone be interested in opening discussion around this? Maybe we could find a solution - Would anyone be interested in creating a working group to develop an open source library for procedural environment creation? The idea would be for people like Michael to donate parts of their codebase to the library without destroying their unique IP.

    1. Cheers! I'm interested in collaboration. Yeah I'm kinda trying to work out how we might deal with IP. I've gained lots from reading various academic papers and tutorials online, and it would be a shame not to give back to the community. That is, until we have anything worth giving back!

      Once we do more interesting things we might start sharing some psuedocode or something. We'll see.

      I think how good the result is depends a great deal on how skilfully the elements are put together. Just because people free access to some of your code doesn't mean you're necessarily threatened. Well, that's the idealist in me talking; I don't know how well it'd work in practice.

    2. I completely agree regarding the result output. However I would envision a library where people such as yourself could donate your procedural algorithms as a set of isolated functions one can choose to run over their volume dataset.
      So the library would be a collection of algorithms to push a dataset through. That way your unique blend of tweaked algorithms remains your own IP, yet you are able to give back to the community and probably gain a whole lot more back from other contributions.

    3. I would contribute to such a project. At the same time I have big reservations, but they are not related to the Open Source nature of it.

      I believe games must be designed like Formula One engines. Almost every atom in the engine is aligned to what the engine is meant to do. There are no atavic features, no fat, no sugar. Everything in the engine serves a single purpose.

      A generic middleware library is the opposite of that. Since it's specific purpose is unknown, it must be generic enough to allow diverse projects. Procedural generation is a very diverse field. You can tell that by just comparing Brendan's work with Michael's work, with Shamus' or mine. Creating a production quality library to help them all will be very difficult, or this will be a very shallow library or very specific for one look.

      I think the knowledge about the procedural techniques should be open, then these techniques can be implemented as the programmer sees fit. So instead taking on the ambitious project of a working library, I'd rather focus on discussing the techniques and open source examples for them.

    4. Whilst I can agree at a high level, in practice I don't believe that's the case - No one really rolls their own render/physics engine anymore unless its for extremely specific purposes. Frameworks like UDK or Unity provide a very large set of atomic enough tools that allow for a developer to effectively create a product that is still unique.
      I think that would be my approach to the open source project. I would like to see any complex math algorithms abstracted away in neat OO functions, but still require enough arguments to make them unique completely depending on what you put into it. If you get my meaning.
      I would expect the library to also implement a bunch of other utility functions like isosurface extraction methods and poly reduction, etc etc.

      I dunno. Obviously you guys are the experts here. But I believe it could work.

    5. Speaking as someone who has aspirations to procedural content, I would like to agree with MC that some kind of generic middleware would be effectively useless for most practical purposes.

      What's needed are collections of well documented algorithms. Not papers; those are in plentiful supply already and aren't really helping newcomers. Instead, something that discusses what something does, how it does it, and more importantly, why it does it that way.

      Providing a reference point for a newcomer to look at the methodologies, and understand them well enough that they can adapt an existing one to their purposes, or create their own.

      It's possible in the process that common elements could be identified and refined, things that can be used as the basis for other larger, more complicated designs.. but like with any complex project, it's better to start with a simple prototype, then refactor it as you better understand its limitations for your goals.

    6. I'm considering writing a book and dumping all I've done so far. I would do it in a way you could reproduce any results I have. It would have explained source code too for the key algorithms. I would sell it, but make it very affordable. If you are interested just give me a shout :)

    7. As eso said, there is quite a large pile of theory already on the subject. The gap, in my opinion, is the practical implementation of a procedural system. I don't even think the algorithms used to generate the data are necessarily all that important on their own. The bigger issue seems to be how you combine those algorithms and then practically use and interact with the data in real-time.
      Case in point - This application you're developing here is amazing in its own right, but the question for me as a developer would be just how the hell I could tie it into a game and actually make it part of the game and not just a starting point for world gen. Could be its just not the market you're aiming for here, but those are the kind of questions I see often in this niche industry.

      P.S. - I think your book idea is still actually a really good idea. I'd buy it if it took a practical approach to the subject - I want to learn by example with real code. I care less about line-by-line explanations of all the algorithms and more about the over all end-to-end process and delivery of something procedurally created to the player.

    8. Well, it is about generating the data. Once you have it you can render it into different target systems. It could be polygonal meshes, sparse voxel octrees, even isometric images. The materialization/rendering part is the easy part, you just need to pick what is your target. Procedural techniques in the most part are about replacing human artists. Humans are not only expensive, you cannot pack them along with your software so you can generate new art on demand.

    9. You're not wrong. I think we both each have different focuses on what we want procedural content to do. For me I don't have too much interest in using procedural techniques in purely static environment generation. The greatest strength, in my opinion, of procedural content is the depth and detail you can go to. I mean once you have the ability to generate the data then you can move in and out of detail levels with ease. I would want to use that detail to make the environment more alive. To do this your target visualization engine (render, physics, input, etc) needs to be aware of what the actual content is that it is displaying. It needs to know that the tree model you've generated is a tree, and that the parts of it are leaves it can run vertex animation on to simulate wind and other physics. It needs to know what a building is versus a rock wall or cave so it can feed that back to to AI that might use that information to let NPC's know they can do things with the building. Dynamic destruction/construction is another feature that appears to go hand-in-hand with procedural environments. How do you feed that information back and forth between all the systems in a game?

      Without that kind of interactivity I don't see procedural generation ever really taking a central part in video game development and will probably remain just a single step artists use to quickly create a canvas they then paint over.

      I feel like it needs to be standardized. I feel like that procedural content in games is extremely complex when we think about all the things we could do with it, as above. We can't continue to roll our own unique 'formula one' engines from scratch because its not sustainable. We need a library of 'parts' developers can use to build their engine, which should be open enough to allow those skilled enough to tweak and build something new and unique.

      Anywho, that's my rant. Apologies for the breadth of it, but I think this stuff will play a big part in future tech in any fields. We should pioneer it right from the start.

    10. I'm interested the same in offline generation (or static as you call it) than in realtime. They are the same, the only difference is one little constant, how much it takes to generate content versus how much it takes for the player to experience it. Really complex worlds, at least as I envision them, cannot be created fast enough in the current and maybe next hardware generations. But the algorithms and workflow can be the same. This is not about initializing a canvas for artists to add their stuff. This program I have shown during the past month allows you to define and teat generation parameters for different types of procedural objects. The actual generation can be offline or realtime.

      Current game architecture is a number of systems like AI, physics, rendering that consumes content already cataloged and properly annotated for execution. You don't need new ways to tag or define your content just because it was generated on the fly, as a result the legacy systems are not required to change much. The same information can be produced in a procedural way, the question is the same, do you have enough time and power to come up with good data, so you are back looking again at the data generation algorithms as the pivotal point of your solution.

    11. "Procedural techniques in the most part are about replacing human artists."

      I'm sorry, but I have to disagree with you on that. There will *always* be a need for artists and designers to provide aesthetic and design direction. With all due respect to the hard working computer scientists creating these awesome journal articles I rely on, from a purely aesthetic point of view many of the final products look mediocre at best.

      From my point of view as an artist and designer, it's less about getting rid of us and more about improving our productivity. Instead of designing each building or object and placing tens of thousands of these elements individually by hand, by collaborating with our developers we can design systems to automate it. This ultimately helps us to focus on the wider problem of making a rich, stimulating experience for our players.

      What I really want to see is both developers and artists working closer together. Our aims are intertwined, and we really need to understand each other if we want to realise our full potential as creative practitioners.

  4. Concept art looks cool, I hope scenery looking like this will someday accomplished procedurally.
    I didn't kinda grasp what this thing is for... Will it be a some kind of game or just procedurally generated villages and such?

    1. I read that Tolkien created Middle Earth before he wrote the stories, so I guess I'm doing the same thing: creating a world that fascinates me before tackling the 'game' side of things (although it is on my mind). Hopefully that will prevent the world from seeming like it 'revolves around the player'.

      Richard Feynman once said that the Universe seems pretty pointless and I tend to agree with him. So then why does my game need a point as well? It is whatever the player makes of it.

      That being said, the road ahead long, so anything could happen. :)

    2. Sounds great. Just remember though that the universe Tolkien created consumed the better part of his late life, and he never even lived to see it become what it is today.
      Point is, you might want to drop in a milestone or two for yourself to get it packaged and playable. You don't want to risk loosing your passion for the project when you don't see any interest from the internet.

    3. Oh there's plenty of interest – I'm just having trouble living up to it. There's so much I need to do and I've only got so much brain power. I'm really starting to consider looking for another dev to help us out. But they're pretty hard to come by. And even if you do find one of them who's excited about your project, they're usually super busy.

      If you know anyone who'd be interested in collaborating, please let me know!

      Thanks for the time management advice too. I don't know how long I'll be working on this, but I want to have something 'presentable' (if bare-bones) in at least a few months time. I realise that might be a tough ask, but all my work will be for nothing if this never sees the light of day.

    4. It's really hard for two people to mesh their visions when they're passionate about similar but inexactly matched concepts, assuming they have compatible skillsets in the first place.

      Personally, though I am interested in the idea of collaborating in the abstract, I'm not at all certain I would be capable on a productive level. My cognitive requirements seem to be largely incompatible with other people.

      I'm pursuing procedural generation of world and assets in a 2d environment. The toolkit I needed doesn't exist, so I'm building it, starting with the language and the VM it runs in. Then comes renderer. Then comes creation tools.

      Finally, actual content production. I have no idea how long this will take, but I continue to move forward.

      Mine is a very particular madness.

    5. "It's really hard for two people to mesh their visions when they're passionate about similar but inexactly matched concepts"

      Indeed, I know exactly what you mean. Xiaohan and I get on well because we started early, but it's a little tricky for somebody to join when you're a reasonable way down the conceptual process.

      On the other hand it's sometimes good to get a different view on things. And not being there from the start could allow them to be more detached from the idea, giving them the freedom question shaky assumptions that might have been picked up along the way. It really depends on the person. It's very much like dating in a way ;)

      And wow, that sounds like a crazy amount to take on! Not that I can talk, haha.

    6. Actually now that I think of it joining forces with Xiaohan really did alter my vision drastically. Because I knew he'd worked on 3D projects before, it gave me the freedom to consider it as an option. I'd still be on 2D if not for him (check the very first posts on the blog). My art style has also evolved significantly the demands of trying to visualise a three dimensional world.

      So maybe there's somebody out there who has another piece of the puzzle that I don't know I'm looking for. You never know… :)

    7. Actually now that I think of it joining forces with Xiaohan really did alter my vision drastically. I knew he'd worked on 3D projects before so that gave me the freedom to consider it as an option. I'd still be on 2D if not for him (check the very first posts on my blog). My art style has also evolved significantly due to the demands of trying to visualise a three dimensional world.

      So maybe there's somebody out there who has another piece of the puzzle that I don't know I'm looking for. You never know… :)

    8. Unfortunately I have nearly no background in procedural work, past what I've read on this, and a handful other blogs. I've attempted to do some myself at various points with differing success.

      Having said that, I did begin work on something similar already. Not procedural content generation, but procedural knowledge base. A memetic library for AI knowledge. The parallel I would like to draw here is that for a thing which can be as broard as these topics, you can do as much reading into and around a subject. You can do your own experiments and make a good library/system. What really helps a lot when trying to generalise it is talking to people who know either nothing about how you've envisioned the system, or the topic entirely. They will always ask questions you've never considered before. Some may not be relevant to your particular use case, but the majority will make the design more robust.

      I agree with the "too many cooks spoil the broth" idea... but at the same time, you can get many incredibly busy kitchens running smoothly producing perfect food. Adopting Brooksian terminology, you need an Architect. The head chef in the kitchen. The person who keeps the vision consistant. So you can have many people contributing, but if one person oversees and ensures that it all works together, you don't have to sacrifice the solid vision.

      I would love to see something come out of this discussion, if it's a published book, I would definitely buy it. If it's a library, I would enthusiastically follow, test and, if possible, contribute.

      I think I've rambled on for long enough, I'd better get back to fixing this bug now...

  5. my god sometimes I think people are reading all the same blogs I am reading :p

    I think the problem with the open source projects is that they get bloated yoo fast. People try to build them up into a all encompassing solution instead of using the as they are. If you can build a simple environment and keep it simple , while allowing people to add extensions that enhance the output THEN you would be able to build something great.