How Does Voxel Quest Work Now? | Hacker News Reader

How Does Voxel Quest Work Now?

voxelquest.com

317 pointsgavanwoolery88 comments

Your work is incredible. Every time you post an update it's fascinating and humbling.

That being said, it's hard to be excited about the game, because there doesn't seem to be one. I'm looking forward to when you release the engine in a documented usable form so that people who are passionate about games--not game engines--will have a chance to use this amazing tech.

On the other hand, it seems like there's nothing you can't do, maybe you're also a genius game designer. Though I'd still like to see what other people can do with it.

Thanks - I agree with you on the game part, which is why I am buckling down on creating a simple game to ship within the next few months (this is outside of my long term goals for the game). I am open to suggestions as well as to what this should be - there is a thread on the forums about the prototype game and all ideas are welcome.

I really can't claim to be a good game designer yet. My primary goal really was to get this engine into other people's hands, and the only reason I am building a game is because I can't build a business off an engine alone, and I need to dogfood the engine to ensure necessary features. :)

Some sort of game where you design, build, and manage dams, canals, and water usage for a small coastal country might be interesting and let you take advantage of the terrain and simulation aspects of the engine. Plus you could find out what happens when CA really does run out of water, ha ha.

So, Where's My Water 3D? :)

Benefits of this idea: Quirky. Takes advantage of strengths. Easy to implement?

Wow, that would be quite fun! How does one sim water in 3d effectively in this sort of case? Is it basically a 2d grid with a third "depth" variable and some simple rules like "where neighbor depth > mine: +1 to neighbor depth on tick" or something?

That approach has the downside that you can't have water jets or multiple layers of caves with lakes above each other. Most "voxel"/block-based games allow blocks to be filled with different levels of water and then have rules to spread it around.

2 Examples:

In Minecraft, there are source blocks and normal water blocks. Water spreads from source blocks towards the lowest point in the area and loses one level (from 7) each step. If you put water source blocks close together, new ones spawn between them. Water just "evaporates" after a few blocks: If you dig up from a cave with flat ground into an ocean, water will spill to the ground and flow 7 blocks. But that makes it easier to handle for players. Example: http://minecraft.gamepedia.com/File:Das_Waterfall.png

Details: http://minecraft.gamepedia.com/Liquids#How_liquids_work

Dwarf Fortress on the other hand has infinite water sources that also have pressure, so hitting a water source with a tunnel will fill your fortress up to the level of the source block, because the water spreads infinitely and also can go up bends. FUN! (Especially if you hit one with high pressure = producing a lot of water. First thing you notice is that the frame rate drops to slide show speed, a few frames later there's water everywhere)

If you block it off, it remains. (vs in Minecraft plugging all source blocks makes water disappear)

This is a more realistic approach, especially if the speed at which the sources produce water is limited and they are only used at the map edges to simulate inflow. Or one could look into finite element modelling and other fluid simulation techniques and try to adapt them for game usage.

Cool info, thank you for sharing that's quite interesting!

The water simulation I have built has finite water and also simulates pressure correctly, as demoed in the past. However, on the downside it is infinitely elastic (a single drop will spread over a large plane, like oil in an ocean). The rendered water also does not correspond 1:1 with the actual water volume, so it can look buggy. And there are still a few minor bugs as well.

I noticed that it seemed to spread laterally much quicker than it dropped, which looked odd. I imagine modeling water in a performant and semi-realistic way is rather hard.

That's really cool. I wonder how you solve the elasticity problem in a way that is performant.

I can't help but see a Final Fantasy Tactics clone.

That would be interesting...Actually when I first started I wanted to achieve the visuals of Tactics Ogre programmatically. http://www.impulsegamer.com/psp/tacticsogre02.jpg

The only problem is that there is a good deal of content production and balancing that goes into such a game - I want to build a "simple as possible" game in the short term.

Would it be possible to produce a stub? Two example "units" for two example "teams" (4 units total), 2 maps, but plenty of documentation, allowing the community to create a fuller game?

What about a game like Worms or Tanks? Simple artillery firing with destructive landscapes. Maybe two castles firing siege weapons at each other?

Worms: http://ciaranmccann.me/wormsjs/

Tanks: http://www.addictinggames.com/strategy-games/tanks.jsp

> Maybe two castles firing siege weapons at each other

Sounds like Castle Storm [1].

[1]: http://store.steampowered.com/app/241410/

Rampart[1] was always one of my favorite console games as a teenager, and strangely addictive. Perhaps that would be a fun game to port (destruction and water are key game mechanics, plays well to a voxel engine, game play is already pretty well balanced)

[1] https://en.wikipedia.org/wiki/Rampart_%28video_game%29

I got one other suggestion for Rampart from another person - definitely a possibility. I would like to take advantage of building stuff. :)

