So I’ve been working more and more toward editable terrain. Still not quite there yet, but am finally getting rather close. I’ve now set up a couple of key steps towards editable terrain. First, the subregions (and regions, for that matter) which I’ve mentioned before now know about their neighbours. Ever since dropping the “grid”-based region approach that I used in MMORPG Tycoon 1 and 1.1, regions haven’t been able to know what other regions bordered them, simply because they were irregular; when all you have is a big list of shapes, it can be difficult to tell which ones share borders! But that’s now been sorted out.
This will be important for terrain editing, for smoothly blending from one terrain type into another, across subregion boundaries.
I’ve also today set up subregions to be able to specify a different style than that of their parent region. In the screenshot here, I’m standing inside a hilly-grasslands subregion, looking towards two rolling-mountain-tundra subregions. (the blending between regions isn’t implemented yet, which is why you can see sharp cliffs between the different subregions)
Next step will be blending terrain between subregions. I’ve got a pretty good idea of how that’ll work. Next after that will be actually regenerating the terrain data when the player adjusts the subregions.
So today I’ve managed to wire the districts I was talking about recently into the terrain generation algorithm. Right now, it’s just assigning a random brightness to each district so that you can tell them apart, and since I’m not yet doing any blending between districts (the way that I do between regions), the boundaries between districts are currently extremely sharp (and badly aliased!) I’ll tidy that up soon.
As I mentioned before, these “districts” are currently on average about 100 meters across, which means that they’d take about 20 seconds to run across, and there are about 150 of them in each region. When editing the MMO terrain, players will do it by setting terrain types and other configuration values on these districts; not by directly modifying the underlying heightmap.
Next step will be regenerating the local terrain heightmap when the player modifies a district, but the weather report for tomorrow sounds really nasty, so I’m likely to be hiding somewhere far away from heat sources like my laptop, and so will get to this stuff a little later in the week.
Apologies for the darkness of this image; you’ll probably need to view it full-size to see it. Or just look at the previous screenshot I posted; this one is basically identical to the last one, except that this time it’s real (whereas last time was just a mock-up)
In this shot you can see parts of four MMORPG regions. As you can see, each region has been divided up into “subregions”. Each region has (on average) about 150 subregions, each of which averages about 100 meters across (which means that each would take about 20 seconds to run through). I’ve also (just incidentally) improved the generation of regions and subregions, so that while they’re still interesting shapes, they’re of a somewhat more uniform size; no more absurdly massive regions or tiny regions that can barely even contain their border walls. :)
I’ve also spent some time on the polygon clipping code, which is used for (amongst other things) constraining the subregion polygons inside the region polygons. I think I’ve improved it, but I’ll still occasionally get impossible results, so I’ll probably have to dig in and debug it some more, sooner or later.
I’ve been playing around with terrain authoring systems lately. The current one I’m experimenting with is kind of a tile system, with non-regular tiles.
In this screenshot, you’re looking at a portion of a region map; the dull grey lines show region borders. Inside the (unusually large) region in the middle of the screen, the blue borders show what I’m currently calling “districts” of a region. I’m thinking about letting the player set each district as “grassland” or “forest” or “mountain” or etc., and having those choices drive the generation of the overall region terrain.
Not sure whether I’ll go with this approach in the end, but I do like it more than asking players to directly paint on the heightmap, and then having every save games be several hundred megabytes in size due to having to save the resulting MMO terrain as an extremely high-resolution image. :)
…I spent some time today fixing the vsMeshMaker bug which was causing procedural geometry to sometimes have weird “creases” which caused sharp changes in lighting across a smooth surface. The cursor is here pointing to a spot where the old code used to put a sharp crease (for comparison, a screenshot of the old, broken shading). To be honest, this new implementation still isn’t quite correct; where the last implementation did the right thing about 95% of the time, this new one does the right thing closer to 99% of the time. If that eventually becomes a problem, I’ll fix it properly. But fixing it properly will require a lot more processing and storage, so I’m hoping that the 99% fix will be good enough. :)
As always, apologies for the debug lines scrawled all over the screen. They’re just marking various boundaries during my testing.
So I’ve been working more and more toward editable terrain. Still not quite there yet, but am finally getting rather close. I’ve now set up a couple of key steps towards editable terrain. First, the subregions (and regions, for that matter) which I’ve mentioned before now know about their neighbours. Ever since dropping the “grid”-based region approach that I used in MMORPG Tycoon 1 and 1.1, regions haven’t been able to know what other regions bordered them, simply because they were irregular; when all you have is a big list of shapes, it can be difficult to tell which ones share borders! But that’s now been sorted out.
