Project Frontier #1: Getting Started

  By Shamus   Jun 6, 2011   113 comments

I’m still sulking about what happened to my book. In the interim, I’ve decided to do some coding. Remember project Hex? That was this thing:

hex_edges15.jpg

I liked the way the first stages of project Hex turned out. While a few people had artistic criticisms of it, the idea and the implementation were solid. I want to try the same thing, only making a more conventional first-person style engine. This is far more ambitious. Here are my new goals:

  1. Use the established pixelated, quasi-8-bit graphics.
  2. The world should be vast. Maybe not Minecraft “bigger than the actual Earth” sort of vast, but big. Basically, I want to be free to adjust the size of the world based on what seems “fun”. Maybe this will be Fuel-sized. Maybe smaller. But I need to design this engine with the idea that it should be able to handle lots and lots of data in bulk.
  3. Procedurally generated world. Because that’s my thing.
  4. Variety. I don’t want ten thousand square miles of same-y terrain. Lots of different lighting, coloring, texturing, topography, etc.
  5. Decent view distance. The world should feel vast.
  6. Should run acceptably on old hardware. (For now, this just means keeping the GPU, CPU, and memory usage low. Whether it actually runs well on old hardware is another matter, but I want to make sure I don’t cut off low-end machines by design.)
  7. It should be as platform-agnostic as possible. Okay, I’m working in Microsoft Visual Studio 2010, so this is Windows native. But I don’t want to load up the guts of my engine with Microsoft-specific code. I’ll be using SDL, and OpenGL.

This is much too ambitious. It’s a starry-eyed pipe dream, doomed to failure. Let’s get started.

I spend the first couple of hours ripping the hex-based logic out of project hex and building it up again based on square grids. I also rip out the cheapo RTS-style camera and replace it with a proper “flycam”.

frontier_start1.jpg

You know, I don’t like to add visual gloss until I have the underlying system working right, but right now it’s hard to see the topography. So, I drop in some basic lighting. Note that this is using the standard OpenGL lighting model, nothing fancy. I have no idea how my lighting system will work long term, but this is good enough for now. (See this post for a bit about what I might have to deal with if I decide to make my own lighting system.)

frontier_start2.jpg

It seems to have lost a great deal of its charm in the move from overhead hex map to where we are now. It’s less cartoon-ish and vibrant. We can worry about that later. Note that my hills are now generated by sine waves. Those suck. Let’s fix that.

First up, I import a few blobs of hill-types smears that I doodled by hand:

frontier_start4.jpg

Compared to the sine wave hills, these are much better still completely awful. Hills are not shaped like noise. Hills are not usually shaped like domes. (Unless they are small or man-made.) On any kind of respectable scale, erosion has its way with the land and the sides of hills end up shaped sort of like tree roots. It will have arms that reach out, with steeper sections between them.

The easiest way to achieve this is to run an erosion simulation on it. No, really. Erosion simulation. Just a bit. What you do is this:

  1. Pass over the map one “pixel” at a time, performing the following process on each space:
  2. Drop an imaginary water droplet onto the current space.
  3. Now look around, and see which of the neighboring spaces is lowest. Move the droplet to that space.
  4. Every time the droplet moves, chip a bit of elevation away from where it was.
  5. Once the droplet arrives at a space where it can no longer move down, abandon it and drop the next one. Repeat until you’ve passed over the entire map.

There’s a quality vs. performance cost associated here. It’s better to pass over the map many times, taking only a slight bit of land away with each pass. But if you’re in a hurry, you can run over the whole thing just once and take a bigger chunk away. The land ends up looking a little “jaggy” when you do this. The slow way gives much more realistic erosion shapes.

Simple. Cheap. I’ve done this sort of thing before, and I can say that erosion systems are very prone to oversimulation. You CAN write one that takes into account sediment, and the different ways in which rock and dirt erode, and the effect of flowing water on steep slopes as opposed to gradual ones. Likely as not, it will be tough to balance those behaviors well enough to produce useful results, but if you DO manage it, you’ll end up with geography that looks 10% better than the cheapo system I outlined above. If all you need is a bit of topography that can look presentable, then there’s no reason to waste your time and CPU making a deep simulation.

The result?

frontier_start3.jpg

