It has taken some time to get to updating this as I mostly update in the forums and on the KS page, but I am happy to let everyone know that Voxel Quest has been successfully funded! Also, in the last week of the KS campaign, I added in a perspective camera - this is an early video of it but I am demoing a much improved version this coming Friday.
It has been about 6 months since my last major update. In that time I got married and had my first child (it's a girl!). But aside from real life I've been neck-deep in voxels.
So what has changed? A lot - a huge amount. There are plenty of visual changes but also tons of things under the hood - not so much (premature) optimization, but really a restructuring of a good portion of the engine to make it easier to work with.
One small, but major change is the support for voxel super-sampling. Everything you are viewing has been rendered to bitmaps that are 1/4 to 1/8th as large as the bitmaps used for chunks in the previous video. This reduction in buffers for the chunks has led to a massive decrease in the memory needed to store chunks - since chunks are stored volumetrically, every reduction of 2 decreases memory by a factor of about 8 (2*2*2). So a reduction of 4 leads to 4*4*4 or 64 times less memory for chunks.
In the image above, I am using 1/8 chunk buffer resolution (8*8*8 or 512 voxels per pixel!). You would think such super sampling to be excessive, but it makes all the difference visually and ensures that no voxels get dropped (as you may remember in the last video, lowering the voxel resolution led to holes in the plaster and defects in other thin areas). It is also using 1/2 screen buffer resolution (1/2 1080p, stretched to 1080p). Lowering by a factor of 8 also reduces the number of ray casts and normal calculations needed by a factor of 64. Total memory usage is only 472 megabytes and it has rendered about 46 billion voxels without unloading anything (you may have notice how quickly chunks unloaded in the old video). I have a 3 GB video card but I've capped mem usage at 2560 MB to reserve space for the operating system (Windows seems to use usually only a few hundred MB unless a browser is open).
The TL;DR here is that it can now store massive areas in memory without needing to unload anything, without any major drop in visuals. There is still tons of room for "low-hanging" or trivial optimizations like better front-to back loading.
Another thing that has changed is the way the world is represented. The old terrain system was based on a heightmap. The new one is based on macroscopic chunks (you can see each cliff or bluff here is sort of cubic, but rounded off to look more natural. All this data is pulled from a volumetric buffer and makes it incredibly easy to calculate things like dynamic water. Right now each unit in this volumetric set is 8x8x8 meters large, but it can be adjusted. This is big enough to carve out sections of cave or dungeon and ensure that any type of monster will fit in there without hitting the ceiling or walls, making pathfinding more trivial. Speaking of which, I have added in pathfinding support as well (you can see this at 5:13 to 5:22 in the Kickstarter video). Chunks do not need to be rendered to perform pathfinding, as shown (first image below).Ensuring that the world is constructed properly and all roads are reachable when you have multiple levels, and ensuring that stairs are spaced enough to not be too steep, and dealing with a million other factors, was a big challenge (see second image below). :) I even tried to implement winding staircases to address the issue of small space within towers, but I pulled that feature for now (third image below).
I've also added in camera tilt - this was mostly to be able to easily see around walls, seen at 7:44 in the KS video.
The UI is another major change. The UI is tightly bound to the data storage, although the presentation layer and the data storage layer are completely different structures - its not MVC though, a paradigm I hate. I have built so many UI's I'm sick of it, but I must say I've gotten the hang of it. The VQ UI system (let's just call it VQUI for now) is built to address many of the headaches I've had in the past with UIs, namely:
Writing your own UI would seem like a bad idea in most circumstances, but I really evaluated every solution and most of them honestly suck. I would have loved to use browser-based tech like in the old VQ editor, but that turned out to be a really, really bad idea for multiple reasons I won't delve into (hey, I make mistakes like anyone else :) ). On the bright side, it was a good practice run for what not to do.
One really powerful thing in the UI is that you can autobind shader variables to sliders, as seen in the video (the part where the hue is adjusted). This works by using a shader preprocessor that I wrote, which already was in there for automating other tasks. You only have to surround a variable name with "@" symbols, and this will autobind it to a slider after you refresh the shaders in the program. You don't even need to declare the variable, it will do that for you, so if you quickly want to fiddle with a value, you just throw in one of these special variables.
This also has an important performance side effect - you can bake these values into the shader after you have changed them, so that you don't need to pass in a uniform (the preprocessor just declares a constant value and sticks it in the generated program). None of this effects the code while you are writing (it modifies the shader in memory, not the file you are working on). The impact has been huge - I can now tweak values without having to constantly save and refresh the shader.
So, you can see that I've faced many challenges - the devil is in the details as they say. There were a million other improvements and fixes to the engine, but I can't cover everything - too much other work to do now! I do have most of the pieces in place to actually start building a real, genuine game though - enough of this engine nonsense. :)
The Kickstarter campaign is live, give it a look (and some money :D).
Hi everyone - I know things have been silent for a while but I have been very busy working on VQ and preparing for the coming Kickstarter campaign. Just want to give everyone a heads up that the campaign will be out soon! Updates will definitely be more regular after this, but I have to carefully use my time at this point and each major update costs me a lot of time and effort.
Had an interview with Jonathan (Ithica), Branislav (Atomontage), and Miguel (Everquest Landmark), and myself on TSG.tv. If you have never heard of them, The Speed Gamers (TSG) raise money for charity by streaming games live. This week they raised over $500,000!
Update 4/22 10:00 AM PST: Now at #81
Update 4/24 10:30 AM PST: Now at #28
Update 4/26 12:20 PM PST: Now at #13
Update 4/29 1:24 PM PST: Greenlit!
Greenlight looks likely - as of this edit I am at spot #13 (typically the top 75 games get approved, by current standards).
First of all, thank you all the fans for your kind words and support up to this point (and even your "constructive" criticism ;) ). I have been getting many emails from all over the world, people offering music, art, modeling, localization, funding, and more (don't worry - I am planning to keep this company privately owned).
Right now I am working on implementing characters, AI, and interactions. I have decided to hold off on the Kickstarter campaign until at least June so that I can at least get the beginnings of these things in. I have barely tackled many of the difficult tasks to come, but I believe everything is doable. I have never encountered an impossible problem in code, but I frequently have to determine what sacrifices I want to make if I want something to work well/easily.
Until then, back to work! I'll post screenshots as soon as anything of interest comes to fruition.
I get asked this somewhat frequently, so I guess it is better for me to explain it once in a post rather than to everyone who asks. If anything is unclear, just ask me about it! Also, if you have not seen the latest demo, take a look now. Also, please vote on Steam Greenlight (cough cough self promotion).
Just a quick announcement, I have posted to Steam Greenlight. It is perhaps a bit early, but I figure the more awareness I have between now and my launch date the better. The Greenlight page is accessible here or via the side bar. Please vote if you can, thanks!
Where to start? It's been about 6-7 months since my last update, but I've been hard at work this entire time. I did not want to keep things hidden but doing big updates takes a lot of time. I think from here out I am going to just do micro updates with the occasional picture or video, and maybe stream my work on Twitch TV or something. There is a lot to talk about, too much to put here...so if I left out something just ask me. Some of you are new here, so some of these features might be a recap:
What is Voxel Quest, and why should you care?
Voxel Quest (VQ) is a single-player, isometric, procedural, emergent, voxel-based, roguelike, tactical, turn-based RPG. Which is nice, but there are like a million of those already. I've been a proponent of these buzzwords even before 2004 when I began work on the Genesis engine. That is to say, I'm definitely not the first person to evangelize these things, but I'm also not just jumping on the bandwagon. Beyond that, here are a few noteworthy features regarding the engine and the game, respectively (if you don't want to read about everything, I highly recommend at least reading about the AI near the bottom):
There are a few games that seem to be catching onto the importance of good AI, and fewer yet that actually have what it takes to implement it. One of these games is Clockwork Empires, and the other, I speculate, is the new Everquest, since they acquired Storybricks [EDIT: My mistake, Storybricks is still a privately owned company] - these would be my two top picks at the moment, but I still would have to see their implementation to judge. [UPDATE: I should also add Ken Levine's new venture to the list, it looks promising - thank you "Tonto" for pointing this out in the comments).] There are many games that claim they are going to create the dynamic, emergent, AI-driven worlds but seemingly have no idea how to do this, so I fully appreciate if you are skeptical when I say I am going to do the same thing. That said, I have been prototyping various types of AI for over a decade and I think I have something that will work pretty well, and it is all based on prior (and proven) art. To be clear, I am not building an "ultimate" AI that can comprehend English and so forth - the AI will actually be very crude.
These include such things as score maximization (used for pathfinding, planning, and traversing action trees), reconnaissance/knowledge gathering, deduction (propositional logic, queries, backwards chaining), and collaboration. The AI operates under a unified mechanism that basically attempts to maximize the NPCs "score" on any given turn by maximizing their comfort, wealth, social standing, and so forth - directly or indirectly, using some combination of their skills and existing knowledge. The AI can and will do everything you can do, including pursuing artifacts, conversing with other NPCs to attain knowledge, and even lie, steal, or kill. This is by no means a perfect AI, in fact, it is very crude. The key is abstraction - a minimal set of rules are abstracted, and the AI makes new and surprising deductions based on this rule set (if you are familiar with languages like Prolog, you already know how this works -- if not, Google it). Since the entire world is procedurally generated, it is ideal for the AI - it understands that a room is part of a house is part of a city block which is part of a city. If a model were imported from an external program, it likely would have very few properties that describe the characteristics of the object beyond the placement of vertices, normals, and texture coordinates.
Going beyond this, I have something that I think will make VQ truly stand out: I have come up with a method of abstracting traditional storytelling mechanisms into gameplay mechanics, which is actually mostly a result of the way the AI is setup. A storytelling mechanism is something that writers use to make a story interesting or surprising - even though most are, by nature, cliche, we still have an almost genetic tendency to appreciate them. Some examples are the hero's journey, character growth, overcoming fears, friends become enemies, enemies become friends, etc. Many mechanisms are based on traditional character archetypes. There are no prewritten quests or dialogue, I simply set the stage and the rest is the result of the rules of the world and the circumstances. Fulfilling archetypes, or fighting against the nature of your archetype at that critical moment, are all rewarded and punished appropriately within the game mechanics, making this perhaps one of the first roleplaying games that really forces you to play a role. Please do remain skeptical until I show you my implementation. :)
An additional bonus is that users can define new rules which the AI will inherently comprehend, just by editing a text file. This makes modding certain things extremely easy. You can even modify the mechanics of the game and the AI will still understand how to make the best moves (for example, if you edited the property sheet for apples and specified that they were poisonous, the AI would try to avoid them, or perhaps even mix one into some food to poison an adversary).
When can I play it?
Alpha invites are slated for September 2014. Anyone can get one, but you must purchase a game key, and the earliest opportunity for this will be the Kickstarter campaign which is supposed to be launched soon (date to be determined).
Why doesn't the game fill up the entire screen?
I am working on a solution to ensure that the entire screen is filled. As it is, there are memory and performance constraints that require only a certain amount of chunks be on screen, but there are plenty of ways around it. Additionally, it will probably be less present in the actual game as the view may remain more zoomed in (TBD). Chunks can also be rendered "offline" and stored to disk. Lastly, GPU memory size will increase quite a bit in the coming years as this game progresses - I suspect 8+ gigabytes will become the norm for cards to keep up the current generation consoles. A larger memory pool makes it easier to store and render larger amounts of chunks simultaneously, although there are other workarounds as well.
How good is the performance?
This is still a relatively early build, but already performance is pretty good...still tons of room for improvement though. My target release date is roughly 3 years out (public access will be much earlier though, sometime this year), so hardware will likely improve during that period. Additionally, the voxels can be scaled to any resolution so it can actually run on pretty low end systems, although at the sacrifice of visual quality. I am aiming to have it run well on midrange systems (for whatever is considered midrange in 2017).
What is with the name?
I know, it is kind of a "dumb" name - it was originally intended to be a code/placeholder name but it might end up sticking. Hey, domains are hard to get, ok?
Make games, not engines, right?
I agree. In this case though, I could not find an engine that did what I wanted it to do. Furthermore, the engine is almost as important as the game because I want to foster a strong modding community - if I were to use a prebuilt engine, my users would be subject to its licensing conditions. All that said, I'm pretty much done with the core world generation and rendering, and from this point forward I am focusing on gameplay specific items and AI.
This is overly ambitious, and are you insane?