Alex Saint Croix

Starting to work on 2nd gen terrain smoother.

This is essentially where the rubber meets the road for me. I’ve gotten back to the point I was at in Java, with all of the functional power of Scala at my disposal, and a completely redesigned TileForm library. Now it’s time to write the new terrain smoother.

Wherein game design drives software design

Game designer Alex: It's not a simulation.  It's a game.  The player should be able to modify the terrain, and that means keeping the choices limited.  We're not shooting for photorealism here.
Game programmer Alex: Okay, I ran the numbers and there are 175 types of tileforms available, roughly 45 for each direction.  Some of these are duplicates.
Game designer Alex: 175 is too many choices.
Game programmer Alex: It's worse than that, actually. There are also 38 types of tileforms that can be drawn two different ways, depending on if you want them to be a valley bottom or a ridge top.
Game designer Alex: That's almost 200 tile types.  TOO MANY.  Can we limit the number?
Game programmer Alex: Well, we can.  At the cost of realism.
Game designer Alex: Realism? It's a GAME.  The last 2D isometric game I played didn't even have hills.  It just had art that sort of looked like hills.  The map is not the world, my friend.
Game programmer Alex: I can limit the possible positions for surface vertices to TOP, UPPER, and LOWER.  Take out center and change the heights to one-third increments instead of one-quarter increments.
Game designer Alex: So, there will only be flat, lazy inclines, and steep inclines?
Game programmer Alex: Yep.  And vertical cliffs like before.  You lose one of the incline types, but you also reduce the number of possible tiles from 175 to 65.
Game designer Alex: That's roughly 16 for each direction, or 8 of each direction counting diagonals.  How many of those funny ridge / valley cases do we get if we reduce to thirds instead of quarters?
Game programmer Alex: 12.
Game designer Alex: Down from 38. I'm not sure.  Let me make some phone calls and see what others think.
 ...
Game designer Alex: Yep.  I think 2 different slopes is enough for our purposes.  Make it happen.
Game programmer Alex: o7

Eye candy for Isographer, Isometric, Java, OpenGL, Rendering, Terrain, LWJGL,

After a great deal of refactoring, and building a unit testing harness with JUnit for the project, I finally implemented “diagonal hilltop smoothing”. This feature makes a second pass over the terrain and identifies locations that could benefit from a slope inversion. So, instead of “down and then over”, the hilltop pieces move “over and then down” in a diagonal direction. As you can see, this gets rid of a lot of the unnatural “scaling”, where there are diagonal rows of rounded corner bottoms on interior curves of the terrain.

Not all cliff edges are meant to go away. If that were the goal, I’d just make a surface mesh. I want impassable cliff-like edges between certain tiles. Next I’m going to work on improving the appearance of certain impassable ridges. Should be faster, with the new testing tools and refactored terrain processing code.

2nd demonstration of Isographer terrain heightmap processing. This demo uses the same terrain as the first demo, only with 65x65 datapoints gotten by expansion and diamond square recursion. Next steps will include discretizing the terrain height values, using the terrain slope data to swap out different angled tile types for smooth surface translation.

Eye candy for Isometric, Terrain, Rendering, Engine, OpenGL, LWJGL,

Early screenshots from Isographer, my new 3D isometric game terrain rendering library. Written in Java using the lightweight Java games library (LWJGL)