Eh. Better than a poke in the eye. The world is still set to a (small) fixed size. It loads up all the data at startup, and displays a fixed-size world. Next time we’ll add paging so it can build the world as we go. And maybe do something about it being so dang ugly.

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


  1. rrgg says:

    Are you going to make a version with squares too or just hexagons?

  2. MaxDZ8 says:

    It’s fairly good looking.
    I am always amazed by how much simple vertex lighting can improve the scene. Compared to that, even the fanciest lighting techniques miss something.
    But I don’t recall what kind of game you’re building. I take it is a surprise?

  3. Randy Johnson says:

    Awesome, I have alot of freetime, wish I had studied harder and taken programming instead of networking so I could put my free time into fun things like this

  4. Kell says:

    Shame about the book problem, but it’s good to see the engine projects again.

    If you need help with terrain textures, drop me an email ;)

    • Daemian Lucifer says:

      Seconded.

      The book project would be more fun if we had snippets of it while its in the works.Now its just this boring thing that will be exciting sometime in the future.And who cares about the future?

      • Henebry says:

        The book is probably too far along to do this now, but it would be interesting to read a build-a-book blog, where the author offers snippets along with his thoughts about plot design, characterization, etc.

        In fact, Shamus, you might find this a more congenial development environment for writing a book than the “one man working alone” model you chose.

  5. X2-Eliah says:

    As for the cuteness visuals, well, the standard thing to do would be to drop black/dark cell-shading lines on intersections/borders, and to make the colours more primary and bright.

    You could perhaps try making it truly brown – like, only using shades of brown, that could be unique for an indie project; because while brown is the de facto colour of aaa games, simple & bright primary colours is the area where a whole ton of indie games fester..

  6. Exetera says:

    Yay, more coding projects!

    What would a good input data source for an erosion simulator be? Perlin noise? Is there a good way to simulate for road cuts (ie. roads in the side of hills) with this method? Also, why not go back to the Terrain Project code rather than starting with Project Hex?

    • Shamus says:

      I’ve found almost anything works as input data, with a few qualifiers:

      * If you’re using a very regular surface (like, spheres or sine waves or something) then add a sprinkle of very mild noise. Using my cheapo shortcuts, a perfect dome will end up being eroded perfectly evenly. The noise will break that up.
      * The cheap method isn’t smart enough to erode bowl-shaped depressions, so if your input data has lots of craters it won’t be smart enough to fill them in.
      * It’s not very useful with exceptionally STEEP hills. Sheer cliffs and such won’t really erode very much.

      Other than that, the thing I described above works very well. Given enough passes and a large enough data set, you’ll see “river” valleys and tributaries form.

      • Peter H. Coffin says:

        You can probably smarten the simple drop just a little and gain the fill-in you’re looking for by maintaining a counter of the erosions the thing has done and dropping it when the drop evaporates (gets abandoned at the bottom of a depression). Drop some on the hex it stops, eating some to account for leaching and distributing the rest to the surrounding hexes. (25, 15, 60 (10 to each hex)% seems like a good point to start playing.)

      • Exetera says:

        Hmm… I tried to implement an erosion simulator similar to this one, but I seem to mostly be ending up with a lot of very deep, tightly-spaced 1-pixel-wide crevasses and no interesting large changes to the geography. Any suggestions on how not to get that?

        • krellen says:

          Make your erosion size larger than one pixel.

        • Shamus says:

          Hm. Hard to debug via comments, obviously, but here are a few suggestions:

          * Take very small bites. Anything more than a percent is a lot.
          * Make a copy of the table with each pass. Look at the original values, store the changes in the copied table, then copy them back when you’re done.
          * When checking neighbors, check all eight, not just the four direct adjacents. (Basically, drops should be able to go diagonal.)

      • Zak McKracken says:

        Oh, just a thought: have you tried using the “Blue Marble” data from NASA?
        They’ve got pretty hires elevation data to go with it, too.
        If you don’t want to have actual Earth terrain, you could always cut chunks out of it and overlap them or blend them together. For example using enblend, which is usually used on panorama images and is quite good at hiding the seams.

        Gaah, I just had the idea to test that out myself, mustn’t do that, have no-fun work to do :(

  7. MDCore says:

    Nice to see you coding — and blogging — games again!

    This is much too ambitious. It’s a starry-eyed pipe dream, doomed to failure. Let’s get started.

    A crash-and-burn with screenshots, my favourite.

    • Steve C says:

      You’ve written some good lines on this blog. This is definitely one of them:

      This is much too ambitious. It’s a starry-eyed pipe dream, doomed to failure. Let’s get started.

  8. Lachlan Stuart says:

    If you’re interested the polygonal/non-tiled landscape generation, I just came across this guide, which seems to be very comprehensive.

  9. sab says:

    I miss the water tiles! :'(

  10. S. Richmond says:

    This smells like Michael’s project at Sea Of Memes. I also noticed you’ve stopped commenting on his work.
    I suppose there is nothing wrong with that – I almost jumped in and wanted to have a go myself. And I suppose you ARE working more on procedural programming where he has still only worked on the engine.
    But even so, I grow tired of smart individuals like yourself wasting time reinventing the wheel by making a poor attempt at building an engine from scratch. Michael made the same mistake spending months trying to make his engine completely cross-platform with directX and several versions of OpenGL. Stupid idea. You and him both want to develop a game, not an engine. So don’t spend 6-12 months on a feature like that.
    We all know you really only want to work on the cool stuff – Procedural environments. It is, incidentally, your forte and our entertainment. You’ve also yourself expressed the fact that its a ridiculous pipe-dream to develop such a project from scratch.
    So you’re going to eat your own words and you are going to download Michael’s open source engine – It has everything you need whilst still small enough for you not to get lost of code caves – Its got object streaming, lighting, transparency, vast worlds, procedural Level of Detail, and its OpenGL.

    This is final. No more wasting WEEKS on the black hole that is graphics programming.

    • Drexer says:

      Huh no? There is quite a difference between what Shamus wants to do(create a procedural first person world with polygons) and what Michael has done(create a world from a cubic matrix stored to the disk). The render is completely different and the only things that Shamus could cannibalize would mayhaps be lighting and related resources, and for that he can easily use the OpenGL versions and he will have the advantage that a code built by himself will be easier to understand by himself.

      You could argue that he could use a realtime graphics library such as OGRE or something, but seeing as his objective is world building; he’s pretty much limited in that all the main work on his world generation will have to be done by himself.

      Most of the points of those exercises in programmings come from the desire of people to try and do those things in particular, and learning while they do so. Using a pre-made procedural world engine and working on filling it with triggers to create a game would be nice, but nowhere near the learning experience that is wanted.

    • Shamus says:

      The thing is, you CAN’T use an existing engine if you want to get anywhere NEAR the list of goals I stated above. NOBODY outside of Asobo has done a thing with procedural large-scale terrain. Most engines are designed with the “Level Builder / Game Engine” mindset, that that’s completely incompatible with what I need to do.

      • mike says:

        I agree. I totally love what you’re doing here.
        It’s cool to see things come full circle. I started reading your blog because of the terrain program you were blogging about years ago. Totally awesome, dude. Keep it up!

        I’m working on a large scale procedural terrain project too, but I’m not as confident as you are so my blog remains void of anything related to it.
        I based my generation on an icosahedron, and subdivide it to get a high resolution sphere, then I run a deform and erode function to make it interesting. The erode function is also responsible for filling the oceans, lakes and rivers…. It takes a while to generate a world.

        • Kaeltik says:

          I’m working on a board game that requires objects that are made of many triangles move over the surface of a sphere. The sphere is represented as a skinned and subdivided icosahedron. I’m having a hell of a time figuring out what to do when a sixfold object moves over the fivefold vertices of the icosahedral projection (slices either get lost or displaced in odd ways).

          Do you have any advice?

          • mike says:

            Hmmm… That could be a complicated problem. I think I see the problem.
            I’m not sure if you are unduly constraining yourself to the mesh generated by the subdivisions of the icosahedron.

            It sounds like you probably want to project your object mesh onto the icosahedron surface, rather than use the icosahedron surface to give you your mesh.

            This way, your object mesh vertices will rarely line up exactly with those of the ico/sphere surface. However, you shouldn’t have any problems with faces disappearing.

            Does that make sense?

            (Sorry if I’ve misunderstood what you are trying to do. Let me know, and I’ll try again).

            Edit: One more thing: do you consider the origin of your object as a vertex, or as a face? This could modify the behavior.

            I also just realized, the above is probably not a solution to your board game problem. You probably want an object to occupy a specific shape on the field (hexagon made of 6 surface triangles, for example).

            There should only be 12 points in the mesh that concern this problem (the 12 original points from the icosahedron) which are an intersection for 5 triangles. All other points should be an intersection for 6 triangles.

            A non technical solution for your problem would be to make those 12 points illegal space. You could design a game mechanic around them to justify the change.

            • Kaeltik says:

              It looks like simple triangular tessellation for more spaces will not work due to aberrant vertices like the fivefold in the icosahedron. The game mechanic precludes illegal vertices.

              I may try to make the “spaces” the vertices of an Archemedian solid, something like a rhombicosidodecahedron or a snub dodecahedron. At least then there is some assurance that all “spaces” have the same number of neighbors. (Archimedian solids are isogonal)

              What do you think?

              • Kaeltik says:

                Actually that didn’t work. The Archimedian solids are vertex-transitive (isogonal), but not face-transitive. I thought that wouldn’t matter, but it looks like it does. Their duals, the Catalan solids, also don’t work. They are face-transitive, but not vertex transitive. Looks like I need both.

                Only the Platonic solids satisfy both, so we’re back to the icosahedron.

                Maybe if movements are expressed as rotations, like geologists do with continental drifts, and if tessellations within the faces of the icosahedron are restricted to move together? We’ll see.

      • Hitch says:

        You probably could use an existing engine, provided you did enough work bodging together special routines to force it to do what you want. Which would end up taking just as long as building it yourself from scratch. Of course, that approach would probably have the added disadvantage of not keeping your interest nearly as much as designing your own system by yourself.

      • Scott Richmond says:

        I agree, yet I disagree. The only standout goal you have listed is procedural worlds. If you intend to generate the world before the game begins, and don’t intend to have the world continue to change in big ways, then pretty much any engine will suit. This is akin to that game Fuel. If, however, you plan to make a procedural engine that streams in the world as you travel or changes a lot in-game, then you of course need a more custom engine…for which Michael’s engine can do.
        Its called scope, which I’m sure you don’t need to be told about.
        I just want to see more blogs on cool procedural stuff rather than some procedural stuff + some rant about some graphics library or algorithm that you can’t get your head around.

      • Roll-a-Die says:

        Ehm no offense Shamus, but, wha, Daggerfall, Arena, both were literally 10 times as large a Fuel. Daggerfall moreso than Arena strangely.

        It’s just older, and thus less detailed.

        Fuel 5540 mi2, Daggerfall, 62,394 mi2. Admittedly most of it was barren, but still, it’s a firm example of how large games got back then. It literally necessitated the fast travel system seen in oblivion.

        • Shamus says:

          I don’t see how that undercuts my point at all. Daggerfall was 15 years ago! I think that pretty much makes my case that almost nobody is working in this area right now.

        • mike says:

          I’m a huge TES fan, and have all the games boxed sitting on my shelf in my office (at home). But I digress.

          One interesting thing about Daggerfall: the terrain heights are based on a height map, but the details use a simple noise algorithm, seeded with the x+y coordinates* of a point combined with a roughness value (provided from other game data) to add higher resolution to the terrain on the fly.
          * or some similar seeding method. I’m not sure.

          When a city or town is placed in the world, the noise modification is turned off for a rectangle the size of the town.

          I’ve seen this bug out a few times, and the towns end up with noisy terrain rather than flat.

          Sorry for the random side track. :-P

          Oh, right. The point I was going for was that the height map for Daggerfall is tiny when compared with the size of the world.
          If you can be bothered doing the math: the dimensions of the Daggerfall height map are 1000×500.

          • Roll-a-Die says:

            One of the fun things about the DaggerXL Project/XLEngine, he’s gonna make enhancements to the reimplemented code to add more variance and things like that.

    • mike says:

      -1
      Edit: I guess I should be more constructive, huh?
      I can totally understand your point of view, but I don’t think the tone you expressed it helped.
      I have to agree with Shamus’ choice though. Building something on this scale is never going to be easier if you take some other code you’ve never worked with before. It’s complicated. It doesn’t follow your coding practices. It probably isn’t designed to fit in with your concepts and methods.
      Above all, it’s often very confusing wading through another persons code for the first time.
      You could compare it to visiting a foreign city without a map and being asked to design the new bus routes – and you don’t even understand the language, or the road laws. Not all the time, of course. But it can be that bad and worse…

      • MichaelG says:

        I agree too. I have done some procedural stuff, but I’ve concentrated so far on just rendering the cube-based stuff I copied from Minecraft efficiently.

        In addition to putting up with my unfinished areas, my bugs and the complete lack of documentation for my framework, Shamus would still need to write all the code he’s writing now. SDL is what he’s used to, so there’s no point in switching to another framework.

      • Scott Richmond says:

        I can agree with that. But thats why I mentioned Michael’s engine – Its small and almost all of his code is exactly what Shamus needs. There is little to no code bloat.

        • Drexer says:

          Here’s the thing though. What does Shamus need from Michael’s code?

          The graphics part? As you can see from above it’s pretty much already made and seeing as Shamus probably won’t be bothering with transparency that soon,Michael’s latest advancements wont be that worthwhile.

          The WASD implementation? That part is relatively trivial and a secondary need for what Shamus wants, he’ll probably work in fly-overhead mode while developing.

          The world generation? Michael from what I know hasn’t done anything in the vein of what Shamus wants and that might be useful to him.

          Seriously, I know that over-development is a problem; but expecting that Shamus just needs to grab a code for something completely different and easily get it to make what he specifically wants is one of those things that just doesn’t work that way…

  11. UtopiaV1 says:

    Glad you’ve decided to take this up again, I liked the way it was going before. Hopefully you’ll end up with something just as good as your procedurally generated city, and maybe even construct a rudimentary game around it. Some kind of TBS maybe, should be easy enough to do (without ai, of course).

    Looking forward to seeing where this is heading. Realistic terrain has always been a bit of a pipe dream in most games. Really puts the ‘valley’ in ‘uncanny valley’… eugh, that was terrible.

  12. Slothful says:

    Nice to see this old thing again.

  13. Simon Buchan says:

    Was Hex just an experiment in generating hex maps? I got the impression you were planning to do more with it. Not that I’m complaining if it means more coding posts!

  14. Micah says:

    YAY!!!!!!!! Finally getting back to your projects… which happens to be the reason why i found your blog in the first place :)

    @ richmond… you know you don’t have to read them if you don’t want to. I for one love watching the projects form from very basic to very awesome. plus you can’t compare Shamus to Micheal. while both are excellent programmers Shamus has more experience with 3D graphics/game development and i doubt that he would have ran into as many issues as Micheal has just based of that experience.

  15. CTrees says:

    As long as the hills are at least as realistic as the ones in New Vegas you’ll

    No, can’t finish that. Even I’m choking, thinking about them.

  16. mike says:

    That’s a great start Shamus! I’m really excited to see where this goes.

    I’d love to see the eroded height map, just to get a better feel for how your initial algorithm is working :-)

  17. Jarenth says:

    Damnit, Shamus! Stop embarrassing the rest of us!

    You’re taking a break from writing the Great American Novel to code an engine for the most ambitious FPS project this side of E3? Why not plan a moonwalk too, while you’re at it?

    I swear, Shamus, I really love this blog, but you’re putting a lot of strain on my ability to rationalize away the fact that I’m doing essentially nothing productive at the moment.

    Also good luck I guess

    • Naota says:

      Yeah, seriously Shamus. Think of the rest of us here and the unmitigated woe you are inflicting.

      “So Naota, what did you do this week?”

      “Well, you know… a bit of writing. I’m hoping to manage one LP update, maybe a post about random stuff. Maybe I’ll finish off that resume. You know, productive stuff.”

      “Oh, neat! Shamus just did the groundwork for a procedurally-generated FPS. As a break from writing a full novel. While between jobs, perhaps as a job.”

      Look at what you’ve wrought – I’m talking to myself with text!

    • Alexander The 1st says:

      Hey, you posted on Shamus’ blog. If nothing else, that could be considered productive by osmosis…

      …Right?

      • Jarenth says:

        I wish I could use Krellen’s ‘reading this blog counts as keeping up to date with tech advances’, but I’m currently an interface designer. So that might become a factor later on, but right now, this is pure self indulgence.

    • Sekundaari says:

      Wait – where do you get FPS? Might be an RPG, some first person adventure, sports or anything. Survival strategy?

      • Alexander The 1st says:

        Survival Horror?

        That could be an interesting attempt – it’s all colourful and all, but if Shamus can make it scary, that’s an achievement.

      • Naota says:

        Evidently I meant a First-Person Somethingorother – the most underutilized of genres.

        Seriously though, first person games that aren’t primarily about shooting/stabbing people are a rare breed, and lamentably so – some of the very best games fall into the category. At the moment Thief, Amnesia, and Mirror’s Edge are the only ones I can think of.

          • Naota says:

            Aha, I knew I was missing something immediately and rather painfully obvious in my list. Mirror’s Edge had some quirks and hangups, but it was really pretty and when it worked I felt there was indeed some of that new-premise-being-fun magic at work.

            Aside from that, all of the other examples are extremely well-received by gamers, yet probably didn’t sell all that well compared to the unambitious and generic shooters of the day. Case in point: I’ll bet Gratuitous Exhibition of Anatomically Ridiculous Spectacle 3 does loads better than Portal 2, but it’ll be Portal which gamers will remember for years to come.

        • Ingvar says:

          Do tanks count as “people”? Because that’s what you fired at (in a terrain populated by platonic solids in lieu of plants) in the one “first-person-view” game wot I have written.

    • Irridium says:

      Speaking of E3, there was a Mass Effect 3 gameplay trailer. Mass Effect 3 now uses Kinect. The Kinect function will let you order your team(sounds kinda neat actually), and pick dialog choices(is actually kind of stupid, since now when you say something, and Shepard says something completely different, now your REALLY pissed that what you read is not what is said. Example: “I’m not interested in her trust” = “I’m Commander Shepard, Alliance Navy”)*.

      Also, now your Omni-Tool can turn into a knife so you can punch people with it.

      I’m not joking, or being sarcastic, or embellishing anything. Not even a little.

      Go and watch for yourself if you don’t believe me!

      *This actually happened

      EDIT: Oh, And the EA press conference just started. The ME3 gameplay preview for this one was Shepard fighting another Reaper on the ground. Or a machine that worked for the Reapers. Or something. I don’t even know.

      • krellen says:

        My brain hurts.

      • Klay F. says:

        When I saw Shepard shooting that thing that looked like a reaper with a machine gun mounted on a truck I almost died laughing.

      • Jarenth says:

        This work PC I’m currently one has, like, half a functioning video codec installed, and no sound to speak of. So for the last five minutes, I’ve been watching a confusing, glitching mess of colourful silent static, occasionally punctuated by glimpses of either a bored-looking man in glasses or images of Captain Space Biff, Alien Puncher Extraordinare.

        I like to think I got the better deal here.

  18. James says:

    out of curiosity how is the world going to be walled off, its got to have an edge even like in MC you only find the top and bottom edges, impassable marches?, forests, make the map a large island surrounded by water?

    also once built how about using the engine to host a simple game? im sure some people here can help with that? then we can review it and say mean things about it and you? (thats a joke btw, the review not the idea, a game with an engine made by Shamus Young is obviously going to be good. cant be any worse then Gamebryo)

    • Alexander The 1st says:

      Hmm…that could be an interesting project. Plop Fallout: New Vegas onto Shamus’ engine instead of Gamebryo.

      Couldn’t make it any more buggy. :p

      • James says:

        it might even have more then 3 colours. and somehow fix the fact Melee is OP (who needs to balance a single player game eh?) and ranged is just so forgotten about.

  19. RTBones says:

    Ahh yes – that project doomed to failure to put the Book Angst Energy into. It’s got to go somewhere, right? Fabulous.

    I’m actually glad to see Hex resurface, as I had wondered what had happened to it. Reminds me of a project from back in the day. I did some DTED (digital terrain elevation data) work for a simulator I worked on. In my case, I was looking for the correct spot to draw a graphic on a CompuScene IV in real-time.

    I should also say that when I first read this post and saw the screen capture with the hexagons, I was immediately reminded of the map from the World of Greyhawk boxed set (my copy of which sits gathering dust in a closet).

  20. Brandon says:

    Does this mean Project: Hex is done? That makes me sad… I was hoping for a turn-based strategy game, or at least a framework for one, to come out of it. There’s a great open-source TBS called Wesnoth, but it’s editor based. I was hoping for a procedural TBS out of Project: Hex.

    • Xpovos says:

      Similar, sans Wesnoth reference. I liked the look of the old Hex because it got away from the FP feel that is so bland and unfriendly for me.

      But, I’d rather see the project back in some form than not at all.

  21. Jeff says:

    I think there’s an inherent jump in difficultly from world generation to level design.

    A TBS where one side gets all the resource tiles would be unplayable, even if the map was realistic. A FPS needs to worry about lines of sight and cover, vs AI ability.

    I look forward to seeing how Shamus goes from procedural world generation to procedural level design.

    • Kaeltik says:

      What if these factors could be scored in some way and hardpoint positions automatically chosen for balance?

      Assuming that you’re referring to a fortress assault model, maybe one side would end up closer to 60% of the resources, but have poor cover in transit, or too many lines of approach, or somesuch. Would obviously require a great deal of play testing or simulation in order to find the right balance of factors.

      • Jeff says:

        This occurred to me, but that’s generally a TBS thing. I imagine it’s easier to generate balanced maps for TBS than FPS games, because it’s a lot harder to get a good map layout for FPS when you don’t have balanced components that a TBS AI can judge.

    • mike says:

      Interesting points!

      Here are a few thoughts that come to mind:
      If you take a look at the way maps are generated in Diablo (I’m not sure about the later versions / releases) the maps are procedurally generated with room sets, and adjoining corridors, etc. Important points of interest use hand-crafted map segments – but they are spawned and random points in the map.

      Also, take a look at most rogue-likes. They use many different methods to generate interesting and fair maps.

      Depending on the method used to generate a map, you can be certain that every area is accessible. Other methods may require running a simple algorithm to test that all areas are accessible (flood-fill for example).

      There are also a variety of resources available for people interested in generating procedural content which is challenging and “fair”.

      That being said, I’m also really interested to see how Shamus will approach the problems you outline. I have a feeling that may be a little way off yet… but who knows?

  22. BeamSplashX says:

    Dear Shamus,

    When I’ve got that feeling, I want hexual sealing.

    Regards,
    Sid

    P.S. It reminds me of Outcast’s environment with sharper edges.

  23. Akhier says:

    Nice to see you doing another coding project. I have enjoyed the others you have done and hope to enjoy this one as well. Good luck!

  24. Platform-independent, not platform-agnostic.

    I’ve been seeing this misuse of agnostic pop up a lot in the last year or so, and I thought I’d point out just how silly it is.

    Agnostic stems from the Greek a and gnostos (known). It essentially means unknown or unknowable. To call a game or piece of software platform- or system-agnostic implies that the game or software is somehow unknowable to the system or platform. Or perhaps that the platform is unknowable to the software? This is completely different than the intended meaning that the software be able to run equally well on any platform without special tweaking. Platform-independent isn’t exactly perfect for that either (it could be taken to mean the software runs without a system), but it is far better than platform-agnostic.

    Please forgive the didactics.

    Q

    • Exetera says:

      I think that “platform-agnostic” is supposed to mean that the application does not know what platform it is running on… which is correct, for SDL applications, as SDL apps should only access the functions available in the SDL library and not care what platform they’ve been compiled for.

    • Shamus says:

      Yeah, Agnostic was the wrong word. I didn’t want “platform independent”, which implies a complete freedom to move to any platform. I want more “platform neutral”, in the sense that while it is ON one platform, it doesn’t have any strong alignment towards it.

      Platform non-partisan might have worked, although it’s a bit cumbersome.

    • Simon Buchan says:

      One of the features of code that is often used to determine how well designed it is, is how much it “knows”, the more it knows, the worse it is. Here “knows” is what facts it depends on, such as whether a string ends with a null byte, or has an explicit length stored before the start. If it works with both, then it is “agnostic” to string implementation, because it works with both, *because* it doesn’t know which. It is possible to work with both by knowing both implementations, in which case it is still “portable” across those string implementations, but when you end up with some other implementation (a start and end pointer into a larger buffer, for example), you need to change it again. Therefore, being “agnostic” to something is, all else equal, prefereable to being “portable”.

      Now all that is defined, I have to play devil’s advocate and say that complete platform independance is silly. For the majority of OS services: heap, filesystem, threading, networking, process control, basicly everything but graphics, there are two implementations you will ever care about: Windows, and POSIX. Now with C++11 close to final, we will get pretty much all that in the standard library as well (yay!). With such easily isolatable services, with so little reimplemention, Doing It Yourself is really not very hard at all, and means you get a much simpler debugging experience, and faster and smaller code. Take a look at the Chromium source to see how they do platform code, it’s surprisingly easy.

    • K says:

      Let me offer a decent example: Java. If you write Java code, you have no clue about the system below, because all your stuff is sandboxed inside a VM. So, platform-agnostic.

  25. Joe Cool says:

    Aw, I was looking forward to the gameplay part of Project Hex. I wanted to know what the turn-based gameplay was going to be like. What cool or unique little mechanics did you have in mind?

  26. TSED says:

    Sadface.

    My friend and I have been working on an RPG project for a while, and our programmer flaked out. We wanted something VERY similar to what you outlined and are now turning Hex into…

    So, yeah. Sadface.

  27. SatansBestBuddy says:

    I suppose this will be the series where Shamus learns that artists really are important parts of game design?

    Cause there’s a reason most companies would rather hire 100 artists to make hills all day than have 100 coders write a program that can make as many hills as humanly possible.

  28. chaz says:

    I love to see this kind of stuff on your blog. I hope you’re managing to maintain an adequate income from your many projects. If there is any fairness in the world someone will recognise your unique mix of talents and start paying you properly to do this kind of stuff. It was a joy to see Jason Scott from textfiles.com get sacked and end up in his dream job as a result. I’ve still got my fingers crossed that the same will happen to you, but I’m not sure you have the same talent for self-promotion.

  29. Goatcathead says:

    Minecraft with hexagons. great

  30. confanity says:

    As a non-programmer I’m always fascinated by your explanations of the process, Shamus, so I’m anticipating lots of interesting stuff coming out of this project. And nobody in their right could ever accuse you of being a slacker, given your output.

    But in my experience, you have to be very careful about allowing yourself this kind of sulk regarding the book: the more time you set it aside for, the more time you have to forget all the stuff you lost, which can be a big dose of discouragement when you finally decide to sit down and start working on it again. I would recommend getting back on the horse as soon as possible, even if it’s nothing more than forcing yourself to rewrite a single paragraph or redo a few pages of reading and editing. The longer something like this languishes, the harder it can be to pick up again — unless of course your predictions of doom in the programming project are sincere and you’re expecting a surfeit of frustration to eventually force you back to writing?

    Either way, of course, best of luck, and I’ll be looking forward to seeing what you produce. 8^)

  31. Alex says:

    Well, I’m impressed at least. For something one dork is doing in his spare time and is mostly therapeutic coding-for-the-sake-of-coding, it’s not lookin’ too shabby so far.

    And if it makes you feel any better about the book, Shamus, some great things have followed after staggering setbacks. Ernest Hemingway lost a lot of his early work in a piece of luggage in 1922(BEFORE “A Farewell To Arms” and “Old Man and the Sea”). And in the music side of things, a hard-drive crash is all that stands between our timeline and one with a completely different soundtrack to Chrono Trigger.

    I know how discouraging it is to lose that much progress so quickly, but I’m sure it’ll still be worth it if you get back on that horse someday.

  32. WWWebb says:

    Did you ever take Yahtzee’s recommendation and check out Just Cause 2? It’s certainly not procedurally generated, but they did manage to pack a large variety of terrain. Of course, having deserts, rain forests, swamps, large cities, snowy mountains, river valleys, and lots of ocean that close together certainly isn’t realistic (imagine Hawaii shrunk to the size of Rhode Island), it makes for good fun without having things so far apart as to make travel boring.

    My only complaint is that there isn’t a “tourist mode” that takes away everyone’s guns and allows me to enjoy the scenery without being shot at. I think Rock Paper Shotgun covered it best: http://www.rockpapershotgun.com/2010/04/02/postcards-from-panau/

    Warning: The world is still plenty big and the “fun density” is high enough to easily get 100+ hours of gameplay even if the “campaign” portion takes less than 10 hours.

  33. Did you fix the accursed ‘slopes problem’ from Project Hex in the transition out of hex tiles?

  34. Jaerys says:

    What’s your opinion on OpenGL splitting it’s specification into core and compatibility profiles? Do you feel that new code should comply with the core profile, or do you see it as more of a guideline? I assume you’re using the fixed pipeline since you mention OpenGL’s lighting model, but that might just be a placeholder. I know it’s a silly question since hardware support for the compatibility profile isn’t in danger, but I’ve had the core profile on my mind lately.

    I’m actually not a graphics person. I’m one of those people that learned to code in immediate mode and never learned how to optimize, so I’m converting an old class project to core to try to force myself to learn to do things the right way. It’s been . . . rough.

    Anyway, seeing personal projects like this helps. It’s a bit discouraging that the problems I struggle with are so minor compared to what you’re doing, but it does keep things in perspective.

  35. […] on another note, I hate Shamus. More specifically, I hate Shamus Young. His project, Project Frontier, has been about building a terrain engine of sorts so far and though I’m not sure what his […]

  36. […] (and the idea to blog about the process) was inspired by Project Frontier, a fascinating project by an experienced graphics programmer who is making far more interesting […]

  37. […] Project Frontier by Shamus Young […]

  38. […] around, and more posts will be forthcoming. Especially now that: a) I have my computer back, and b) Shamus Young and Michael Goodfellow are making significantly more progress than I on their procedural generation […]

  39. Hi! Your hobby work is similar to mine. Maybe we can talk about it. Have a look at my blog: gdevice.blogspot.com

  40. […] we have Shamus Young at Twenty Sided Tale, with his Project Frontier world.  His goal is to create an interesting, varied world using procedural content.  He’s […]

  41. […] my journey I definitely want to say that my inspiration for this project is Shamus Young and his Project Frontier series. His entire blog is excellent, but when he blogs about his programming projects he’s […]

  42. […] by Shamus Young’s Project Frontier series, I decided to make a game of my own. But since graphics programming is a strange and […]

  43. This new found desire may fade as a result of the persons
    goal becoming more challenging and time consuming. This can help uncover any
    issues that may be demotivating to team members.
    But when it comes down to it you must find it in yourself to
    push yourself to achieve your goal.

