This progress is looking fantastic. I remember when you posted about it here last year. The dedication put towards this project is admirable.
It's good to see that the engine is near completion and that (hopefully) we'll be seeing some custom characters running around the screen soon.
Are you building it in such a way that this will make networked multiplayer feasible in the future? If not, what reasons do you have for letting that fall on the wayside?
I consider myself a gamer, but I don't have a lot of time so I only spend my time on games that I think will give me a really high quality experience. This game is the one I am looking forward to the most.
Thanks! Networking is available, but not yet used for multiplayer. I'm not implementing it myself, but if modders want to that is fine. I've got way too many issues to address - as much as I would have like it in there, I had to prune my feature list and taking out networking made everything much easier to implement.
Yeah I myself can't waste much time on games, obviously. I only pick up ones that I feel are good "research."
If anything, your procedural approach should make it easier, shouldn't it? Instead of transmitting level files you can only transmit some seed data, after that only transmit the updates. This should also make it possible for all players to change the map itself through interactions, like in Minecraft. I'm imagining something like the concept of No man's sky, applied to a low budget / community project, where every player starts on his own island and through exploring the world and surviving in the environment, they can slowly get enough gear to explore the world overseas.
Btw. what's with the Swiss mug? I'm Swiss, so that made me curious :).
My initial investor was from Switzerland. As I mentioned in another comment, we found eachother on reddit. He is just a regular guy, gamer, and programmer - not by any means wealthy but he had enough in savings to get me some seed funding. By coincidence, I went to Germany right after we started making a deal (I was visiting my wife's family, who is from Germany). I made a pitstop in Switzerland to meet my investor, and bought the mug there in Zurich. :)
Procedural approach does make it much easier to generate content. I've already got everything in place to generate entire seamless maps with logical road, street, city, and house placement among other things, and it is pretty easy to extend for things like caves and dungeons.
The AI and emergent plots remind me of Storybricks, the AI game tech that Sony has licensed for their "EverQuest Next" game. Designers add personality and need/want attributes to NPCs who then run on their own.
Yep, I am twitter "friends" with some of the guys at Storybricks and others who have been involved with EQN. I'm very excited to see what they come out with.
When I view your videos, all I can think is "oooh, he's using some kind of page-fault type engine to pull in and dynamically generate cubical subdivisions of space"
So, assuming that's what's happening, why not pre-render/pre-generate a larger area than the visible area so that this faulting in process isn't as visible for a typical viewport pan.
Also, if you were to reduce the resolution, would that make the faulting/rendering faster? Seems like that would be a good compromise, as many of the demos now feel like the terrain isn't generated fast enough to make a playable game.
Oh, can you also demo destructibility in a future video?
There is some destructibility in this video, but I'll go over it more in the future. :)
You can make it go a lot faster by lowering the resolution, as I point out a bit down the page in the article. Every reduction of 2 in resolution ups performance and memory usage by 4-8 times, based on if the process is 2D (post process) or 3D related (chunk rendering). I'm continuing to add more optimizations to make things faster as I go along.
I am also going to add in better support for caching and prerendering - right now it all happens exclusively in GPU memory - I can easily expand the view even further with system memory and hard disk usage.
At the risk of having you compete with a project I would not even start, ;) you should dynamically reduce the resolution so that it runs in WebGL and create a backend in Akka or Erlang. You could get real funding with what you have here.
With polygons, you must explicitly pass in every vertex and corresponding data (unless you use a geometry shader). This gets huge fast - with just usually around 12 32 bit floats per vertex (position, normal, material and tex coords). That is 48 bytes per vertex. Not only that, but each vertex must be processed (transformed) and the resulting polygon clipped, which is usually a more or less order-dependent operation and thus not well designed for multithreading on GPUs (they do use tiling though to address this I think, but usually this means redundant calculations).
With voxels, positions are inherently stored, and guaranteed to have some cache locality if they are uncompressed. Thus, GPUs are really good a chugging through large amounts of bitmaps, which is what I am doing (only rendering to bitmaps). With teraflops of compute power now, you can do trillions of flops every second, and in my case I can render about 1-2 billion voxels per second.
Additionally, doing procedural generation with polygonal surfaces is much more complex (I've done it, I know). Implementing stuff like voronoi patterns (used for the rocks) is trivial with voxels. Not the case with polygons, unless you are just wrapping voxelized data. Its the difference between evaluating a graph at every point, and calculating the graph at only the needed points. Voxels are implicit, polygons are explicit.
Really, you can think of VQ like a really fancy graphing calculator (in fact, all of the structures are just an extension of superellipsoids) (http://en.wikipedia.org/wiki/Superellipsoid)
I actually never read any technical book beyond a few pages, and tend to avoid papers which are typically too academic for my needs (I really just look at raw source, if anything).
My best recommendation - dive in and start coding. You are your own best teacher. :)
Also, if anyone has any questions, please let me know! I'm trying to gain some visibility for Voxel Quest, so please spread the word if you can. Thanks!
Well, maybe not so much questions as honest feedback.
As a tech person, I'm amazed at the tech. As somebody whose greatest design skill is a straight line in Gimp, I find the graphics terrific and different from anything I've seen before in a game. However, as an RPG fan, the blurb on the Kickstarter page didn't resonate with me (apologies if you say more in the video, I had the sound off). There isn't anything about worldbuilding/characterization, or what the gameplay is about (considering that "RPG"s range from DCSS to Planescape Torment). You may also want to reveal some character models (even if they are just concept art).
I would definitely suggest stretch goals (for instance, you speak about supporting additional platforms, this could be one).
Oh, and hopefully you're reaching out to the usual suspects like Rock, Paper, Shotgun to get some coverage.
Yeah I did reach out to RPS, no coverage yet but they are typically dormant near the weekends so it could possibly go out next week (they have covered me in the past).
Yeah, to be honest I am really bad at putting together marketing materials and videos. I tend to talk about the stuff I'm comfortable with, which is mostly technobabble. I have gone into further details in one of the updates on the page, and posting a few more now.
It is a style choice mostly. :) I am fan of old isometric games like Ultima (which was really diametric), and Fallout. Also, simplest to store tilesets when there is no perspective projection - this means they can be rendered once to a larger bitmap for better performance, and that can be scrolled around on its own (versus redrawing thousands of chunks every frame)
Got it. So you couldn't do a view where you could see the horizon or anything due to the performance fixes. The scrolling wouldn't quite work out. It's interesting, I never thought to do it that way. I suppose you could do like spherical deformation postprocessing if you wanted to make this like tiny planets, but then the problem is that the sides wouldn't correctly show perspective. Anyway, it looks great.
You can tilt the view, as shown in the Kickstarter video, with a straight on projection or top down projection - both are difficult to process visually but you can tilt at a higher angle to get a different effect and visibility (might be good if people are crazy enough to try and build a side-scroller with this engine).
Thanks, yes - once the source goes out, I'm hoping people will do all sorts of crazy stuff with it. I will hire whoever is the best fit as well, within limitations of whatever my budget is. :)
Glad to see this on the top of HN! I saw you launch the Kickstarter campaign on Twitter the other day and was instantly blown away by the detail in the engine. Looking forward to watching this progress.
Thanks!! I'd settle for a decent middle class wage at this point. Right now, I am effectively making less than minimum wage based on the hours I work. :)
Well, I will put some money in the kickstarter campaign. When the source code is released, I will put my hands on it. :-D
You can make a GPL version so you create a community of users with dual license for commercial developers-artists so you get much more money than the ridiculously cheap 30Ks.
You can make great engines, but probably for creating amazing content for your engine you need artists.
Question: you're using the super-fine voxels for the aesthetic, (and it does look amazing), but only coarse grained voxels for gameplay? I can see the trade-off makes sense, for the reasons you mention (path-finding, monsters can get through).
It's just that a fine-grained modifiable world would be super-amazing. It seems to me that your rendering tech could do that just as well... if the edits only occurred on-screen, they are manageable (and all the rest can be rendered off-screen to bit-maps and cached, as you do now).
Of course, what I'd really love is a living world, which also changes off-screen. e.g. erosion. But I think that may be asking too much of present-day hardware...?
marketing advice: copy notch. Do little updates as often as you can, for every small thing you do. It gives you energy, engages long-term followers and - most important - is advertising, so more people know about it.
Good question - you can add in fine grained details as well. The macroscopic chunks are used to make quick calculations. Then on top of that, it sees whether or not the chunk contains microscopic changes, and if necessary recalculate a path or collision or whatever.
Erosion: doable, but not something I'm going to tackle right now. I originally built errosion in from the start to try and create realistic maps, but it turned out to be way simpler and faster to just pull in real world heightmaps and mix them together in patches, even if not realistic.
Marketing advice: taken. :) I'll be updating more frequently now, especially with the KS campaign going, which is pretty much a full time job right now.
I remember the last post about this engine and loved all the details. There's a huge amount about voxels I don't know, and the author always has such interesting insights.
I'm totally sold, just backed for the Platinum badge.
You mention a few games as inspiring traits of Voxel Quest -- most of which are quite obvious -- including Hearthstone. In what ways was Hearthstone an influence? Art style, or something beyond that?
Edit: Just finished watching the entire video, it really does look fantastic. I will say, the one off-putting part of your game design philosophy for me was the whole "no long-term progression" thing. I find the way Rogue Legacy handles this a beautifully rewarding mashup of the roguelike quick permadeath and the feeling of making overall progress in the game world.
The game is largely based off of CCG mechanics, but not the way a traditional CCG plays so much. Items, skills, classes, and monsters each add their own unique mini-rules to the game, based off a larger set of common rules like Hearthstone. Superficially, it plays a bit more like Dwarf Fortress.
Funny comment about the permadeath - Rogue Legacy was exactly what made me realize I did not like unlocking. Nonetheless I'm aware of the drawbacks of permadeath, and I will do what I can to address the communities wishes (there may be various game modes for people who hate permadeath and want a progressive, traditional RPG). Spelunky is, and has been, my goto design influence for years (not the sidescrolling and platformer mechanics, but just the pacing of the game, how it handles various design choices, etc), I still consider it one of the best designed games of all time.
I've been looking forward to Voxel Quest since I first read about it last year - everything about it seems to appeal to my taste in games. Great to see all the progress you've made!
I use Trello to manage my project. Google docs to do design documents and other spreadsheets.
There is a section of code where I adjust some important constants frequently (for chunk, buffer sizes, and other vars that are constrained at compile time for now). In this section I have a commented area for quick todos and reminders, for when they are too trivial to add to Trello or I dont want to forget them.
For other details on my work environment:
I have 4 monitors - 3 primary ones to code on, and a forth to run the game on, fullscreen if needed (i.e. for recording). I use Sublime Text by habit, even though I compile in Visual Studio. I also have a bunch of batch scripts to automate C++ stuff I don't want to deal with (LZZ for automatic header generation is crucial for my sanity).
I also have several apps running in windows to reconfigure how the desktop works, allowing desktop switching and other stuff (I'm on Windows 7 right now). I used to program on a Mac, so I actually changed my keyboard to be more mac-like (switched the control and alt keys on my keyboard and reprogrammed them in the registry - hehe).
Woo! Its not really a game yet, but constructing an engine from scratch was a decision I made with intent. I've still got three years on my projected timeline to go, so I will be working further on making it a game. To use my goto comparison, if you look at the early days of Minecraft, it was just a cube-placer. Now most people call it a game. :)
Both - initially the engine source will be put out to help boost the community and mods around the game - a game is being built so that relevant features are added to the engine. Kind of dogfooding my own engine I guess. :)
I'm guessing Gavan would like to protect his work a bit and not just give out licences to do anything you want with it - if others want to commercialise, he should get a fair cut, otherwise it's going to be a hard sell to investors. IMO that's completely understandable. I find it sad that things like non permissive CC licenses are regarded as so bad in the open source community - making a project like this completely open is very hard to do as a full time job because of that.
I will put it up on github soon :) License requires a game key for now, but will be open sourced eventually if I can afford to do so. (see other comment on open source)
Full source will be distributed with every game key, similar to licensing the Source SDK from Valve, but that is API-only IIRC. I would really, truly love to open source the whole thing but have to pay the bills for now. I think I will open source it if possible once I have made enough money to survive a few years (If I even get to that point!).
No royalties or fees are charged.
I also consider any licensing deal offered to me with pretty loose restrictions (and I have had two bigger requests in this regard so far).
If/when I get to the point of opensourcing, it will be a very permissive license - like ZLib or MIT.
I'd like to know that too. Right now, I think the engine looks more interesting than the game -- but the engine is really only interesting in as much as I can play with it...
Thanks! My own devising, but really based on existing techniques. Although of course it will be "published" since source is going out. Its actually based on just two things - one is the same heightmap used for the world, transformed and overlayed several times to produce unique cracks (it reads this based on the world position, and then does a whole bunch of sin calculations and stuff to make it look random). The same map is used to add in sediment and grass, just more permutations on the calculations. The other is voronoi patterns. It combines these to form what turned out to be surprisingly unique and cool looking (even I was surprised how it turned out).
It looks awesome. But without following this project up close it's really hard for me to see what changed since 12-6 months ago when I saw the last video about the engine.
And what will the actual game be about? From the video I'm not sure if there is an actual plan yet.
You can find some more details about the game on the Kickstarter page (some good questions answered there in the updates section as well, with a link to the design doc), in the about section, or on the Steam Greenlight page (http://steamcommunity.com/sharedfiles/filedetails/?id=245148...)
As usual, video editing and marketing are my two worst skills, so I'm not very good at putting together all this stuff. :)
The marketing of the game gives me honest concern. It is the quintessential "list of features" that is indicative of technology made without acknowledging a critical, artistic perspective - that's even true of the title "Voxel Quest." If you can correct this and gain understanding of what the game _represents_ and what areas you _want_ it to be critiqued on, it will become both easier to design and to market. Narrowing always clarifies things.
There is one aspect in which you do show a definite perspective, and that is in the use of a simulationist philosophy: Everything done in deterministic, procedural, emergent ways. Now, one of the ways in which this philosophy gets challenged is the issue of "you don't know what you don't know" - if your simulation is built upon bad premises, then it's garbage in, garbage out.
So then, if you want to find the same kind of successes with the approach as something like Dwarf Fortress, Spelunky or Minecraft, you have to actively acknowledge where your simulation becomes intentionalized by the assumptions you make about how the world works. At that point you are in the business of making critical arguments through your game and the workings of its systems: Things like how the economy is tuned, frequency of combat, or average NPC reactions to violence, all send unavoidable messages about the totality of the world you make.
You can literally pick just _one_ thing that characterizes the world, consider it in depth and tailor every other system's features around it, and have a fine game. Even Dwarf Fortress, which is extremely deep, shows intentionality in that the details it focuses on are descriptive and categorical(types of rocks, individual organs) vs., for example, being spatially accurate like the physics simulation of a racing game. What makes DF's detail cool - and what makes it a big, complex game instead of a tiny one - isn't that it attains atomic precision, but that everything adds up to a specific, detailed, believable narrative about fantasy characters doing the "everyday things" we expect to see in a fantasy world.
To put it another way: Eliminating things from the game makes it impossible to criticize those things, and every game eliminates something! But the things a game does show should have a ton of care put into them.
If you're doing all of this right, you'll be up at night with some fear over the internal struggle of the design decisions, instead of the actual production or marketing; you are already demonstrating the necessary skill to do those two - you have very nice graphics to show off in your trailers, which is a great entry point.
The only reason why the marketing looks hard is because there's a lack of design intent, and thus nothing but bullet point features after you show the graphics. But the design can act as a master plan for the marketing, as it allows you to go on at length about the things being conveyed through the systems, vs. what the systems are, where your effort on details is going to go, and how you want the overall play experience to expand over the coming months.
All good points, thanks! Many of the details I failed to convey because I targeted my past audience (people who already saw my old updates) instead of current audience (people who have no idea what Voxel Quest is). But even with that in mind many of your points still hold. Thanks for the detailed, thoughtful feedback :)
To be able to do this fulltime is really a blessing (or a curse maybe, because it is extremely hard work). Was not easy getting there - I was turned down by every single investor I ever approached (many), and threw a hail marry pass on reddit of all places, met a gamer/dev there who gave me a small amount of seed funding to get started (the rest is based on savings/severance from my old job). Now investors are knocking on my door, rather than the other way around, which is cool (and I really do appreciate everyone who has approached me, I don't take it for granted).
Great question about hotloading - everything is data-driven, no realtime scripting yet, unless you count the GLSL as scripting, which can be hotloaded. And really, the GLSL is a huge part of the scripting process - it is simply awesome to use for scripting, especially so in the context of voxels. It has blazing fast compile time (I hit refresh, refresh over 40 shaders faster than I can notice a delay) - and shaders obviously compile to be very fast. I have intentionally avoided other scripting - for the same reason Unreal went to a pure C++ engine.
Unreal has the Blueprint scripting system though :). But I am not going to argue as I don't have enough of the relevant experience. Besides your About page has cleared my questions (AI plans are quite ambitious :)).
Keep the good work! Looks awesome, and it was my dream to create such game long time ago, but never happened. The tooling also looks amazing and powerful!
Are you using any sort of acceleration data-structures to manage your voxels or just storing everything in plain 3D array of positions? I imagine you can run into memory issues there if you don't account for spatial sparsity in your voxel data?
I'd be curious to know if you're something something like run-length encoding (RLE) or something hierarchical such as a B-Tree?
See my response to ilolu - I most recommend diving in and experimenting yourself - maybe build something that is on the CPU first since it is easier to work with. Voxels are really intuitive, you are just manipulating a 3D array of data (more complex once you get into compression and things like that). I learned everything just by playing around with code. :)
Hey, with the way you have built this engine and/or with potential mods, is it possible to change the camera angle to view the map out of isometric mode, for instance in first person?
