T w e n t y S i d e d

Projects slow down over time. It’s inevitable. Partly it’s because the more you add, the more complex the code becomes, and so the harder it is to make headway. Swapping out a part on a lawnmower is easy. Changing that same part on a fully-loaded 2011 automobile is likely to be an order of magnitude more complex. But mostly it’s because we tend to go for the low-hanging fruit first and tackle the thorny problems later.

I began writing this series of posts a week into the project, and I’ve been gradually catching up. To wit: I’m adding features more slowly than I’m writing posts about features. Now that I’m out of new stuff to show off, these posts are naturally going to become less frequent.

While we’re waiting for the next breakthrough, I thought I’d take a minute and answer a few of the questions I keep seeing again and again…

Continue reading ⟩⟩ “Project Frontier #8: FAQ”

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.

WARNING: This one is tough to explain without spending 5,000 words detailing the most mundane inner workings of the engine. Sorry if it’s confusing. I did what I could to balance information and readability. I tried, I really did.

When I started the project, I had a pretty good idea of how the previous features were going to work. Terrain textures, the topography, the grass, the sky. My design changed as I worked, but I always had a plan.

I don’t have a plan for rivers. This is a shame, since the whole project is pretty much a bust if I can’t solve it.

Here is what the world looks like during my default build:

Continue reading ⟩⟩ “Project Frontier #7: River Raid”

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.

As we reach the end of week 3 of the project (I didn’t start blogging until I was a week in) I decided to make a demonstration video:

I’m not crazy about how the video turned out. There are annoying framerate skips. (Which only happen when I’m recording via Fraps. The program itself doesn’t have slowdowns like that.) I’d disabled dirt and forgot to re-enable it before recording this, so the surface is a lot less diverse than it should be, especially in the badlands-type areas. The rocks are colored to match the grass, due to a bug that I fixed after editing the video. In general, this just doesn’t show off the program as well as it could. I almost trashed it and started over, but then realized that those two hours could be spent improving the program instead of editing a two-minute video to show it off.

Also, I must thank the person who suggested Mercurial for source code control. Everything about it is awesome. I hooked my source up with Mercurial, and then put it in my Dropbox* directory, meaning I now have continuous, off-site backups of my entire revision history.

So, thanks for that. If I had access to professional-grade Perforce again, I’m not sure I’d go back. It really is that good.

On the subject of the source code:

Under normal circumstances, I’d share the source for this as I have in the past. However, I’m nominally unemployed and so I’m playing things a little closer to the vest. I have no idea how far this project will go or who will take interest. To be blunt: Minecraft has made a pile of thirty-three million dollar bills. It’s outsold a bunch of AAA games and it’s beaten them on the profit margins by a humiliating degree. Now, I’m not making Minecraft and what I have here is not worth millions. (Going by how much I’ve been offered so far, it’s worth zero. Heh.) But it’s entirely possible the employers or investors are looking for another game that hits those same notes: Replay value, retro-graphics, low system specs, unconventional gameplay. Someone might want to hire me because of this. Someone might want to buy the project. Giving away the source might make this less likely. Employers are sometime strange beasts, and they don’t always view source code the same way we do. People are less likely to buy code when they can get it for free, or if they’re concerned that the code is a group effort and they are worried of the group-fights that might appear once money is part of the equation.

I’m not ruling out sharing the source in the future, and I realize I’m giving up a lot by keeping the source to myself. Other coders out there could probably solve some problems that are difficult for me, or spot bugs I’ve missed. And it’s always nice to be able to show off a really well-polished bit of code.

But the point is, I’m holding onto it for now. Please respect this decision.

* My praise for Dropbox is somewhat less enthusiastic. It’s too stupid to ignore unwanted files and directories, which means it backs up a ton of useless intermediate compile-time files, and it freaks out a bit over the blink-and-you’ll-miss-them temporary files that are created during compile. The designers have flatly stated they won’t add a feature to exclude files, which means 95% of the crap in my Dropbox is stuff I will never want but can’t stop it from uploading. Clarification: You CAN tell Dropbox you don’t want certain files, but if you do that it DELETES THEM. Stupid, brain-dead design. Still, it’s free and it gets the job done.

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.