Voxels are hot topic. Ever since the minecraft game ‘voxels’ are popping up everywhere. The technology is not new, but with the power of modern-day GPU’s, advanced techniques are now possible in real-time.
I was particularly impressed by the works of Procworld, Voxel Quest and Blockscape. Since this technology requires combining computer graphics, maths, CPU/GPU parallelism and complex algorithms, I was very excited to taste some of those delicious voxels myself!
Voxels are the three-dimensional equivalent of 2D pixels on your screen. Your screen is divided in a finite set of points (hopefully at least Full HD ). Each point corresponds to a dot or a square with a single color. Put all of these millions of points together and you get an image.
Voxels follow the same principle. The 3D world is divided using a regular (equally spaced) grid, and each gridpoint corresponds to a single voxel. Instead of containing color, a voxel typically holds the type of material present at this point, like grass, dirt, rock, air, but a voxel can be used to store any kind of volumetric information.
I deliberately didn’t refer to voxels as cubes, since they aren’t. Voxels can be represented as cubes, by placing a cube at each voxel using the voxel’s material (as done in Minecraft). However, alternative techniques exist, Procworld converts the 3D voxel information back to 2D triangles by generating the surface between air and solid. I’m guessing blockscape stores different shapes of cubes in its voxels and displays those. Voxel Quest is using some sort of ray marching algorithm and evaluates 3D mathematical functions.
For my implementation, I started with a surface extraction approach as in Procworld, since it has as a main benefit that it outputs triangles, making it compatible with most mainstream 3D rendering technologies. This way I can render the voxel world using my existing deferred rendering implementation.
I’ve been mucking around with Unity lately, building a very simple game to figure out how to do the basic things in Unity (gameplay coding, animation, UI, user input, ray casting, camera, …). You can see the results of the experiment on the Github website (press play latest build). It’s not much fun at the moment, but you can finish the mission and the items are jumping and there are mouse highlights :). I intended to make a game about item transportation networks but I figured I needed to get to know Unity first.
My initial feelings of working with Unity as compared to working with my own hand-crafted engine are currently mixed. In general, having a complete tool chain with editor is very nice, but the programming/software design side of Unity feels very rusty and cumbersome. Lets highlight some pro’s and cons!
In general, Unity has a lot of features to get you started really quickly.
Pre-delivered set of game engine features: complete deferred renderer, particles, basic animation system, advanced asset management
Scene builder/Editor with very useful property inspector directly tied to the script’s source code. This makes play testing and prototyping very intuitive
Cross platform compilation! Always good to have
Asset store which enables easy reuse of other peoples work. Did not get to really use this feature yet.
While implementing the scripts for the Transportation Game experiment, I experienced a lot of difficulties related to working with their GameObject-Component model and its relation to their API’s. These difficulties are related to achieving a decent reusable, understandable and extendible software design, resulting in the little amount of code used being a complete mess. The trouble I’ve had might because of my unfamiliarity with Unity, but given the number of really annoying and stupid problems I had to look up on the Unity community boards I suspect other people are having issues with this too.
I think that’s enough for this post. In the future, I might try to actually start on the actual transportation mechanics and continue my battle with Unity’s unusual software engineering practices. Or maybe I will return to The Wizards Engine and do some engine/rendering stuff
Last post I talked about the development of a new game concept based on the city building series games. Since then, the basic ideas of the game are taking shape. Using ‘the new game concept’ gets old quickly, so I decided to give it a working name: ‘project Scattered’.
I’ve been work out the basic game elements of project Scattered (see what I did there ). In order to test out these gameplay concepts, my friend Simon and I took a swing at paper prototyping. The idea of paper prototyping is to use a very simple and quick way to test out gameplay (paper). The way it works is that when you have your game rules, one of the participants can play the role of player, and the other one of the game master (performing the computers tasks).
Since we were not able to physically meet, we used a collaborative diagramming tool together with voicechat. Here is a screenshot from during the ‘game':
After a little time playing we discovered some problems with the game concepts. One of the most important things we concluded was to carefully analyse what you wish the player to do and reward him for doing that.
I decided to make all written content on the project publicly available. You can have a look at this wiki here: Project Scattered Wiki. Currently it contains a draft of the design document.
It’s been a while since the last post. Turns out that the RTS game concept is too simple, not detailed enough. Back to the drawing table!
I’m looking for a good solid design for a game, but at the same time not too complex with respect to time limitations. Instead of reinventing the wheel I decided to base myself on an existing game.
After some thinking i got drawn to the game Caesar III which I played a long time ago. It is part of the old City Building Series containing similar games like Pharaoh, Zeus and Emperor. I even dug up a copy of Emperor to play. At their core, these games are really simple and elegant. The key concept in these games is that they are city management games, which is the main thing you are doing while playing the games.
I decided I wanted to recreate the amazing experience in this games. The current game concept I am working on is mainly based on the workings of Caesar III. The main change is that it will be a little more combat oriented. There will also be a change in scenery You will not be building on the ground anymore:
The RTS testcase is slowly being implemented (due to lack of time). The intial magic + crystal system is working. This system allows the player to store magic energy and transport it using crystals. The system should allow for building energy transport networks. But beware what might happen if you focus too much energy in one place 😉
The goblins have received upgrades! Now they can receive commands through the use of command orbs. The player can pick up these orbs and place them somewhere or attach them to containers. The can even use carts to store their items in. The implementation is still a work in progress, but so far it is looking promising.
Goblins have a lot more to do, so their brains should get somewhat larger. Since scalability is very import in the wizards, I opted to use behaviour trees for implementing their AI. This will not give us goblins that invent time travel, but allow for easy adding and adjusting behaviour in a scalable manner. Currently the behaviour tree’s implementation is pretty basic, but I am eager to learn if they are as scalable as they seem to be :).
The Wizards Project practically entails all domains of game development. This makes it extremely difficult to predict which features the engine will require, making designing it even more complex.
A lot of the plans we have for this project are also experimental. We don’t know if these are fun and epic and awesome as we like to believe, once they have been implemented. Maybe implementing them on modern hardware might even prove impossible.
In order to tackle these difficulties, we’ve decided to divide work into what we currently call ‘TestCases’. A testcase is a playable game demo, containing some of the concepts we would like to see in the complete game. This testcase itself is not aimed at being playable for many hours, or being balanced, graphically optimized, or a reflection of any sorts of the final game. It will simply be used to test if certain features are viable,
We’ve completed the concept and initial design of the first TestCase (no codename yet :D). Here are some things this testcase will cover: minion control, very simple resource economy, cannons, magic flux, crystals, carts and loots of barrels!!
Everything is ready and we are busy implementing this testcase. Simon is working on some assets, since my modeling skills would make pong look graphically advanced **grins**.
The last couple of weeks, i’ve started working on some basic gameplay play-tests. The current setup features a sort of RTS, but where you can walk around the world in third person view. Skinned animation support is currently missing from the engine, so the primary agents in this testcase are barrels :). I added some very simple crowd control to make them more realistic. Check this video: Crowd control
Pathfinding was added to the engine to support this gamemode, here are some pics:
Goblins are able to accept commands from the player, which makes them move resources, powering basic factories.
Now it’s time to combine these features into some more challenging gameplay