Worms has been a common suggestion (as well as Scorched Earth) - definitely not a bad idea and I will likely incorporate some aspects of these games at minimum.

Sandbox games like Beseige also would be fun in this type of world.

The bombs are particularly compelling -- awesome work. In terms of potential for gameplay, my mind went right to Legend of Zelda. Going around, trying bombs on different walls was a big part of the gameplay for me in that game.

Yep - as simple as a mechanic as it is, I really enjoy discovering secret areas in these types of games, FPSs, etc.

Hi Gavan... Fellow gamedev here; I like your tech; it looks neat!

As soon as I saw it, I had a great idea for a game. It's pretty simple too... Imagine a sort of hybrid of Angry Birds and Defender of the Crown (https://youtu.be/Af0vFi4sSzw?t=272). Where you have to build up your castle and then knock down your opponents.

You already have pretty good walls, rocks, brickwork, etc. So you could use that for the construction phase. Then you'd need to add a variety of weapons; Ballistas, Trebuchets, Cannon, etc. Each one would destroy a few blocks in a certain pattern. Maybe you can unlock/upgrade weapons as you proceed. You'd also need some kind of physics to detect when blocks are unsupported and allow them to fall & destroy themselves.

I'm envisioning a simple single player mode where you take it in turns defending and attacking castles and then an MP mode where 2 or more players can defend and attack each other. You'd need some kind of replication system to report which blocks are created or destroyed during the game, but that shouldn't be too hard for you.

Let me know if you like my idea.

Thanks

Jan.

Yeah, actually when we were originally considering ideas it was not far from this, and will probably retain a few elements of this. We are dabbling with the idea of CTF where you build bases and try to hold a flag for the longest period of time, with a secondary objective perhaps being to destroy your enemy's base through whatever means (sabotage, artillery, etc).

which is why I am buckling down on creating a simple game to ship within the next few months

I love games where the mechanics of the engine are part of the gameplay. When I saw your little video of 'what happens if you apply the ripple effect to land?' I immediately thought of how fun that would be in a fantasy wizard fight. Great cartoon violence potential! I've really enjoyed reading your updates on this project, because of your excellent writing as well as your technological achievements.

ISTM you have a great platform here that would be suitable for a wide variety of gameplay styles, which will attract other creative people to your project to help. Can't wait to see where this goes!

Thanks :) I think other people will make this engine shine, or I hope, in the same way modders made Minecraft much more interesting.

I got a strong Final Fantasy Tactics vibe from your demo. I think your engine would be fantastic for 8-bit-style games set in a new, malleable 3D world.

If I don't make it, I'd definitely like to see someone do a tactics game in the style of FFT :)

At this point I'd say build a minigame collection. It's a no-no most of the time because it means "now you have two problems" but if all of them explore the engine, it sets the right tone.

I remember seeing the lack of design as an issue back in the initial trailer. My main suggestion for completing a design now is: spend an hour or two each day trying to kill the design on paper. As in - the only unknowns left should be tuning and balancing. Everything else - assets, systems, ui - should get a paper spec, and then be turned into tasks. This process makes for faster iteration than doing it on the computer since you can mix visual ideas with text. It lets you make bolder decisions up front and see the size of the game properly.

Not a bad idea actually - I have considered just pumping out a game every few weeks. It may end up sort of a hybrid of this path and focusing a bit more on the launch prototype.

throwing out my suggestion for a game here: networked multiplayer combat game, but make killing each other not the main goal, the main goal should be capture the flag, or find the treasure, or build a bridge to the enemy's castle. Maybe one team is trying to build a bridge over a chasm to get to the winning thing, but the other team is trying to sabotage them, blow up the bridge or something.

This is slightly similar to some of the prototype ideas I've discussed in the past (in the forums) -- so I like the idea! :)

How about a game like Populous? You're basically a god who intervenes in the life of his followers. There's lots of landscape generation, etc..

A remake of Blast Corps for the Nintendo 64: http://youtu.be/_N51L5h37VQ

It plays to the strengths of the engine: explosions and terrain deformation are key, and huge draw distance is not needed the way they placed the camera (likely needed back in the N64 days).

Massively multiplayer PvP marble madness?

I would love to see a puzzle solving game like Clark (https://www.youtube.com/watch?v=6dPVseD0Va8). I think the puzzles should be community-defined in some easy to create format (json, xml, etc) if possible.

This is right in the article:

"That said, the point here is not just to make a game (plenty of people are doing that already), but to make a unique engine, and that could not happen in a vacuum."

SDFs (Signed Distance Fields) are an amazing optimization to marching a ray through a scene. Unreal Engine 4 uses them for ambient occlusion https://docs.unrealengine.com/latest/INT/Engine/Rendering/Li... and soft shadows https://docs.unrealengine.com/latest/INT/Engine/Rendering/Li...

The author mentions Inigo Quilez, an incredible demoscene artist, who has an amazing writeup of how he uses SDFs for creating the geometry in demos: http://iquilezles.org/www/material/nvscene2008/rwwtt.pdf I remember when it "clicked" for me... instead of defining geometry and generating SDFs for use in shading, which is expensive, he was generating SDFs directly to be used as the definition for geometry! It's brilliant.

Neat - I was not aware of Unreal's use of SDF. I am consistently impressed with Unreal's improvements.

It took some time before SDF clicked for me, and IQ and Shader Toy were responsible for that. :)

Are you talking about IQ from Shadertoy? You can check out his stuff here: https://www.shadertoy.com/user/iq

I think one of the reasons there continues to be so much excitement about this project is that it clearly does not look like any other game on the market. It's only more exciting now that the renderer is fluid and the perspective not limited, demonstrating that the results are not an unpractical hack.

Thanks! There was a time when graphics coding was more creative (people get quite creative with what we have, but we can only take it so far). John Carmack was writing Doom's engine, Ken Silverman the Build engine, etc. Everything looked and felt different. The standardization of rendering hardware and APIs has become a blessing and a curse. On the bright side, it saves us from reinventing the wheel, but on the downside, there is some art in reinventing the wheel. When I launched Doom for the first time, it was basically Wolfenstein in terms of gameplay. But it was visually beyond anything I had seen prior, and the visuals created an entirely different experience on their own (and I used to be a large proponent of the "graphics don't matter" camp). It is incredibly punishing (from a business standpoint) to be in the engine business - even if you are one of the big guys, but I feel like somebody has to add a little diversity to the arena. Using these newest techniques is very refreshing to me because it allows for all kinds of tricks that simply are not possible in your traditional modern polygon pipeline.

Can this be termed as the near saturation of Game Engine technology? Or there are still many undiscovered ways in the tech stack to make it work?

as far as polygon stuff goes, your hands are more or less tied - there are only so many tricks you can use. I am finding a lot more flexibility with SDF, not just in terms of performance tricks but rendering in ways that are difficult with polygons, like warping the direction of rays to produce different transformations or deformations in objects.

There are a lot of undiscovered techniques. However, triangle rasterization is currently supported by widespread consumer ASICs with competing, but compatible libraries. It hits a "sweet spot" of performance and results given current hardware. Current predictions are that path tracing will get more common, since the computation cost won't be prohibitive, and path tracing can handle shadows and reflections more easily AND more accurately. SDFs are currently the structure of choice here, but I'm sure we'll see a lot of improvement.

For an example of the kind of improvement, think about how depth buffers are implemented. They're not just arrays of depth values, but they're hierarchical data structures which allow entire fragments to be queried at once. The same kind of optimizations for 3D SDFs might get hardware support in the future, but who knows?

This is indeed true; read any interview with Carmack from right before HW acceleration became mandatory.

If I'm not mistaken, the obtuse fast inverse square root algorithm came from early lighting engines.

https://en.wikipedia.org/wiki/Fast_inverse_square_root

I agree completely. But as someone very interested in game dev, I am also terrified by the idea if spending 3-4 years on just the tech. I wish there was a good middle ground.

As someone who is writing a real-time 3d engine, let me tell you the experience is incredibly rewarding. My math background is weak, but the practical applications of 3d maths that you will learn is invaluable. If you're interested in learning how a pixel is created on the screen from some arbitrary model in a lighting environment, nothing can really replace writing an engine. Give it a shot! http://web.archive.org/web/20150311211412/http://www.arcsynt...

Yes - it is relatively difficult to make anything that stands out, and venturing into engines is like making two games (or more) in the span of time allotted for one game.

Game's are hacks through and through, generally speaking. No technique works well in all aspects there are always tradeoffs. Even if something only works well for isometric views doesn't mean it's not good. Just sayin'.

Looks great. What does concern me is the VERY limited view distance. I assume this is a micro-voxel engine. So that in that small space there are millions of voxels. Scaling that up to give a reasonable draw distance is a challenge I have not seen anyone live up to yet.

If you like this style of engine check out http://www.atomontage.com/ and Ken Silvermans http://advsys.net/ken/voxlap/pnd3d.htm

Keep up the good work.

I mention it in the video, but it is somewhat buried - view distance is more a data loading problem than a rendering problem. I just have to optimize for faster data loading (right now it happens on the main thread so it locks the program for bigger data loads/unloads and makes it lag). Still pretty early in this respect, so a lot of room for improvement there down the road. I am friends with Branislav (Atomontage) and a long time fan of Ken's work. :)

Gavan's work is outstanding to say the least, I haven't felt like such a fanboy in a very long time. Every time an update is posted, I'm on the edge of my seat waiting to hear/see more.

