First of all, I am happy to introduce my new investor: Tristan van Essen, who is making all of this possible. He is a great guy, and I'm not just saying that because he is giving me money. :) It takes either a very smart person or an insane person to see potential in my work, so I'm glad that Tristan is both. ;) I hope that I can reward his good faith with success for both of us. So I am working on Voxel Quest full time now, which means this website will definitely be seeing a lot more updates.
That said, a screenshot:
That said, a screenshot:
And another:
And a video (sorry its a bit choppy, I had to capture in software this time vs using a hardware recorder):
I have put a lot of work into the GUI (probably too much), but thankfully I am done with it although I will add in features here and there as I have time (namely, make it more user-friendly). However, building out the GUI has allowed me to rapidly implement many other things that will be used in the engine such as fast AO, materials, shadows, and so forth. It's nice to be able to preview exactly how materials will look within the editor itself. I did some major overhauls on the performance side of things, and it performs quite well even on the Intel 4000 chip pictured here (as noted, the video is a software capture; normally it is much more smooth). I am relieved this worked out well because there is a lot of dynamic updating going on for mesh and buffer data. Aside from that, it is not resource intensive at all since it only updates when you move the mouse or click a button (and only uses 40 mb of texture memory, which could be far less if optimized).
The GUI is extremely flexible, much more so than what is demoed here. It can support any layout, and the layouts are liquid/fluid/elastic/choose your term -- meaning that I just drop in components and it autosizes them correctly and intelligently. It will even minimize container widths and heights to their smallest children, meaning you don't have to tweak column widths to see everything at once -- it all just fits.
You can additionally take any JSON data and it will build a GUI for you to edit it -- which is what's being done here. Not only that, but it can spit back out an updated JSON across a websocket or to a file, which means real-time editing of any of your game data (as I mentioned, my editor hooks up to a C++ server that hosts the game, or can be directly embedded in the game). One needed improvement is nesting the data more to take up vertical space - every node opens up a new horizontal container right now.
One thing that you may have noticed is the color, which is more vivid than your typical game engine (IMO). It uses the LAB color space. You are probably familiar with the RGB (Red, Green, Blue) and HSL (Hue, Saturation, Luminance) color spaces already. The LAB color space (and its variants) are generally considered to be the most perceptually uniform color spaces. Picking out a single color, this really makes little difference. The LAB color space really shines on interpolation. If you want to blend color A to color B using RGB, it will often turn grey between the two. LAB avoids this by keeping saturation and lightness more or less constant between two points, at least perceptually speaking. If you want to learn more about this, here is a good link. The easiest way to understand the difference between the two is probably a visual comparison of their linear spaces. Take a look at a LAB color ramp (top, mirrored) vs a HSL ramp (bottom):
The GUI is extremely flexible, much more so than what is demoed here. It can support any layout, and the layouts are liquid/fluid/elastic/choose your term -- meaning that I just drop in components and it autosizes them correctly and intelligently. It will even minimize container widths and heights to their smallest children, meaning you don't have to tweak column widths to see everything at once -- it all just fits.
You can additionally take any JSON data and it will build a GUI for you to edit it -- which is what's being done here. Not only that, but it can spit back out an updated JSON across a websocket or to a file, which means real-time editing of any of your game data (as I mentioned, my editor hooks up to a C++ server that hosts the game, or can be directly embedded in the game). One needed improvement is nesting the data more to take up vertical space - every node opens up a new horizontal container right now.
One thing that you may have noticed is the color, which is more vivid than your typical game engine (IMO). It uses the LAB color space. You are probably familiar with the RGB (Red, Green, Blue) and HSL (Hue, Saturation, Luminance) color spaces already. The LAB color space (and its variants) are generally considered to be the most perceptually uniform color spaces. Picking out a single color, this really makes little difference. The LAB color space really shines on interpolation. If you want to blend color A to color B using RGB, it will often turn grey between the two. LAB avoids this by keeping saturation and lightness more or less constant between two points, at least perceptually speaking. If you want to learn more about this, here is a good link. The easiest way to understand the difference between the two is probably a visual comparison of their linear spaces. Take a look at a LAB color ramp (top, mirrored) vs a HSL ramp (bottom):
Doing LAB interpolations in realtime would be way too expensive. So I precompute it. I use gradients to build a lighting ramp, which might seem like a naive approach but in my experience it is far superior to tweaking things like specular, ambient, and diffuse lighting. Even to experts, the mind cannot fully grasp how such colors are added together to form the result. A gradient is great because you know exactly how each color is going to act. If this lighting is too simplistic you can always add additional rules. It produces far from realistic lighting, but I am much more interested in style than I am realism. All of the chrome-ish textures you see above are achieved solely with gradient lighting - no reflection maps (although I will probably use reflection maps eventually since they provide better looking results).
Eventually I may use this GUI to power the Voxel Quest website (since it runs in a browser, obviously), but its other uses are:
Now that I'm finally done with this aspect (at least, past the worst of it) I am going to focus on getting the interesting stuff going for Voxel Quest, namely finishing up the terrain generation.
Eventually I may use this GUI to power the Voxel Quest website (since it runs in a browser, obviously), but its other uses are:
- An editor
- A scripting engine (sometimes its way easier to find a snippet of javascript to do something than try and integrate a C++ library into your build).
- Inventory Screen
- Stat Screen / Character Creation
- Intro Menu
- Settings
- Dialogues / NPC interaction
- Debug Information
- Popping up DRM notifications every five minutes >:)
Now that I'm finally done with this aspect (at least, past the worst of it) I am going to focus on getting the interesting stuff going for Voxel Quest, namely finishing up the terrain generation.
RSS Feed