One beautiful ball

My last blog post wasn’t particularly well-timed because the day after I wrote it, I took off for two weeks to get married and spend time with my wife’s family (wow, I guess it’s now my family too!) in their mountain cabin with no internet access. It was tremendously awesome, but not in the bloggy sort of way.

However, I may have been gone, but I haven’t been inactive. In addition to the whole, you know, getting married thing, I spent some time working on the planet’s appearance. It was actually my new nephews and nieces who really spurred me on; the moment they saw my work, they planted their hindquarters on the couch with me to offer suggestions and observe my progress. Here’s what I was able to show them by the end of the trip:

You’ll notice a number of enhancements:

• The shoreline blends into the ocean
• There are polar ice caps
• The ocean has a subtle texture (alas, not animated yet)

Of course, all these enhancements have bitten into the generation time since I haven’t optimized them yet, so each new globe takes about 16 seconds to create. That’ll be fixed in due time.

Next up: rivers!

Wait, what?

Soooo. Yeah. I’m here. Still here. I know that I haven’t provided a real update in months, and I’m sorry for that. I would say something like, “a number of life-related events took over and I haven’t been left with much time to work on side projects,” but I know that’s a cop-out. I’ve always believed that you make time for the things that are important to you, and the truth is that I’ve been making a lot of time activities other than working on this game. I’ve painted 40K models, built an AR-15 rifle, completely overhauled my financial infrastructure, played Mass Effect 2, StarCraft 2, and S.T.A.L.K.E.R.: Call of Pripyat (awesome games, BTW), and got a hunting license and a driver’s license (finally). So I’ve had the time, I just chose to spend it elsewhere.

The reason I’ve been avoiding this project is because I became demoralized by the lack of progress and the challenge of learning multiple new toolsets at once. But that’s stupid, and games don’t create themselves. I’ve resolved to push forward and aggressively learn the tools to gain confidence. You can’t become any better at a programming language that you’re afraid of using!

I’ve done a couple of things recently:

1. Added a method to randomly determine a land pixel
2. Used that to seed the planet with preliminary artwork for goody huts and initial bases
3. Implemented gravity that pulls affected objects toward the center of the planet
4. Added a setting to determine the mountainousness of the land area

So here’s what the globe looks like now:

The little pointy thingies are placeholder models for the goody huts. What do I mean by “goody huts”? Well, it’s sort of a longstanding Civilization tradition to scatter the map with areas that yield a one-time bonus of some sort when conquered by a military unit. Civilization has actual huts; Call To Power has stonehenges and Easter Island heads; Alpha Centauri has pods.

This game will have ruined cities left over from whatever apocalypse you choose to believe happened. Unlike goody huts that disappear once grabbed, the ruined cities will be semi-permanent fixtures. They represent an excellent source of resources for your nearby settlements, but they can be directly exploited by military units for a large one-time bonus and smaller long-term bonuses.

For example, a ruined city that contains a hospital can be used once to totally heal an army in an emergency, or it can be left intact and provide small medical bonuses for nearby settlements.

But this is all a bit far-off; right now the goody huts don’t actually do anything. My next big priority is creating a rudimentary unit movement framework. Gravity was the first big step; with that in place, I’ll be able to say simple things like “move forward for 3 seconds” rather than having to use calculus to precisely determine a unit’s movement path. This is good, because I don’t know calculus.

I’m also investigating deleting the parts of the land mesh that are below the ocean sphere for a performance boost, but that’s turning out to be surprisingly challenging.

To the two people who found this blog by searching for “god given right to take all of the land”

Sorry, I don’t think this was what you were looking for!

It exists!

I’ve put what I have so far online so go try it out! I’m going to keep the game at that URL for the indefinite future so you can check it out anytime you want to see the progress. I’d embed the game right here into this post, but what is this, nursery school? If you haven’t already done so, you’ll need to download and install the Unity Web Player to see it.

There are a few caveats:

1. This is a work-in-progress! Things will be broken, ugly, and generally crappy.
2. There’s no GUI, so the planet creates itself as soon as the game loads. This means…
3. It’s going hang while it loads. Because this process takes about 10-13 seconds, so there’s a 10-13 second lag before you can interact with it. Be patient when you click on that link because it may hang for a little bit.

Once the planet loads, you can orbit around it by control-clicking and dragging. You can right-click and drag too, but the Unity Player will instead pop up a menu if you’re not full screen. Hopefully I can fix this soon. To zoom in on the planet, use your scroll wheel or the two-finger-scroll feature of your laptop. You can make another planet by reloading the page.

No more Waterworlds!

…At least, not unless you really want one, because I’ve added a mechanism for you to determine how much land you want. All you have to do is specify a target percentage, basically. Under the hood, what it does is it first deforms the globe like it always does and then checks to see what the actual land coverage percentage is. It then compares this to your specified target. If it’s more than 5% higher or lower then the target, it’ll scale the resulting mesh up or down (depending on whether there’s too much or too little land) a teensy bit at a time and then calculates the percentage again until it winds up with a value that’s within 5% of your target. It’s pretty neat and it doesn’t add anything to the total generation time either! Also, unlike Alpha Centauri, when you tell my algorithm to generate a planet with about 30% land, it makes one that has a few big continents rather than 500,000 tiny islands. Booya!

I hope to have a playable tech demo uploaded sometime tonight or tomorrow. I use the word “playable” in the loosest possible sense of the word here, since all you’ll be able to do at this point is generate a globe. But hey, at least it’ll exist in a place where the entire internet can make fun of it!

Yes, I’m still alive!

What happened? Work happened. Basically, it got more demanding and I had to cut out development time. But I’ve normalized my schedule a bit and gotten a nice routine going and I’ve been able to squeeze the time back in.

I’ll be realistic here: expect sporadic posts from now on. Some weeks I’ll have plenty of development time; others I’ll have none. It’s just the nature of the beast, I’m afraid.

Anyway, when we left off, I had a dynamic globe that took 45 seconds to generate. Well now I have a dynamic globe that takes 12 seconds to generate.

I know, not very impressive, right? But I had to do some major re-architecting under the hood. Before, I was taking up valuable time by generating the blended texture myself based on the heightmap and using an extremely inefficient algorithm to create both of them; now, I’m generating the heightmap using better math, then using it to create a four-color blending map before finally feeding that to a custom shader that does all the work of smooshing textures together based on the colors in the blending map.

Did any of that make any sense? I don’t think so. But the important part is that it’s more efficient and faster. A lot faster! From hitting “play” to looking at the end result, it typically takes 10-13 seconds on my computer, which is 3 years old now.

Oh yeah, and I also did some prettifying:

It still has the ugly seam (it’s actually worse now) and it still sometimes creates Waterworlds and Tatooines. But I’m making progress again and I have some good ideas to fix the latter issue. And one of these days, I’m going to upload a playable tech demo — one of the awesome things about Unity is that you can compile your game to a web-playable format, no matter how graphically complex it is! You’ll have to grab their web player plug-in though, so you might want to do so now.

Hackin’ along

Sorry for the lack of updates recently, but my life has been a bit of a whirlwind. I’m coding away, but haven’t had nearly as much time left over after other obligations as I would have liked.

Nevertheless, I’m making progress. It’s sort of difficult to visually demonstrate efficiency, but I’ve managed to get the generation time for a globe like the one in the previous post down from four minutes to about 45 seconds. Even better, about 30 of those seconds can be spent watching the terrain morph, so at least there’s something to look at while it happens. 15 seconds of nothing is still too long for me, and I’m convinced that I can make the texture generation process take under eight seconds. If I can get it down to that, then it’s nothing to just toss in a progress bar and call it a day.

A texture jackpot

This update is sort of like two-in-one because I fixed two problems in the past few days:

1. The texture is now made up of a series of smaller textures rather than flat pixel values.
2. The texture generation algorithm now blends the different layers into each other.

I think the results speak for themselves:

Next up: boring old optimizations and efficiency fixes. This globe took a full four minutes to generate, about 3.5 of which were eaten up by my super-slow heightmap generation algorithm. That’s the first target, and I think I can dramatically improve its speed.

My problem is that right now I read and write one pixel per calculation, which is horribly inefficient, as any techie can tell you that disk reads and writes are some of the slowest operations out there; it’s orders of magnitude faster to write a 1-gigabyte file than to write 1,000 1-megabtye files.

With this in mind, I think I’ll do the reads upfront, load the written values into an array and then apply the final pixel values all at once when the calculations are finished, rather than one at a time. This approach will be tricky, as I’ll have to figure a fast method of converting from 2D (a plane) to 1D (an array) because my heightmap algorithm right now works by calculating 2D distance, which sort of doesn’t work if you happen to be working with fewer than two dimensions. Ultimately, though, it’s the only way, as performance is pretty horrific right now due to this bottleneck.

Oh, and I’d also like to increase the resolution of the textures, but the efficiency fixes come first unless I’d like to wait until I’m an old man for a high-res globe to complete.

DAS TEXTURE IST HIER

Days of slaving over my algorithms has finally paid off! I have successfully managed to generate a texture from a heightmap and apply it to my random globe. As usual, this is a rough attempt and the visual quality isn’t where I’d like it to be yet, but there are a squillion tweaks that I can do now that I’ve finally cleared the hurdle of randomly generating a texture pixel-by-pixel to begin with.

This graphic is similar to the last one, only with the addition of the texture. At the top is the finished globe; beneath it is the texture that has been applied to it; and beneath that is the extrapolated heightmap that was used to generate the texture.

More Updates will follow shortly. The approach I think I’ll try next is documented here (scroll to the bottom for the ultimate goal), and I think it won’t be long at all until my globes are looking as nice as the terrains there!

An idea…

I’ve found no less than a treasure trove of resources on how to create terrains and textures from heightmaps, but this hasn’t helped me, because I’m bypassing the heightmap entirely by creating the terrain myself rather than creating a heightmap and generating the terrain from it.

But I’ve been really banging my head against the wall about this texture issue. And then it hit me (the wall, maybe!): if I can super-easily generate a texture from a heightmap, how hard would it be to create a heightmap from a terrain? If I could just do that, then I could make a terrain from it with no problem.

It intrigued me. The biggest problem I was running into was that there weren’t enough vertices to paint one pixel per vertex; I would up with unpainted black areas. I had contemplated drawing circles or even fancy radial gradients, but I had NO IDEA how I would get the colors to mix properly given how colors are stored in Unity.

But it would actually be very easy do draw circles or gradients if I didn’t have to worry about complicated color mixing. And I wouldn’t have to worry about complicated color mixing if there were only one color. And there’s only one color in a heightmap…

Everything seemed to be pushing me in the direction of generating a heightmap from my terrain mesh. Which is funny, since heightmaps are almost always used to generate meshes themselves, not the reverse! Still, it had some promise.

Having decided to do it, I had to figure out how to draw radial gradients pixel-by-pixel. Summoning up all my high school math knowledge, I actually managed to do it! Basically, I had each pixel calculate its distance from the center and dampen its color value accordingly: a pixel right in between the center and the edge would be 50% as bright as the center pixel; one 90% to the edge would be 10% as bright as the center one and so on. Then I just had these pixels add their color values to the color values of the pixels they were about to replace. In other words, a bright pixel that gets a bright pixel painted on top of it becomes twice as bright.

Here are three random globes and the heightmaps they generated. I stuck the heightmaps themselves onto the globes in lieu of textures because I couldn’t stand those beastly squares any more.

The next step is basically to loop through the heightmap and determine for each pixel what color to apply to the pixel in that same spot on the texture. It seems easy, but I’m still working on it. And there’s an obvious performance hit to adding this intermediate heightmap generation step, but I think it’s worth it if it gets me farther to my goal. And once I reach it, maybe I’ll figure out how to create the texture without a heightmap.