Often, developers wander off to "make an engine" partially as an excuse to put off making those scary decisions. But an engine isn't a game and if you want to ship something people can play (and not just make games themselves with) you do have to make that choice.
You've made an insane amount of progress, but I wonder if you're struggling with this too. If I can make two suggestions that might help:
1. Realize a negative choice has positive value.
Every idea or feature sounds cool, so the default answer to "Should I add ___?" or "Can the player do ___?" or "Can the engine support ___?" is going to be "yes" because it all sounds fun. But the end result is something that takes infinite time to produce. Your time is finite.
It takes courage, but I find I make better progress when I deliberately allow myself to choose not to do something. Remember, any feature you omit pays you back in the most important currency: time. By saying, for example, "No multiplayer", you're saying "Yes" to a lot of other features you will now have time to implement.
2. Make the game that only your engine can do.
You're in an unusual position in that you already have a very interesting, unique engine. Most developers out there just have half-baked clones of existing engines.
When you're trying to figure out what kind of game to build on top of that engine, focus relentlessly on the kind of gameplay your engine, and only your engine can support. For me, that's rich, detailed, destructible terrain. If it doesn't take advantage of voxels, cut it.
Looking at the videos over the past year, I see lots and lots of basic character animation. Every game engine can do that. It's not interesting to see yours can too, and it takes (took) a ton of your time to do it. Don't spend time catching up to other engines. Spend time building on top of what you already have.
I don't care if a character in the game is a simple billboard—I actually think billboard characters would look nice with the pixely voxel style—I'm coming to your engine for the terrain. Everything else is secondary.
Good luck! It's been inspiring watching you make progress on this.
That can also be a trap (one that I myself am particularly prone to given how much I love roguelikes and tool-building). When it comes to games, I'm just not wired right to enjoy hand-authoring content. So when I do game-like stuff, I tend to lean towards procedural generation because it lets me avoid that unpleasant task.
But, I've learned, painfully, time and time again, that that tends to be way harder than hand-authoring. It kind of makes sense. If hand-drawing a fun level is difficult for me to do, why should it be easier for me to write a program than can author a million of them? In some sense, the latter must be strictly harder since it is a superset of hand-authoring a few one-off things.
Tool-building does matter, of course. But sometimes you just gotta make some stuff.
Another option is to push it onto the player: make the gameplay itself creative. That can work (SimCity), but it can also fizzle out (Spore).
The problem there is similar, I think. With hand-authored content, you have to come up with a narrative path or maybe a tree through the possible game space that's fun to play. With player-authored content, the entire play space has to be fun. Otherwise they'll be able to make anything, but most of the stuff they make won't be fun to make.
Here is my tip this time: try to find a lot of anchors outside of the game engine. You can do design incrementally by defining what the "rules", "logic", and "lore" of the world are, in order to clarify it. For example, use a mind map tool like a writer to plan scenario ideas. Pick a genre of music and a visual design language and incorporate them into the game's identity. Consider the limitations of the camera and control scheme and allow those elements to shape the scenarios. Borrow plots and characters from stories you like. Compose an essay response to something you want to critique, and then figure out ways to turn that essay into game form. If you don't have ideas for game mechanics, you can develop the story more instead and you'll eventually find some story elements that convert into mechanics.
The more of these things you can piece together in a coherent way, the more it will start to look like a complete design where "the work is cut out for you", instead of being a mass of bad content to crank out. There are a lot of ways to go about defining the design, but you will have to find some anchors if you want good content without a lot of meandering and second-guessing. The meandering should happen in notes and sketches, well before you try to write final code or assets.
Oh, and all of this can be done with an eye towards marketing. You can opt to choose and highlight elements specifically to capture an audience. The hard part tends to be finding concepts that you're happy enough with to want to think about for months on end.
for example a "sticky" thread titled "Game design resources" from one of the subforums:
Also, I'd think people like to help with generating/brainstorming some ideas when provoked, like you're doing here with throwing around some thoughts. I can barely resist adding my $0.02 of random suggestions already :)
There is probably a name for this concept, but I don't know what it is.
Have you ever heard of the game Magic Carpet? See http://www.gog.com/game/magic_carpet . It had insanely good destructible terrain, base building and exploration. I think something like that might work extremely well with your engine and also there has never been another game quite like it that combined exploration and resource gathering with the almost RTS like base elements (and of course the fun of creating volcanoes and dropping asteroids on your opponent's base).
All software Doom, Quake, Wolf 3D, Rise of The Triad and such: that was still cool stuff.
The game programmer should control every pixel going into the frame buffer.
Here's an example of path tracing in "realtime" (ok, it's not quite there yet) on the GPU.
check out this blog too:
This gives just enough structure for players to escape the Second Life trap. (What happens to people who have no needs/problems in a virtual world? They go right up the Maslow Need Hierarchy -- to Sex.)
Hopefully, this will provide the right kind of structure to let players game-balance the game themselves. (And give them enough scope to invent their way into and out of corners.)
It turned out to be somewhat pointless because once you know how, you can easily skip the night phase altogether. A game where you can't do that might be interesting.
Also: preparing for floods. What happens when the river overflows or the storm surge hits?
Another idea: build a sand castle and see how long you can hold out against the rising tide. No bad guys involved, just waves. Almost a literal sandbox game.
Hey, it works in Minecraft. (But in Minecraft, you have to earn it.)
I didn't expect I'll be googling that phrase ever in my life. :o.
I'm a big fan of fostering creativity though restrictions, so this makes sense to me. I would be interested in any notes on how you try to realize that goal in the engine. It would be interesting to see the difference between limitations imposed by performance v.s. limitations imposed in the name of a focused creation experience.
In general, any time you're not "simply" (not that the problems are simple) creating a system that exists elsewhere (physics, liquid, etc), it would be interesting to hear your thoughts on where you choose to deviate from the 'norm' and why.
For other things, if I introduce some system I'd like it to be unique and have purpose. Many games do GPU-based particle physics for water, and the ability to have this produce any significant interactions isn't that great. My system is CPU-driven, and contains things that are rarely done in games like simulating pressure and a constant fluid mass, which makes for more interesting interactions (you could pour water down the end of one pipe to raise it at the other end, as just one example). Usually people find ways to modify the system that I would not think of (someone made a roller coaster in Minecraft using water canals IIRC).
Years ago, I loved to read their blog. Lots of interesting technical articles.
But development has pretty much stalled for years.
IIRC, these guys are also behind Humble Indie Bundle, so money should not be a problem for them but it would be nice to finally see them ship the damn game.
But a game needs to be fun and easy to understand. I hope VQ adds lots more fun things. Bombs. Bombs would be fun ;)
I think it's possible to make spending time on the internet trying to figure out what's possible an integral part of playing the game.
If he's reading this: how do you fund work like this? You said you're raising a kid, I've got two! Is this a couple-hours-a-night kind of thing?
I'd really love to help more people fund and follow their passions full-time.
Phew, I don't even have kids, and I can't maintain a couple-hours-a-night hobby between maintaining relations, dinner, and a fairly late bedtime.
Artistically, the voxels are too big to look impressive to anyone used to polygon graphics, and too small to give off the "pixel-art" aesthetic of Minecraft or Terarria.
I want to play the game evoked by the banner at the top of the page, but not the one I see in the video.
It would be better almost to go further in either direction: either make the pixels smaller and therefore the terrain and characters look much more realistic (probably technical challenges in doing this), or make them larger so it gives off the "pixel-art" look.
The big unproven thing is building something that is fun. I look at Spore as this great unbelievable game engine that accomplished exactly what it set out to do. But they forgot to make the game fun, don't be Spore.
Meaning if I purchase the Alpha game key, will that give me access to the game engine during Alpha to start looking at that side of things?
Watching the demo today woke up, in me, some long forgotten excitement. My son and I enjoy the hell out of Minecraft. It's a great game and it arrived in its space at just the right time.
What you're doing, though, is going to push things in a new, even more exciting direction, in ways that you can't even imagine yet.
The amazing thing here is how tiny this guy's voxels are while still keeping the game running at a decent framerate.
Compared to traditional polygon graphics: voxels are discrete elements in space (sort of like "giant atoms") while polygons are the surface of objects (cuts of planes in 3d space). Being merely polygons they have no depth (as GP said, they're paper-thin) while voxels are inherently volumes in your space. You could compare it to Lego vs. papercraft.
Do you find that to be pretty efficient compared to other methods of terrain deformation (ROAM,etc)? Pretty curious, since I did my big undergrad research paper on deformable terrain in videogames before the huge voxel craze.
EDIT. To give some unsolicited advice: From my experience giving presentations, if you want to give a demo that sounds good, I recommend around a dozen practice runs.
- ultima - Great customisation / open world, but that's already mentioned on the kickstarter page.
- LBA - I would love for someone to create next version in this engine. Can't explain why, but it seems to match so well in my mind. Especially after LBA2 went 3d.
Tinkerers will just want to poke around the code, and maybe make a youtube video.
Project managers will try to "fix" issues, "suggest" new directions, and basically try to get you to do things they want. :-P