Blog

Disclaimer – This is a semi-technical blog-post. Some of you might not be interested by it’s content while some others might find it incomplete. I made a compromise between accessibility and depth. Later, if people seem interested by the subject, I might make a more complete tutorial. – François

So we got that question a lot and since voxel games are all the rage these days, why not explain how we are doing ours? Well, this question has two aspects. First, how do you make a voxel base game? Second, What specific Unity3d tool can I use to do so?

Let’s do things backward and start by answering the second question. Unity3d is a very good game development tool. It provides you a simple and complete environment as well as an array of basic function to help you simplify the numerous and most complex aspects of the game creation. However, there is no built-in function or predetermined way to make a voxel based games.

Many of Unity3d’s very useful features do not work with dynamically built objects. Things like path finding and occlusion culling only works on objects that are in the scene prior the game’s exportation. The same way, most of unity’s automatic lightmapping functions only works on non dynamic objects. By non-dynamic, I mean objects with an unchanging shape. So if you want to make a game in which every objects change their shapes in game time, be ready to build your fancy tools yourself.

Do not despair, however. Making a basic voxel system is not so complicated. Once you understand the general idea, implementing it is relatively easy. Shaping it into a full scale video game can be a real headache though. But what game isn’t? Unity is as good a environment to do that work as any other and it takes care of many other things that would normally distract you from your daily cubic puzzles.

So now we covered the Unity subject; how do you build a voxel game at all? First, get familiar with the process of building dynamic mesh. It may look like a big chunk and it is. Depending on the language or the engine you are using, the process of creating geometry will change. Read a tutorial to know how to do that in your specific environment. Before you can do anything else, you need to be familiar with the general structure of 3d objects (vertices, triangles, normals, etc) and be able to procedurally build a cube from scratch, face by face. You can read this post even if you can’t create your one cube yet. For now, make abstraction that specific notion and once you understand the global idea of voxel objects, go back to the basic “building a cube” step.

Moving on.

Voxel is a contraction for  volumetric pixel . It means that your world is made of points in a 3d environment. Each point is either filled of empty. In most cases filled points in the 3d universe are represented as cubes and the organization of these cubes makes the shape of every objects. What you need to understand is that  filling an entire world with cube (depending on the size of your world) can easily represents dozens of millions of cubes (no kidding). For example, the main island in the first part of our presentation video weights about one million cubes. No modern computer can handle that many different objects or that much geometry. 12 millions cubes, with six faces per cubes and two triangles per face makes 144 million triangles. To run such a game you need to do three things.

For each different object in your world, your graphic card has to make a certain amount of calculations. We call that a draw call. It has to compare that objects position with the other objects of the world in order to determine which object is in front of which. If there are too many objects in your world, they will consume most of your graphic power and your game will be far too slow. The solution is simple : you have to combine your cubes into bigger objects. In other words, you have to build containers. Each containers will have a certain volume and every voxels in that volume will be part of that container. That way, you will only have one object per container, and that object will simulate many voxels. That means every time a voxel changes in the container, you will have to build it again. Depending on the game you are making, you will have to tweak the size of your containers. A big container means that there will be less containers in your game and that will be easier on your graphic card ( less draw calls). However, a too big container will be hard to rebuild for your processor when a voxel it contains changes it’s state. There is no perfect answer, the ideal size of your voxel containers depends on the optimization of your algorithm and the size of your world.

The second thing to do is to choose which face to build and which face not to. As I said earlier, 200 million triangles is completely insane. In a normal world, most of your filled voxels are actually in the middle a your mountains, under your floor or inside your walls. The voxels you actually see is generally (again, depending on your game) less than on tenth your world. Your goal is to not create the faces inside your mountains and under your ground. When you re-build your voxel containers you only want to create the geometry of the visible faces of your voxels.

Finally, this is more a tip than a actual necessity. Since you want to have your voxel containers as big as you can without creating lag at the moment of their reconstruction, you might want to do some of your calculations in advance and keep the results in your memory. For example, if your game has objects more complex than cubes, like stairs, round corners or arches, it adds exceptions to the simple « If the voxel beside of me is occupied, I do not need to draw the face between us. » rule. Each exception in your system grows your decision tree a little and by the time you reach a full size game, reevaluating which voxel has to draw which face can be really heavy on your CPU. To reduce that, you can make these calculation once and inscribe that in the voxel data structure. When you change a voxel, you only have to recalculate that particular voxel and its neighbours. The rest of the voxels in the container remains unaffected. The same thing goes for every complex things in your game that you don’t want to reevaluate all the time (pathfinding nodes, ambient occlusion, texture variation, etc). Again, that leaves you with variables to tweak. The more calculation you make in advance, the faster voxel recreation will be. However, every information you choose to keep in memory to save calculation power costs your game some more RAM. Keep in mind that every byte of information you add to your voxels may end up in costing you millions time that.

So these were the three basic principles about voxels. Divide your world in bigger chunks to reduce the number of different objects it contains; try not to build the faces that can’t be seen and do your most complex calculations ahead of time. If that seems confusing to you, you do not need to understand everything about that. Learning is often part of making a good indie game. Go back to the beginning, and start by learning to make basic shapes in-game, you can worry about optimization later.

I hope these explanations and tips about making a rudimentary voxel game engine helped satisfy your curiosity. We were making the Global Game Jam this weekend and since we are pretty tired, that will be all for today. In the following days we will get back to you the game we made in the last 48 hours.

Cheers!

The Sauropod team

update : Got rid of those damned witches. Sorry, English is not our first language.