7 Trackbacks

  1. By Quickie! – Steve's Dev Diary on June 15, 2011 at 7:41 am

    […] on another note, I hate Shamus. More specifically, I hate Shamus Young. His project, Project Frontier, has been about building a terrain engine of sorts so far and though I’m not sure what his […]

  2. […] (and the idea to blog about the process) was inspired by Project Frontier, a fascinating project by an experienced graphics programmer who is making far more interesting […]

  3. By Development Diaries « Corner Piece on July 13, 2011 at 9:12 am

    […] Project Frontier by Shamus Young […]

  4. […] around, and more posts will be forthcoming. Especially now that: a) I have my computer back, and b) Shamus Young and Michael Goodfellow are making significantly more progress than I on their procedural generation […]

  5. By Procedural Worlds | Hot-Pink Monkey Socks on October 17, 2011 at 8:53 pm

    […] we have Shamus Young at Twenty Sided Tale, with his Project Frontier world.  His goal is to create an interesting, varied world using procedural content.  He’s […]

  6. By Plext – Intro « Rather Hard Work on January 4, 2012 at 1:43 am

    […] my journey I definitely want to say that my inspiration for this project is Shamus Young and his Project Frontier series. His entire blog is excellent, but when he blogs about his programming projects he’s […]

  7. By Plext: Intro « Rather Hard Work on January 4, 2012 at 1:50 am

    […] by Shamus Young’s Project Frontier series, I decided to make a game of my own. But since graphics programming is a strange and […]

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="http://en.wikipedia.org/wiki/Darth_Vader">Darth Vader</a> on Wikipedia!