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.
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).
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.
https://forums.tigsource.com/index.php?board=5.0
for example a "sticky" thread titled "Game design resources" from one of the subforums:
https://forums.tigsource.com/index.php?topic=31350.0
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.
[1]: https://en.wikipedia.org/wiki/Delta_Force_2#Game_engine
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.
https://www.youtube.com/watch?v=BpT6MkCeP7Y
check out this blog too: http://raytracey.blogspot.com.au/