LESS T_T
Arcane
- Joined
- Oct 5, 2012
- Messages
- 13,582
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)
THE GAME:
- 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.
THE ENGINE:
- 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 supports modding via Javascript and GLSL at the moment. JS support might eventually include or transition to Lua. Modding can be done over a websocket, meaning you can open a web browser on one computer and run the game on another. Right now I mostly use it to edit materials and colors in realtime.
- 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.
http://www.voxelquest.com/
Sounds very vague and ambitious, and smells vaporware, but the voxel engine looks impressive.
It's on Kickstarter now: https://www.kickstarter.com/projects/gavan/voxel-quest
edit: typo.
Last edited: