Jump to content

Voxel Populi

Lazlo Bonin


Cubic voxel-based games have been striking a chord for me since I discovered them; and let's not fall for the hipster complex -- for most of us, that came with the popularization of Minecraft. But that interest grew past the 1m3 scaled sandbox world; the mere retro-looking style of games like Voxatron or the upcoming Cube World made me rethink my perception of quality graphics. In a sense, the simplistic, minimalist voxel styling is a potential revival for pixel-art, in a 3D fashion, and I feel like it isn't being exploited. Or at the very least, not enough.


A lot of game developers saw Minecraft as an opportunity to capitalize on voxels, leading to abhorrent commercial ripoffs and the like. But a significant amount of indies, lacking the financial incentive behind, seem to have "moved along" the voxel train, seeing how merely developing the framework to sustain and optimize the graphics was a pain. There was and still is a technical barrier in developing voxel games, which, in my opinion, hinders creativity and keeps a lot of indie games from ever seeing the light of day.


If that barrier were to be abolished, voxels may finally be perceived as they are -- a stylish rendering and interaction pattern that encourages creativity, for developers and players. They would no longer be the core element of the game, but merely a design choice, like using toon shaded graphics, for instance. That is, without losing their interactive benefits. We could start seeing voxel platformers, tower defenses, top-down RPG's, etc. The developers could finally focus on the game. And at the end of the day, that's the only thing that matters.


So today, I've finally decided to start concretizing this vision. I've started developing (or rather, at this stage, planning) a bare-bones voxel engine called Voxel Populi. Here's a link to my blog. It's the first time I'll keep a development log, and I hope it'll help me getting through the occasional lows of motivation I usually suffer from.


Why post this here on Leadwerks? Well, if you read the post about the development environment, you'll see that I intend to use Leadwerks (2, until 3 is out) as the rendering and physics pipeline for testing. While the library is meant to be engine, platform and language independent, this does still imply that it'll be fully compatible with Leadwerks out of the box. Also, I'm hoping I can get some occasional feedback from this community, if the project interests you.


That's pretty much it! I might keep you posted on Werkspace from time to time, but I'll mostly be updating the tumblr and Google Code page. Try to keep an eye on it!


Recommended Comments

In fact there is LOT of voxel style games in PC, made in another 3D engines, You can find that with Java 3D engine , Unity, Esenthel engine and others. You can find a lot on XBOX LIVE using CUBIC WORLDS mixed with non cubic avatars from XBOX LIVE, they are also FPS games using that CUBIC style and others ones.


Here is my sort of thesis on that Cube them :


Indeed anyone is free to make Cubic games, the advantages are :

- No complicated 3D models and textures to make : accessible for non 3D artists

- People can build levels using a library of BLocks

- You can create levels and stuff lot more faster because you stay re using basic CUBE stuff

Yes you can make any type of game, it's like using 2D or 3D it's just a view and you can make any type of game in boths.


But you'll loose a lot using CUBES :

- no more precise 3D models , no more realistic or realistic like stuff

- no more unique and precise textures

