And now for something completely different.
The idea of writing a game in C# language is in itself plausible, since many commercial game engines (like Unity) use it for the actual "game code", but just for that, not for the underlying engine and especially not for CPU based graphics rendering. That's what I was doing with Codename Z, and while it was a fun way to learn C# while I was in the university, it could never be commercially released.
So I decided to start over and do it properly this time. I've been working on a new engine for the last year, using C++ and OpenGL, so finally the graphics hardware will be utilized. I chose these two for performance and portability reasons.
Cross-platform development with SDL
I've been experimenting with cross-platform development for a time now, and after many dead ends I have finally found the SDL library, as it descended from up above in an angelic choir. As it turns out, this library serves as the basis for almost all indie cross-platform games.
SDL stands for Simple DirectMedia Layer, it provides a uniform way for handling otherwise operating system dependent stuff like audio playback, keyboard, mouse, joystick, and graphics hardware. With this I can write just one single code and it can run on Windows, Linux, macOS, and Steam OS.
For the new engine I stayed with the idea of using voxels, but instead of a flat 2D representation I went for 3D. Voxels are really popular these days thanks to Minecraft and its endless stream of clones and look-a-likes, and also I think because it is easier to sculpt something with voxels rather than using a 3D modeling software, not to mention the learning curve. And since it's built with blocks it can be taken apart anywhere in any shape, thus providing a very good basis for a destructible environment.
As with Minecraft, voxels usually mean a world made out of uniform blocks (see figure 1 below), but there are ways to make it smoother, and this is where the Marching Cubes algorithm comes in.
The Marching Cubes
"Marching cubes is a computer graphics algorithm for extracting a polygonal mesh of an isosurface from a three-dimensional discrete scalar field (sometimes called voxels)." (source: Wikipedia).
The first image is a Minecraft-like voxel render, it is very blocky, not too life-like. The second one is the same data but using marching cubes with binary states, and finally the last one is utilizing the fractional values for the blocks. The polygon mesh is actually the same on the last two images, the difference is the interpolation. If the blocks still have binary values (0 or 1) like with the shed, the same 45° features remain, but with any other value the mesh will be distorted accordingly. Smooth features are generally suited for natural formations while blocks are for man-made structures, and it is up to the designer to choose which one is better in the given situation.
This algorithm was originally developed for medical visualizations such as CT and MRI scan data images, but since it will be handmade and less dense, I'm planning to do a few modifications, like the ability to mix the techniques from the first and last image, so smooth and very sharp features could coexist.
The list could go on long, I'm still at the very beginning of this project. For the last year I was implementing mostly core features of the engine, which are not so much to talk about, but were necessary as a foundation for anything else that will come after.
Some of the next major features I'm planning to do:
- Further experiment with voxel editing tools to make the process easier.
- Integrate a physics engine, namely the Bullet Physics library.
- Further integrate Squirrel programming language for the game logic. This is basically Lua, just a bit more mature, used by many Valve and Crytek titles.
- Find an animation library which has an exporter plugin for Blender, so I can make the animation there.