Some people here and other places have noted that it is hard to get excited without an actual gameplay, but for me the gameplay, while a very interesting and essential point for the final product, is almost secondary. Just looking at all the ideas people have come up with around the engine is quite telling.

People are being excited, curious, creative, collaborative and kind about the whole project. Gavan's doing an amazing job at being transparent and honest, while patiently listening and responding to people. Even if these are the only things that ever come out of Voxel Quest (though I'm sure that won't be the case :) ), I'd say that's already a great achievement.

Thanks, I am honored :)

That draw distance is giving me Superman 64 flashbacks...

In all seriousness. Voxel tech is awesome and I can't wait to see some games implement it fully.

Haha - yeah it is pretty poor but I will fix it up a bit soon. I did get farther distances working "ok" but still need to work on optimizing it to load in data without lagging. Here is one shot with a farther view distance: https://pbs.twimg.com/media/CJ83yn7UcAATnkU.png:large

Nice, reminds me of Ogre Battle (but without fixed perspective).

For your first game, you'll probably want to pick a topic that either is not hindered by the draw distance or is even helped by it. Like the way the early Silent Hill games used the limited draw distance to create a spooky foggy town setting.

Also, Daggerfall had a fairly limited draw distance IIRC, which I didn't mind when I played it.

I've played in the past with ray marching http://williamedwardscoder.tumblr.com/post/26628848007/rod-m... (I eventually did it all on the gpu) so I'm curious how this is split between cpu and gpu?

Mostly GPU - the logistics of the fluid simulation are the only expensive thing that runs on the CPU really

Impatiently waiting for an engine + API docs that I can download and play with. :-)

Soon actually - I can't give a release date but source should be going out in the not TOO distant future. :)

Have you figured out what you're going to do with your billions when this eats up Minecraft? In all seriousness the bits and bobs you're putting together are delicious. I would say that the stories and games that people use to built it will be the most important part of its success, obviously.

I hope so! I'll settle for millions ;) ;)

Looking good.

Something about that land-based ripple effect makes my brain think the effect is happening in screen space. Wonder why?

Thanks - its actually world space :)

Speaking of world space, have you run into any precision errors in world space? The further you get away from the origin, your floating point numbers lose precision, so I've understood that doing world space transformations and comparisons can lead to artifacts. Have you had to compensate for this anywhere yet?

Yes I've hit these errors in the past. One way around it is to keep things local to camera space (as far as rendering goes).

And now I want to play magic carpet...

An ex-Bullfrog employee just told me they wanted to use my engine, so... :)

I really like the sprites they have some character though the shiny dirt is not really my thing. Any idea when content like structured gameplay or stories will start to be added or is this more like Minecraft where you kinda just play with the world?

Yep the terrain needs improvement. :) Sprites are just placeholders I bought from an asset pack. I am currently working on a building a small prototype game that will be very simple, along the lines of Capture the Flag - so not quite a story, but structured gameplay at least.

CTF? OK. between this and the axe, at one point you basically have to do voxelquake, just so that we can play with that engine :)

that might not be a bad idea for a 'simple enough' game, a fps within everything is destructible. four a side, some simple enough goal, a timer set to 20 minutes and you have a potentially very fun game.

/edit: in an 'afps' level design would make draw distance less of an issue aswell.

Thanks for the update! I really like your novel approach. Ray marching is pretty cool for scaling in procedural generated graphics so that you don't have to load entire geometries and cull most of it. Just render what you can see! :)

Nice trick with the objects.

I heard mention of single core and Im, afraid its already too late. Projects that start single core and get advanced enough are very difficult to convert, if not impossible without a total rewrite.

Well, raycasting is supposedly trivial to parallelize, right?

I use multiple cores for some tasks, such as the fluid sim - I only have not moved loading scene data into a separate thread.

>Arguably the isometric rendering looked the best of all the methods

I disagree just based on the few screenshots here. The isometric looks so generic. The latest version almost looks like a 3DS game (especially with the draw distance), but at least it has some character. The isometric screenshot looks like an iPhone RPG that I would see in ads but never actually play.

'Arguably'.

That's actually not an entirely uncommon reaction - some people loved the iso mode, other people thought it looked too much like a F2P game. :)

I'm among those that loved it. It had a really endearing charm to me which the newer methods haven't entirely captured. But that's outweighed by my excitement at what the newer methods have made possible. :)

But I love that look, I actually want to see videos of the first revision

You can find videos here: http://www.voxelquest.com/videos.html (scroll down)

rev 1 and 2 look better... 3 looks like everything is covered in oil.

Haha - thats an apt description. :) I've added in "real" specular (it was "fake" prior), and probably went a bit too crazy with the specular highlights. I need to tone it down considerably.

or just deep fry it :)

Reply on news.ycombinator.com