- no more detailled characters (it won't match sometimes to mix the cubic and realistic!)

- no more amazing gorgeous levels and characters ...

etc ...


I prefer to play TorchLight 2 that uses a 3D tile framework than some CUBIC version of it.TorchLight 2 is gorgeous, what Minecraft is not.

You won't fidn semi realistci games made with CUBES also.


After looking at Cube World, i find it has amazing features, gorgeous lightening and shadowing system on cubes, and lot of custom RPG elements. I find it lot more gorgeous than Minecraf, why ? Because Minecraft an it's textures ... i don't know but it's not my taste perhaps, i prefer the simple shaded cubes of Cube World.

Like i prefered simple colored cubes of Dot Heroe game on PS3 :


The game was old school and good on PS3, but i didn't like the simple Choppy animations, i found map regions too short, i even didn't finished the game, caus i get borred, even graphics borred me.

they could have done ZElda Wind Waker style graphics that would have matched lot more for this type of game.So simplicyt, cubic style is not always a good way.


Cube World is appart, the amont of colors at screen remember Nintendo colorfull games, the sahding / lightening is smooth and great with no textures. It's unique cubic style.


Minecraft is just the concept of 2D Tiles and possibility to construc things , destruct 2D tiles in the game; but in 3D.

This principle have been done with Terraria also, Minecraft gameplay in 2D.


I play some old indie PC game Venetica and i won't have such pleasure with graphics if it was CUBIC.



I don't think all LE developpers will run after some CUBIC engine. the more people here come because we wan next gen engine for suing objects with normal maps, advanced effects (for mobile soon).


Terrain system, 3D tiles, modular building construction, re usable 3D parts , terrain works like a library also, more complicated to make than cubes, but you can have the re usability and have some library in fact :



Lot of games needed the realistic touch and it was what made them so amazing (even if you can't compare the technology evolution to today) :



Strateggy or tower defense games are so easy to make, you just need to make good 3D models for each turret type, good ennemies, and have just a simple level, no need to go Cubic, because it's easy to make compared to Crysis levels smile.png

But well , why not if you can make one.

Here is some examples of cubic games :


Some times it's not cube , but pixel mixed with 3D , and retro style that makes the game :


So simple retro can be great also :)


Cubes is style , good for indies to go fast specially non 3D artists, but there are other 3D style wihtout needing to go for cubic.

If you have a precise game idea in mind , go for CUBES, if not you should ask or make some vote system to knwo who needs that features with LE2 ?

If you would made some special version of the voxel features ? something new, original why not ? perhaps special lightening system or shaders for cubes ,you could get something good.

Share this comment

Link to comment

Props for the word-play.


Way back in 1992(?) NovaLogic had this tiny little booth showing Comanche Maximum Overkill which was how many in my generation were introduced to the term "Voxel". It certainly looked different and was just the cool thing on the block, no pun intended.


I'm not sure if voxels are really used in Micraft'alikes, those games seem best described as cubist.


I would like to see some kind of voxel object in the engine. Something that complements everything else. So one can drop in an overhang or cave at a particular terrain tile position.


Anyway, thanks all for the read. I'll be watching progress.

Share this comment

Link to comment
I don't think all LE developpers will run after some CUBIC engine. the more people here come because we wan next gen engine for suing objects with normal maps, advanced effects (for mobile soon).


That indeed was the case for Leadwerks 2, but Leadwerks 3 may attract a crowd for its easy to use API, pipeline, toolset, and portability. The simplest way I can picture making a 3D game, even with all alternatives open, paid or not, is still with Leadwerks (3).


Besides, it's just a neat coincidence that Leadwerks will be well integrated. I won't try to get Leadwerks users to go down the voxel road, but if they do, I'll be glad.

Share this comment

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Blog Entries

    • By Josh in Josh's Dev Blog 2
      Documentation in Leadwerks 5 will start in the header files, where functions descriptions are being added directly like this:
      /// <summary> /// Sets the height of one terrain point. /// </summary> /// <param name="x">Horizontal position of the point to modify.</param> /// <param name="y">Vertical position of the point to modify.</param> /// <param name="height">Height to set, in the range -1.0 to +1.0.</param> virtual void SetHeight(const int x, const int y, const float height); This will make function descriptions appear automatically in Visual Studio, to help you write code faster and more easily:

      Visual Studio can also generate an XML file containing all of the project's function descriptions as part of the build process. The generated XML file will serve as the basis for the online documentation and Visual Studio Code extension for Lua. This is how I see it working:

      I am also moving all things private to private members. I found a cool trick that allows me to create read-only members. In the example below, you can access the "position" member to get an entity's local position, but you cannot modify it without using the SetPosition() method. This is important because modifying values often involves updating lots of things in the engine under the hood and syncing data with other threads. This also means that any method Visual Studio displays as you are typing is okay to use, and there won't be any undocumented / use-at-your-own risk types of commands like we had in Leadwerks 4.
      class Entity { private: Vec3 m_position; public: const Vec3& position; }; Entity::Entity() : position(m_position) {} It is even possible to make constructors private so that the programmer has to use the correct CreateTerrain() or whatever command, instead of trying to construct a new instance of the class, with unpredictable results. Interestingly, the constructor itself has to be added as a friend function for this to work.
      class Terrein { private: Terrain(); public: friend shared_ptr<World> CreateTerrain(shared_ptr<World>, int, int, int) }; The only difference is that inside the CreateTerrain function I have to do this:
      auto terrain = shared_ptr<Terrain>(new Terrain); instead of this, because make_shared() doesn't have access to the Terrain constructor. (If it did, you would be able to create a shared pointer to a new terrain, so we don't want that!)
      auto terrain = make_shared<Terrain>(); I have big expectations for Leadwerks 5, so it makes sense to pay a lot of attention to the coding experience you will have while using this. I hope you like it!
    • By Josh in Josh's Dev Blog 8
      An often-requested feature for terrain building commands in Leadwerks 5 is being implemented. Here is my script to create a terrain. This creates a 256 x 256 terrain with one terrain point every meter, and a maximum height of +/- 50 meters:
      --Create terrain local terrain = CreateTerrain(world,256,256) terrain:SetScale(256,100,256) Here is what it looks like:

      A single material layer is then added to the terrain.
      --Add a material layer local mtl = LoadMaterial("Materials/Dirt/dirt01.mat") local layerID = terrain:AddLayer(mtl) We don't have to do anything else to make the material appear because by default the entire terrain is set to use the first layer, if a material is available there:

      Next we will raise a few terrain points.
      --Modify terrain height for x=-5,5 do for y=-5,5 do h = (1 - (math.sqrt(x*x + y*y)) / 5) * 20 terrain:SetElevation(127 + x, 127 + y, h) end end And then we will update the normals for that whole section, all at once. Notice that we specify a larger grid for the normals update, because the terrain points next to the ones we modified will have their normals affected by the change in height of the neighboring pixel.
      --Update normals of modified and neighboring points terrain:UpdateNormals(127 - 6, 127 - 6, 13, 13) Now we have a small hill.

      Next let's add another layer and apply it to terrain points that are on the side of the hill we just created:
      --Add another layer mtl = LoadMaterial("Materials/Rough-rockface1.json") rockLayerID = terrain:AddLayer(mtl) --Apply layer to sides of hill for x=-5,5 do for y=-5,5 do slope = terrain:GetSlope(127 + x, 127 + y) alpha = math.min(slope / 15, 1.0) terrain:SetMaterial(rockLayerID, 127 + x, 127 + y, alpha) end end We could improve the appearance by giving it a more gradual change in the rock layer alpha, but it's okay for now.

      This gives you an idea of the basic terrain building API in Leadwerks 5, and it will serve as the foundation for more advanced terrain features. This will be included in the next beta.
    • By Josh in Josh's Dev Blog 0
      A new update is available for beta testers.
      The terrain building API is now available and you can begin working with it, This allows you to construct and modify terrains in pure code. Terrain supports up to 256 materials, each with its own albedo, normal, and displacement maps. Collision and raycasting are currently not supported.
      Fast C++ Builds
      Precompiled headers have been integrated into the example project. The Debug build will compile in about 20 seconds the first run, and compile in just 2-3 seconds thereafter. An example class is included which shows how to add files to your game project for optimum compile times. Even if you edit one of your header files, your game will still compile in just a few seconds in debug mode! Integrating precompiled headers into the engine actually brought the size of the static libraries down significantly, so the download is only about 350 MB now.
      Enums Everywhere
      Integer arguments have been replaced with enum values for window styles, entity bounds, and load flags. This is nice because the C++ compiler has some error checking so you don't do something like this:
      LoadTexture("grass.dds", WINDOW_FULLSCREEN); Operators have been added to allow combining enum values as bitwise flags.
      A new LOAD_DUMP_INFO LoadFlags value has been added which will print out information about loaded files (I need this to debug the GLTF loader!).
      Early Spring Cleaning
      Almost all the pre-processor macros have been removed from the Visual Studio project, with just a couple ones left. Overall the headers and project structure have been massively cleaned up.
  • Create New...