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):
- VQ uses an engine that I built from scratch myself, powered by OpenGL and C++. If you have a game key, you will have full access to the source, but only other users with game keys can play your mods or conversions (a bit like Valve's Source Engine licensing, except with full source access instead of SDK access). This model is in some ways advantageous to traditional licensing because the more games and mods that use the engine, the larger your pool of potential users is (versus charging a license fee for every game or mod that uses the engine). I am planning to support Windows, MacOS, and SteamOS, but alpha access will likely be limited to just one OS (I have already successfully ported between Mac and Windows, but I don't want to manage multiple builds at this point). Other *nix OSes will probably have to be implemented by other people, but the source is there for people to modify.
- VQ is one of the few game engines I know of that is truly volumetric. That means that every object is solid in a non-trivial manner. If you slice a brick wall in half, you will find every brick laid out properly in the new cross section. The same goes for any other material or object. It also supports boolean geometry - you can create a cube and "subtract" a sphere from it. Even more intelligent types of intersections are possible - for example you can notice in the buildings each segment is intelligently walled off when it is added or removed. Because everything is evaluated on a point by point basis in 3D space, it is extremely easy to define objects mathematically (in fact, every object is basically defined by a few equations, and most of the shapes are derived from superellipsoids). Every object is currently voxel based with the exception of grass blades, which were easier to implement with polygons. There are no "textures" in the traditional sense, there are only voxels. In this sense, the engine is kind of driven by 3D textures that are not painted on but rather apply to the entire volume of an object.
- VQ is 100 percent procedurally-generated at this point - the only trivial exception are some heightmaps from NASA, but even those are fed into a procedural generation algorithm to produce new and unique terrain. In the future, many entities will likely be manually generated in external programs, such as items and possibly characters. The entire program is only a few megabytes in size, which is mostly libraries that it uses.
- The world is seamless and consists of over 100 quintillion unique voxels at the default settings. That is 100,000,000,000,000,000,000 voxels. If each voxel were just a byte, that would be 100 million terabytes of data (I think?). Yet the game resides in a few gigabytes of memory between the GPU and CPU, and takes only a few megabytes of disk space. This is made possible through rapidly generating, rendering, and discarding sets of voxels which are described by higher level constructs (for example, one segment of house can be described in a few bytes of data, but the resulting object is millions or billions of voxels in size). By default, there are 128^3 (about 2 million) voxels per cubic meter. As a comparison, Minecraft uses one voxel (or quasi voxel) per cubic meter - of course Minecraft has a dynamic perspective, and runs on mobile phones, so my engine is in no way "superior." Some patterns are intentionally repeated but every voxel can be as unique as I want it to be (for example, bricks are mostly identical right now but I could easily randomize the size or extrusion of each brick).
- Every run is completely unique, but you can save and share world seeds.
- Support for an arbitrary amount of shadow-casting colored lights, limited only by the performance of your machine. Right now it does about 32 comfortably, which is plenty for an isometric game. It also uses a nonrealistic, stylized lighting model that favors vivid colors and soft shading. Finally, ambient occlusion and radiosity are implemented, but like the rest of the lighting they are performed in screen space. All rendering is deferred.
- Support for transparent voxels, refraction, and animated volumetric water. In most games, water is defined by a plane or boxed region; in VQ water can fill any shape, and every voxel is accounted for. While the base voxels that compose the water are truly volumetric, the animation is just a trick that occurs in screen space.
- All shaders are hot-loaded, and since the majority of generation occurs on the GPU, you can mod many aspects of the game in realtime just by modifying a shader text file.
- World generation is just about complete, but a lot of variations and new features will probably eventually be added in. Right now it can generate a full world with semi-realistic topology (after all, it is based off of terrain data from NASA). One thing you will notice that really differentiates the terrain from traditional perlin or simplex noise generators are the fractal-like drainage basins (in reality, these would not be so present under the ocean, but it is just a game). It has road networks between cities that realistically follow the terrain isolines as much as possible while avoiding bodies of water, and ship routes that avoid land masses. Cities contain networks of streets and alleys that all lead to meaningful destinations such as house or shop doorsteps. Multistory houses can be generated with varying level placements, towers, overpasses, and differently beveled corners on building sides and roofing. Doors and windows can open and close, and lanterns can be turned on or off; many more dynamic objects will be implemented in the future.
- Trees and plants can have their own sets of unique grammars. Branches grow and split realistically without strange seams or texture inconsistencies. Even the insides of tree branches contain semi realistic wood grains that merge and split properly. The engine allows for many variations of trees but so far I am only showing two basic ones (more to come later).
- The engine *might* support a fairly flexible set of mechanics that are easy to modify, even ones I don't use, including multiple card decks, dice rolls with arbitrary dice sizes, card selecting, shuffling, and discarding, rules for item and token distribution, etc. My initial vision was to create a digital world that players could easily replicate their favorite board games or pen and paper RPGs in -- being voxel based and isometric, it would be a great candidate for digitial versions of miniatures. This would be a bonus feature and other items are prioritized first at this point.
- The key differentiating feature is the AI. This deserves its own section so I will talk about it below.
- Like most roguelikes, the game is designed for relatively quick playthroughs: level fast, die fast, no grinding. I was inspired by many card games (similar to Magic the Gathering or Hearthstone) and a few nontraditional roguelikes such as Spelunky and Desktop Dungeons. Seemingly, the best games change your circumstances and push you out of your comfort zone via different permutations of a familiar set of rules (Chess, for example, has very few rules, but each board arrangement is kind of its own mini puzzle, and there are countless permutations for any given game).
- Every single game mechanic is deterministic - there are no dice rolls or random chance (which makes my company name a bit ironic I guess). I made this choice because I wanted a game in which any scenario was based purely on skill, rather than depending on chance rolls like critical hits. It also makes the AI a bit easier to implement as there is less need for fuzzy logic or probability calculations. The one area that is ruled by random chance is world creation - you might get a world that is generated in your favor or not, but either way there is a deterministic path to cope with whatever you are up against.
- There is a unified skill and trait system that functions not only across combat but professions, dialogue, and more. This system is driven by some common card game mechanics (every skill is basically a card that may or may not be affected by core attributes like strength, intelligence, etc, in addition to other circumstances). Even if you have never played a card game like Magic the Gathering, the rules should be fairly easy to learn and comprehend. There is potentially an element of chance behind which cards are available at a given time, but shuffling and picking mechanics have not yet been worked out.
- It is single player for now. I have to limit the scope wherever I can as this is already an ambitious project. There might be hotseat multiplayer eventually. Although I played quite a few multiplayer games in my teen years, I mostly avoid them now; from what I have read there is at least a small audience of people who prefer single player games. All that said, the AI should compensate greatly for the lack of multiplayer, as explained below. If things are really successful and there is high demand, I will implement multiplayer further down the road (first, I want to get a functional game out the door though.
- No "free to play", you buy a game key, and that's it. There may eventually be expansions or sequels, but I am generally against both unless you are really getting what you pay for (I believe that if an expansion costs as much as the original game, it should provide just as much content). Game keys will be priced in the $10-$20 range, depending on the period (cheapest during the Kickstarter campaign). If you are interested in when the campaign launches, you can sign up to be notified in the sidebar to the right.
- You can read more in the (very much in progress) design doc here.
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?