If you've noticed an increase in the amount of voxel-based graphics around the place, this is why.
Voxatron is an arena shooter that takes place in a world made of voxels (little cubes, kind of). Everything in the game is displayed in a virtual 128x128x64 voxel display, including the menus and player inventory. If you look closely, you can sometimes see the inventory (score/life/ammo) casting a shadow on some of the objects on the ground.
I've been working on voxel rendering and modeling tools for a long time now, with the ultimate goal of making a large explorey adventure game. About half a year ago it fused with work I was doing on arena shooters for Conflux, and this is the result.
It's quite a simple game at heart -- mostly just Robotron set in a 3d destructible world with goofy creatures. I'm unsure how major the implications of destructibility will be for gameplay, but it sure is fun to blast away pieces of wall. I've also added an experimental wall-building pickup you can use to construct barriers to hide from scary monsters.
The game takes place in a small set of arenas. Some of them feature rooms with set action pieces, somewhere between Knightlore and Smash TV. This is some of the original adventure based design sneaking back in, and an excuse to create thematic environments.
- Custom software rendering with soft shadows.
- Built-in sound and music synthesizer (also used to make the trailer music).
- Playback & post game recording.
Voxatron will be ready later this year, but I'll create a single-arena preview version too.
Wow, looks amazing man. That lava part looks so smooth, I'm suspicious if it's even real! Hahah.
Have you got enough CPU cycles lying around to put in some Dwarf Fortress/Minecraft esque voxel interactions? Like say, fuel voxels like wood or coal that slowy burn away when ignited?
I've been kind of curious myself if I could port this whole lowrez world allowing for high level interaction with said world concept away from little cubes and over to say a really lowpoly polygon world. It would look sort of like Starfox only with a better frame rate, heh.
The video compression & low resolution helps the lava! The waves are only around 5 voxels high, so you can really see the steps in fullscreen.
Yes, actually there aren't so many voxels to take care of. It depends on the world size of course, but at 256x256x48, that's similar to managing a 3k x 1k 2d map in the same way.
I played around with some water simulations -- semi-randomly processing around 5% of the world each frame. If it's a water voxel, move it down, across, or stay still. It looks pretty hilarious, and slightly.. academic. But could be nice for a different kind of game.
I'm more or less crossposting this the forum, but a linux version of this would be mindboggingly awesome.  You might even be able to get community help with packaging if that's a hurdle for you. (You wouldn't need to provide the source for this or anything, mind.)
Yes, this looks rad. "custom software rendering" - does that mean high-level (like generating vertex buffers for opengl based on your voxel geometry) or something low-level (like you're rendering to a screen buffer without opengl)?
dMITIC - the player can shoot 8 ways. It's actually just a fluke it doesn't happen in the trailer (maybe because I was grappling with video capture hotkeys)
csigh - for sure. Perhaps not the adventurey levels (it complicates the design too much) but 2-player robotron style levels on the same machine.
dcco, efnx - the rendering engine is quite simple and brute force. It's all in software, and each frame everything is 'blitted' into a back-buffer voxel map. At the end of the frame, the voxel map is scanned for possibly visible edges and drawn as a bunch of polygons lit with a shadow map that is generated every frame. There's no spatial optimisation or anything, because the voxel data can change arbitrarily every frame and it's not worth calculating.
dcco - the physics is quite standard 2d platform physics. The main difference is that when pieces of wall/ground start moving, they are broken out of a fixed world voxel map, and then burnt back into it when they stop moving. So it's easy to let exploded monsters pile up etc. -- I just don't do it because the world gets too messy and starts to look like a pollack painting.
eobet - I haven't released any of the music yet. I'll make an extended version of the trailer theme for the soundtrack, and post it as a single mp3 sometime before then!
Great thing about voxels is they dont make use of any 3d processing power of graphics cards at all... as voxels are not polygons... so everyone should be able to run this game just fine... Guess it depends on processing power. Anyone remember a PC game called OUTCAST (1999) ? That used voxels too. (even after 11yrs the darn game is still bugged to hell - but shows off voxels quite well even though I hated testing it - told em it didnt work.. ah well). Good Looking stuff - love watching the vid, keep up the great work.. voxels a thing from the past that may be a way forward! :)
I am a man of my word - Chocolate Castle is now mine.  I look forward to the bundle.
I will resume my stalking of your site in approximately 3 weeks.  I will require 3 copies for myself and my friends, possibly 5 copies depending on the exact wording of the restraining order :)
EDIT - This was meant to be humorous, not creepy.  Sounded better in my head.  Oh well.
Looks fantastic.  I've always loved the use of voxels in games, that and fractals (rescue on fractalus and koronis rift being my favorites)...  I think it would be great if this could come to iOS (iPad ?) or maybe xbla or wiiWare though... it deserves a big audience.  Looks amazing :))
I'll definitely try to get the game on any platforms I can, and iPad is high on my wish list. It's about the right size, the control isn't too clumsy, and no publisher hoops to jump through. For now I'm focusing on designing the game to play well on desktop though. Fortunately it's quite easy to port later, as long as a given device has the cpu for it.
Voxatron (like your other games) looks utterly cute ;-)
I read in the above comments that you use a standard 3d renderer, but I had some thoughts about voxels:
since the camera is static, each voxel is always at the same screen position. So I wondered to what extend it would be interesting to pre-render each voxel as a bitmap, and attach some depth (z) data. Then the rendering would only need to render the visible voxels, color them, and sort them.
The rendering would probably very fast
Different shapes could be used instead of cubes (eg spheres)
The difficult point is about lighting and casting shadows: it would probably need a pre-render phase for adding some shadow data to relevant voxels.
The minus is that the camera could not change.
Well that's all.. I just wanted to share this.
Whatever happens, continue the good job :)
dcco, efnx - the rendering engine is quite simple and brute force. It's all in software, and each frame everything is 'blitted' into a back-buffer voxel map. At the end of the frame, the voxel map is scanned for possibly visible edges and drawn as a bunch of polygons lit with a shadow map that is generated every frame. There's no spatial optimisation or anything, because the voxel data can change arbitrarily every frame and it's not worth calculating
Does this mean that you generate new geometry each frame? Also, can you explain how your raytracer works? I notice in your video that the engine has only xyz translation.
Absolutely -  because everything is drawn from a kind of voxel back buffer, there's no reason it needs to be cubes. I'd like to experiment with this later on, giving the option to choose alternative renderers. Apart from using different shapes, it might also be possible to render nicer shadows/lighting in hardware. I quite like the look of the per-voxel lighting for now though.
As for speed, the main bottleneck isn't actually drawing the polygons to screen. A lot of the work is just shifting data around, doing the perspective transforms, and calculating shadows. I imagine drawing the voxels as sprites wouldn't help much because of the extra cache thrashing.
I do generate the geometry each frame I suppose, but just before it's needed. i.e. I don't first generate a whole model and render that -- I just draw polygons as I go. It's not raytraced or raycasted, it just draws exposed voxels as polygons from back to front.
The camera angle is set to the front mostly for aesthetics, but it does mean I can avoid a whole bunch of z divides during perspective transform (only need one per row). The engine can handle arbitrary camera angles but it turns out to be much easier to see what's going on straight on, and I like drawing the voxel models as if they'll be displayed as almost 2d sprites from side/profile. Otherwise it ends up being quite a jumble of harsh angles.
Thanks lexaloffle for the info. I have one more question! How do you determine what is visible geometry? Like, do you use vertex culling from opengl, or do you have your own function based on voxels? I've only done 3d games with panda3d, and that handles culling automatically.
Anyway, sorry for all the questions, but this game is really impressive. I've never heard of voxel graphics before. I started doing research on voxel engines as soon as I saw your trailer.
Actually, that's a good question.. I couldn't get ASDW+mouse control to feel right, so it just supports keyboard / joystick either with twin-stick style control or a single shoot button that locks your direction when held.
duo - no worries, I'm planning on posting a more detailed description of the inner working at some point, but probably closer to release.
About culling -- nope, I don't do any culling at all. All faces that are potentially visible are drawn back to front. Potentially visible just means that it's the side of a voxel that has no neighbour, and is facing the camera. So if you drew a hollow sphere, all of the far voxels would be drawn first and then drawn over.
A lot of voxel research seems to focus on scenes which are static to some degree, because often that's all that's needed. Voxatron has the requirement that the voxel data can change arbitrarily each frame, so there isn't much that can be done in terms of generating spatial data structures for the purpose of optimisation.
Very cool looking game.  Props to you Lexaloffle.  How did you get started learning about Voxels?  I'm struggling to find any tutorials other than hightmap based voxel terrains.  I'd love to have a play about with voxel world/sprite rendering.  Do you have any tips, or tutorial references you could point me (and I'm sure many others are also interested) towards.  Thanks, and looking forward to play the game :-)
Lexaloffle will probably tell us all about it after the game is released. It might not be good for the game if 10,000 clones came out at the same time.
What I could get of this (correct me if I'm wrong) is that the voxels are rendered with standard tris. This means it's not a standard voxel engine. Regular voxel engines render in a billboard (all voxels face the camera) style. They are restricted in degrees of freedom to make raytracing efficient.
With this engine, there is no raytracing. The cubes are made of tri geometry and rendered back to front, which just means that the far cubes are behind the near cubes. The program just goes through the voxel matrix, and renders the voxels it needs to render as cubes.
If other people are interested, this can be implemented easily in Panda3d. It uses python to call c++, so it is fast enough. Graphics cards get bogged down by having too many separate meshes. You would have to use the rigid body combiner (http://www.panda3d.org/manual/index.php/The_Rigid_Body_Combiner) to merge all the cube objects into a single mesh object to send to the card. I don't know how lexaloffle gets around this issue, but this is a way in Panda3d.
EDIT: Regarding performance issues, for a 512^3 scene, with 12 tris per cube, there is a max of 1,610,612,736 tris. Too many. But most times only a quarter of the scene will be filled, so 400 million tris. Better, and since panda3d by default only renders the outside faces, this will be cut down to 200 million. Lexaloffle said he has a routine to prevent internal voxels from being put into the scene graph. For simplification of programming this may not be necessary.
So, I hope this is enough for people to start experimenting.
The Linux porting is going well. You can try a test version of Jasper here (it shares the same base code).
MrMonkfish - there isn't a lot available on voxel graphics for games, at least in the way I use them. You could try having a look at the Voxlap engine (which is now opensource), but it might be a bit heavy as an introduction. I'd like to post something on voxel programming, but closer to release (partly for the reason duo gives, partly because I'd like to focus on the game itself).
duo is right about the basic method for rendering. I consider the way rendering happens to be quite separate from the fact that the display is voxel-based, though. For example, it would be possible to swap the polygon rendering for something else like a sphere for each voxel, and leave the rest of the game as it is.