Please Save This For Me

I'll come back for you, love, I promise to.

This week I've been working on saving and loading the world as you move through it. Until now, the world has been procedurally generated as needed. You could make changes to the world, but if you left and came back, the terrain would be re-generated.

A simplest way to handle saving and loading is to divide the world into parts and save/load each part to a file. However, this can incur a lot of hidden overhead. File reads/writes are very expensive. They're pretty much the most expensive thing a computer program can do short of accessing the internet.

So I decided to (once again) take a lesson from Minecraft. I originally implemented a format that was more or less identical to the Region file format used by Minecraft. After doing all that work, I suddenly realized that the Region format wouldn't work for me, and there's one important difference between my project and Minecraft that makes this a problem: Minecraft has a fixed height limit.

My project, on the other hand, does not. The game world extends infinitely in all directions, including up and down. The reason this is a problem is because the Region file format stores world chunks in vertical columns. This is fine in Minecraft since moving up or down can never trigger loading/saving. This is not the case in my project. If I used the Region format, I would have to store twice as much data when the player is straddling a vertical boundary.

So I decided to modify the format to suite my needs. Instead of working with columns of the world, I'm working with large cubes. I chose a size that was large enough to take advantage of compression (using run length encoding), but small enough not to incur a huge memory overhead. I ended up settling on 64 x 64 x 64 block areas.

Unfortunately, this change created a problem. In the Region format you're unlikely to get an entire column compressed down to significantly less than 4096 bytes. This number is significant because most modern computers read from hard drives 4096 bytes at a time (it's more efficient to have a few large reads than a lot of small ones). Region stores its data in a way that minimizes the number of reads/writes.

When you store the world as large cubes, you end up having cubes of solid air or rock. After compression, these only take up a few bytes. Basically, this would mean using 4096 bytes for something that requires less than 10. This wouldn't be so bad if these sort of regions were few and far between, but they actually make up the majority of the game world. My solution to this problem was to store multiple small chunks in a single 4096 byte area. Large chunks are still stored the original way. The end result isn't quite as elegant as the Region format, but it did, inadvertently, result is a larger maximum chunk size (255 MiB vs Minecraft's 1).

I finished all the code for this, but I still have to fix a few bugs before I can say it's done.

Vegetation

Another short post this week. I added some vegetation! Importantly, I can use the same code to create other objects. Although, for the time being, I have to hand write object meshes, so I probably won't add many more until I have a way to import them. I added a minimap. This is just for testing purposes and will eventually be taken out. I also did some more optimization that allowed me to increase the render distance quite a bit.

Snow Stickers

Gonna be a short update today. You can now create and destroy blocks (look, I made a castle!). Additionally, I added decals. This lets me slap additional textures on blocks. I could even layer several on a single block. In the above screenshot you can see me experimenting with snow decals. This will cut down on a lot of work that I would otherwise have to do by hand, and opens up a lot of possibilities. I was pleasantly surprised to find that the decals didn't impact performance, even without any optimizations. There's also some water visible, but this is purely for looks.

Grounded

I've been making progress on my project! I finally got some basic physics implemented (after three days of debugging), so you can walk around the world now. I also did some optimization; things are running a lot faster now. Sections of the world are now generated on demand, so you can walk around indefinitely. I'm not saving or loading sections yet though. I also added in some variation in the terrain, so now there are patches of snow and snow capped mountain peaks.

This week I'm going to talk about how I'm generating the world.

All Aboard the Tangent Express

So, when I began working on adding 'simple physics' to last week's project, it got me thinking about rigid body dynamics (a.k.a. game physics) and how to apply geometric algebra to it. Not surprisingly, I ended up on a tangent. You'd think I'd know better by now.

Perlin Hills

This week has been unusually productive. I've been working on terrain generation. Already the results are much better than previous attempts of mine. Thanks to researching the topic, I've finally come to decently understand Perlin noise. For generating and storing pieces of a massive world, I plan to adopt some of the methods used by Minecraft. Specifically, I'll be using a file format similar to the Anvil file format, which Minecraft currently uses.

I've spent some time reconsidering the previous block shape scheme I planned on implementing. For the time being, I've largely given up on finding the 'perfect scheme'. Every system I've considered has drawbacks of some kind, and all would have been a huge headache to implement. So, for now, I'm using a simplified scheme. The shape of a block is simply defined by which of the eight corners are present (256 total block shapes). In the future, I will likely consider more complex schemes, but until I find a better one, I'm just going to move forward with what I have now.

As an optimization, no hidden faces are included when the meshes are generated. This is done simply by checking if two adjacent blocks have matching corners on the touching sides.

Here are the next few things I'm going to be working on:

• Adding textures to give the world some color.
• Saving and loading sections of the world dynamically so you can move around.
• Some simple physics so that you can walk around.

What I Want in a Survival Game

A few weeks ago I found myself wishing for a first person survival game. So when I heard about Rust, I decided to give it a try. So far it's not exactly what I was hoping for, but it is definitely fun. It's also early in development, so it's likely to get better with time. In any case, playing it got me thinking about what I want in a 'survival game'. I'm using that term loosely; my ideal survival game would have a lot of elements that aren't strictly about survival. Two of my favorite games that I would group into this category are Minecraft and Dwarf Fortress (again, using the term loosely). Throughout this post I'm going to compare and contrast what I like and dislike from Rust, Minecraft, and Dwarf Fortress. I might also mention few other games that I have less experience with.