|Programming||By Shamus||Apr 30, 2012||129 comments|
At PAX this year, during the Q&A session at the Escapist Movie Night someone asked about Project Frontier. This is still a thing people ask about. Remember Project Frontier? That was this thing:
People ask me why I don’t work on it anymore. There are a lot of reasons, but the most important of which is: Because it was done.
It’s true that it wasn’t a game, and I occasionally talked and fantasized about making it into a game, but deep down my real driving goal was just to make my procedural generation ideas and prove they could work. I thought it might be nice if someone took an interest in the project later, and I always hoped it might lead to opportunity the way some of my other projects did, but at the heart of it was a desire to validate my ideas with a working proof-of-concept.
Once I’d gotten to the video above, I had 90% of what I was after. Sure, I could have done ten times more work to finish a game and get the other 10%, but I’m sure you can see why that route wasn’t particularly alluring. I had bills to pay and a book to finish, and so Frontier was shelved.
So almost exactly a year later, the programming bug has bitten again. I tried to ignore it so I could continue work on my next book. This resulted in me sitting with a blank look on my face, unable to write anything because I’d rather be programming. Which led to me closing the word processor and playing videogames, because I wasn’t getting anything done.
I’ve come to the conclusion that the only way to get moving on any of these other projects is to get the programming bug cured as quickly as possible. I can spend a couple of weeks staring into space, or I can spend them writing code. Might as well write code.
I seriously considered working on this project in the dark. I’ve already invested several days into the project, and I’m only writing about it now because I seem to work better when I can write about what I’m doing. And since I’m writing, I might as well make them blog posts, right?
I know what people are going to say. “Ugh. A MINECRAFT CLONE.” In fact, I’ve already gotten this treatment from a friend, so I can only imagine how THE INTERNET will respond.
However, there are a couple of technology ideas I want to play with, and doing a Minecraft -style world is the simplest and most direct means of playing around with those ideas.
There are three main concepts that I want to explore:
1. The Qt Development Environment
I want to mess around with Qt. This is a cross-platform SDK AND development environment. This is odd. The development environment is where a programmer works. They generally look like this-ish:
It’s basically to coding what a word processor is to writing. You type in your code. You compile your program. When it crashes, the IDE can help you find where. It provides a bunch of tools for keeping your code organized and managing the thorny dependency issues you might encounter.
There are a lot of these environments, usually many for whatever language you might want to use. Java, C#, Python, whatever. For nearly all of my career I’ve hammered away at Microsoft development environments. Once in a while I try something else, just to see if I’m missing out on anything. I keep coming back to Visual Studio. (I just accidentally typed that as “Visual Stupido”. Hm.) I’ve never been terribly impressed with Microsoft’s operating systems, but their developer tools are top-notch.
But who cares, right? I mean, this is Qt:
It’s got different windows. So what? Well, we’ll see. The pitch with Qt is that by using their tools you will be making 100% portable code. Write your program and it should run on PC, Macs, or X11. Since it’s generally free to use, it might be worth leaving behind Visual Studio. That’s the theory, anyway. The only way to really know how the Qt platform holds up is to write something meaningful with it. Any idiot can load up example programs and get them to compile. It’s another thing to try to bend the tool to your will.
Octrees are a major concept in 3D programming, yet I’ve never written one. Hard to believe, but there it is.
An octree is a way of dividing up 3D space. There are a lot of ways to use them. In my own work, I’ve used a lot of quad trees in my day, which which is basically the same thing but in 2D form. (Like this.) In fact, fair warning: Odds are good that at some point I’m going to call something a “quad tree” instead of an “oct tree”. I’ve made that mistake several times in my own code over the past few days and then wondered why it wouldn’t compile. I guess I’ve typed the word “quad” a LOT of times in my career.
An octree just takes a 3d space and divides it into eight sections by dividing it into half along every axis:
I’ll get into why it’s important later.
Yes, this problem is “solved”. I could type “octree” into Google and get any number of open-source solution to the problem. In fact, Michael Goodfellow made one in his very first entry of Let’s Code. I could download his code and call this done. But my goal isn’t to have an octree, but to write one. It’s one thing to see a diagram showing you “this is how you use a crescent wrench”. It’s another to pick up a wrench and take something apart with it. Writing a bit of code can put the concept into your mind in a way that reading about it in the abstract really can’t. The concept then becomes a general-purpose tool that you might be able to apply to different problems or use in new ways.
3. Perlin Noise
Here is where the Minecraft comparisons will come in, because to most people
octree+Perlin noise=Minecraft. Fine. But I still want to do it.
So those are the goals. I have many other small goals in mind, but this is basically it. As with Project Frontier, this project could die at any time.