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.
Features:
- 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.
P#1183 Posted at 2011-01-04 14:57
tags: voxatron preview
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.
it looks awesome but there is something bugging me...is there any plan to make the player able to shoot in diagonal? you know, like robotron and smash tv
This looks awesome. Do you think you might post something that explains a little bit about how your graphics && physics engine work? Looking forward to seeing this thing come out
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.
Put out a nice game and be the next minecraft. I'm a big wimp in real life. I just get excited when I see something like this - so simple yet brilliant.
This new decade absolutely needs a new voxel game and this one looks amazing.
I own all your games, can't wait to buy and play the Mac version of this.
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.
Hi,
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.
@gludion
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.
@duo
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.
I'm extremely interested in the shadow-casting algorithm. I've been trying to get my shadows working, and even in the semi-static environment my voxel engine's working with, I can't get it working fast enough. Obviously a single, static directional lightsource affords some optimisation, but I still end up casting and checking over a million rays :(
I found about you and this game from wikipedia :))
i searched for info about voxel tech for games and here i am.
It looks absolutely fantastic.
if you could integrate the destruction into the gameplay your game should be an instant classic and you a millionaire... maybe
(some people don't have good taste).
I check in occasionally also. Just remembered that you are based in Japan and New Zealand. Hoping you are alright with the recent events in Japan. Wish you and your loved ones the best.
MisterCat, I went through the same process as you. The voxel renderer started off as a by-product of a raytracer using a regular occupancy grid for optimisation. That was about 6 years ago on a 600MHz cpu, and I couldn't get more than 5 fps out it for a 64^3 scene at 640x480. If you don't want to do any fancy reflections etc., just brute force it with polygon rasterization! For typical gamey world scenes it's not as expensive as you might imagine.
MIK3K, thanks for your concern. We're in Tokyo so got off pretty lightly. I certainly know a lot more about iodine-131 and weather patterns than I did a month ago though!
@DigitalD
I don't have a date for an alpha release yet -- my plans are still up in the air. I'm quite keen to get something out early though (along with Linux versions of my other games), so hopefully can announce something soon.
@isidor3
Everything is on the grid -- objects are first blitted to a voxel buffer and then the whole buffer is drawn to the screen at once. So it's not possible to move anything less than a voxel or to rotate it -- basically the 3d version of a low resolution pixel game.
@Iamogam
yes, there's a level & voxel designer built in.
@Kurbs
the editor feels a little bit like a sandbox mode.. you can throw in a bunch of items and play with them in god mode. Over time I'll add more stuff to play with which isn't relevant to the main arcade game side of things.
@oneSaint
Transparent surfaces are fun but slightly slow and not as useful as I imagined. The only variation in surface material I'm using so far is a reflective one, just by flipping all the voxels and tinting them (click for a larger version)
Level and Voxel designer built in . . . . SOLD!!!!
Actually, I was sold with the first video, but whatever. The excitement is renewed.
Please, where do I insert the money for this? I cannot seem to find the buy button anywhere. Hurry please, playstation network had my credit card information and I don't know how much longer I will have money in my bank account.
And to the guy above who would pay $20 for this . . . pffftttt, I'll pay $30 and I'll take 3 copies to start. Hmmm, can you sign my copies? Probably not. It's okay.
@macattack It's written in C with a software renderer. I'll post some details on the workings of the engine closer to release
@fskn ok-ish!
The 3d models are stored just with a simple raw dump of colour values, much the same way raw 2d image formats do. In fact, internally I represent a voxmap as a vertical stack of 2d images.
I have a compressed version of the file format too for sharing user-made levels, which is encoded in the form of a .PNG file with a thumbnail.
I have had this game in mind for the past week, and only now the word "voxel" popped back into my head. I Googled for "voxel block game", and lo and behold, I found you again!
I'm looking forward to the release of your game. Best of luck polishing it up! And thanks Voxel Man for the catchy music too.
Alright, I wonder that you might have tried to use RGBA then, for transparency, on those 2D images you stack.
Older games didn't have transparency, though, so I think it would add to the charm not having it here either.
Do you think you could release a new demo video soon..? I'm so eager to get this game!
Wow! I spent over a year working on a voxel engine (and the associated gameplay). In the end I abandoned it because I couldn't get the performance to an acceptable level. Here's the dev blog if anyone is interested
First off, this looks great, awesome job! Secondly, I'd like to see if I could pick your brain without revealing to much of your implementation.
You said that each scene you are calculating whether a voxel is on the "surface" or rather if it has an empty neighbor cube. You also stated that each map is basically a stack of PNG images. So does that mean you are using array based indexing to find neighbors.
The reason I am asking is I am tinkering around with a voxel based engine. I store my data in an octree so I can merge voxels an octree node either has all or no voxels. My huge bottleneck is walking the octree each pass, so I am very interested in other people's approaches to this problem. http://www.youtube.com/watch?v=wzelLGZ7W0s&feature=related
Wow, this thread is fully of really interesting technical discussion! I'm totally amateur so even this basic stuff is almost too much for me, but it's still really cool to read all of this.
Zep, I hope you consider talking a little bit about the behind-the-scenes aspect of this before it comes out. I know you don't want to spend a long time writing up stuff, and you also don't want to give away all your trade secrets ;) but, even if it's just simple stuff, we'd love to hear about it!
