T w e n t y S i d e d

We’re a few weeks into the project now and a lot has been done. Now is a good time to assess our progress and see how things are going. After all, it does seem like I’ve satisfied my initial goals, which I talked about at the very beginning:

1. The Qt Development Environment. Qt was very interesting, very easy to pick up, but not terribly useful in a situation where I really care about performance. The Qt experiment was an educational endeavor, and time-well spent, but it’s not right for a project like this one.
2. Octrees. I learned about octrees. It didn’t really pay for itself, performance-wise, but it was a fun little system.
3. Perlin Noise. So what I had in mind was actually called “value noise”, not “Perlin noise”. I may have used the wrong name, and it took quite a bit of fussing to get it working, but it was a really interesting exercise.

So now what?

A reader asks in email:

The idea behind project Octant was to experiment with Octree and Qt, both of which you dropped. The idea right now seems to be to experiment with noise. You are also not making a Minecraft clone, so there will be no mining.

My question is: what can Project Octree do that Project Frontier could not do better? If there will be no mining, what is the idea behind using cubes? And would the world not look better off using Frontier-type system (I can probably answer this one; this would be boring.) Moving further with this question: are you planning to use erosion generator for Octree? If not, what are you planning to use?

That’s a lot of questions. Let’s break it down:

You are also not making a Minecraft clone, so there will be no mining.

Eh. I dunno about that.

See, I’ve always been driven by exploration in games. I like seeing new stuff. This explains both my passion for, and enjoyment of, procedural worlds. So I tend to gravitate towards things that satisfy that desire. Asking “will this game have mining?” is like asking “will this car be used to commute or get groceries?” to someone working on the assembly line at the automobile factory.

I have a design document here. In fact, I have several. I have a friend (hi Mike!) and we love talking about game designs, gameplay mechanics, gameplay elements, feedback, motivation, etc etc etc. We bounce ideas back and forth and talk about things we’d love to see. This results in a lot of scattered Google docs, which are fast becoming my drawer full of scrawled notes.

The thing is, I don’t want to grab a specific design and say, “This! THIS is what I’m doing!” Making a game takes a long, long time. Rather than set some far-off goalpost of making a commercial game, I’d rather just focus on technology. To put it another way: If I was focused on a specific design document, then I wouldn’t have messed with marching cubes because marching cubes isn’t in the design doc. And I would have missed out on all of this cool stuff.

If the technology stuff pans out, then I can re-assess. If I’m still having fun, maybe I’ll add some gameplay. If not, maybe I’ll do something else. This project isn’t a game. It’s a skunkworks.

The point is: If this were a game, it might have “mining”. Mining is not precluded by anything I’m doing here.

(For one thing, a world made with value noise is unpredictable. Without the ability for the player to remove blocks, it’s possible that the game could generate stuff the player couldn’t reach. Even if we wanted to make a Skyrim kinda game, you’d probably need to allow digging because otherwise a quest item might become unreachable due to an unlucky land formation. And detecting and correcting these cases would be insanely hard. Much harder than just giving the player a way to dig and letting them solve the problem themselves.)

What can Project Octree do that Project Frontier could not do better?

It’s certainly yielding more interesting scenery. Frontier was always going to be limited by its heightmap-based world. That’s not a bad thing, mind you. World of Warcraft is mostly just a bunch of doodads on a really big heightmap, and that place still looks great. But now I want to build something else.

Moving further with this question: are you planning to use erosion generator for Octree? If not, what are you planning to use?

No real need. Value noise seems to be giving me all of the cool scenery I could ask for.

Which brings me to my next set of goals.

1. An Interface

I really need a way that I can get detailed, real-time feedback from my program. So far I’ve been using the program title bar for this purpose.

That’s… less than ideal. What I really want is something like this:

Having live feedback like this is really important for smooth development. If I’m fumbling around on the landscape and suddenly the framerate takes a momentary dive, it would be really nice if I could just look up and see what sub-system just went nuts.

You can’t fit all that crap in the title bar. If you print it to the console every frame it will scroll by so fast you can’t read it. If you dump it to a log file you’ll have to sift through megabytes of text to find the trouble spot. (That’s how we did things for a long time at Activeworlds. Man, I hated that. When you see something questionable happen you have to make a split-second decision: Do I stop and visually inspect this problem now while the log file continues to grow, or do I slam Alt-F4 as fast as I can so this moment will be someplace near the end where I’ll have a chance at finding it?)

You want this information on screen for the same reason that players want their health bar and ammo count on-screen: You need to see when those numbers change. If some system goes nuts and starts eating five times as much CPU, but only when I’m looking across the world border, then I need to know about it. But if this system only eats 5ms to begin with, then I’ll have no way to know about it. That’s too small of a change for me to feel.

If I’m running around and I find a bit of scenery that doesn’t make sense, it’s nice to be able to see what it’s supposed to be. “Ah! This region is marked as mountains. So this mess must be the result of a problem with the mountain-making code.”

Case in point: Minecraft is a rare game where the developer left his debug screen available to end users:

This sort of thing is immensely useful. Now, I don’t need bar graphs and pie charts, but I do need some text. And that means using a third-party GUI, or writing my own.

I’ve been working with Michael Goodfellow on this. Do read his post on his framework if you’re interested in this part.

With regards to his “framework” problem, I’m actually going through the same thing. Over time, you build a lot of tools. These tools are code snippets, classes, structures, modules, or entire working systems. You add those tools to your tool-belt. Pretty soon you’re like the gosh-darned Batman, with a toolbelt that has every single conceivable gadget in the world. Then someone asks to borrow your screwdriver and you have to explain why it’s on a keyring with 350 pounds of unrelated gear.

I’ve talked about this problem before. I don’t know enough different languages to be able to say if this is a problem with the language itself, or with programming in general. But the short version is this: Things in a program tend to inter-connect. You want your code to be portable. You want it to be useful to other people. But then you try to offer it to someone else and you end up with, “Oh? You need to do some 4×4 matrix math? No sweat. I’ve got some code to do that right here. Er. It’s built on top of my system for using XYZ values. Which has a bunch of code for converting to/from 2D values, so you’ll need that code to get it to compile, even though you don’t need the 2D stuff. Oops. Looks like it’s also connected to my code for using Euler Angles. That’s kind of big. Sorry. Also Quaternions. Wow. I forgot those were even in there. And all of that stuff depends on this math module I wrote that calculates angles and such.”

So in this example I have one module (source file) that solves your problem, and five others that you don’t need, don’t care about, and don’t help you, but are simply required because of a tiny bit of inter-dependence.

So Goodfellow has a GUI system and I’m going to try to integrate it into my project.

2. Cool scenery

I want to combine these marching cubes with the value noise and see what kinds of cool places I can make. I’ve already made quite a bit, which I’ll be showing off in future entries. I have a lot more ideas along these lines. Basically, this stuff consists of:

“What if I took some 2D noise, combined it with 3D noise like so, and used it to make formations of this material?”

This is my favorite part of this whole thing so far.

3. Lighting, texturing, and different block types

I have cube-based blocks in addition to the blobs I’ve been using.

It seemed simple to re-introduce cubes, but there’s actually a lot of questions as to how lighting ought to work when we combine the two systems. My goal is to have both block types work together in a single rendering pass, sharing a common atlas texture and shader. We’ll see if that works out.

Also, I should probably re-name the project.

Shamus Young is a programmer, an author, and nearly a composer. He works on this site full time. If you'd like to support him, you can do so via Patreon or PayPal.