Zanteogo wrote:New Update:

https://www.youtube.com/watch?v=X7MYf01X1Y4

Victor Tombs wrote:
I yawned a lot, Zanteogo. Gavan sounds pretty bored at the best of times but when he's tired he should stay away from that microphone. *chuckle* I enjoyed watching his little actor doing his thing. I'm not following development as closely as you are so I'm not sure whether this was a demonstration of how cool the actor is in striking a pose ( a very manly exercise type pose) or how cool blue grass can look. I wish the tired developer wasn't so obsessed with variations of the colour brown. A nice bit of stone grey would help.

Zanteogo wrote:Gavan is no showman, and he knows it.

Victor Tombs wrote:

Zanteogo wrote:Gavan is no showman, and he knows it.

He doesn't have to be, Zanteogo. I like his open honesty and his undoubted talent. I may joke about the video but I'm sure I will be happy with Gavan's completed project.

Talvieno wrote:Twitch stream is up, if anyone is interested.

http://www.twitch.tv/gavanw

Charley_Deallus wrote:I had just seen the tail end of it. Couldn't figure out fast enough how to register (didn't wanna sign in through facebook) and say

ALL HAIL SLY-MO-DI!

Gavan Woolery wrote: Voxel Quest January 2016 Update

Happy New Year! Ok, maybe a bit late for that, but I still want to do a review of the last year, what went right, what went wrong, and so forth. I will also try to preemptively address some of the common questions I get - please read the bottom of this post before you ask!

So, since the last update, there was so much stuff that I could not even cover it all in the video, and I won't cover most of it here. But here is a high-level list:

• More advanced building materials, building segment templates, building intersections
• Physics (via Bullet Physics)
• View distance now 16+ kilometers (formerly ~128 meters), and many rendering/generation tweaks
• Networking (simple deterministic model over TCP, only good for low latency play over LAN)
• Advanced pathfinding and basic character AI
• Character generation and animation system (supports physical responses, blending, in-game pose editing and shape editing, support for objects, much much more)
• Literally thousands of bugs fixed, many classes overhauled and cleaned up, several new utilities and more hot-loading for various resources.

What Went Wrong:

• ​Lack of focus. I bounced between many areas for a couple reasons. One reason was trying to work out deals with investors. There were a handful of significant deals that came my way but only two of them ate up any considerable amount of time. Each person that has come to me has asked for something different and most of these things I could justify as features in the long run for the engine (even if they did not have immediate priority). To be clear, this was my mistake, not the fault of any investor. Unfortunately it has gotten to the point that I am now fearful to engage with investors at all even though I could definitely use the funding. Overall, these were minor setbacks though. A bigger setback was bouncing between ideas personally. I was fearful that pursuing something ambitious was a bad idea for the short term and thought I should just pump out a prototype game as fast as possible. This led to a further lack of focus as this idea changed multiple times (based on community input and otherwise). At first it was going to be a multiplayer game (hence the networking I added in). Ultimately I decided that there is one game that I really want to build, and that was in the vein of my original vision. It does not mean that it can't be fun in the short term, or that it will take any longer to release something in the short term.
• Feature creep. I constantly found myself thinking system xyz was not good enough (and maybe it was not). I kept adding in features without a clear goal, just that I would "probably need them." I don't doubt that everything I added will be useful, but prioritizing is key. Believe or it not I have been well aware of this issue for a long time, and even in spite of my best intentions I found myself getting caught up in these problems. Often in adding some gameplay aspect I found some feature necessary. Admittedly, it is quite a different thing if you are working with a prebuilt engine and most of the functionality you need is right there.
• Being concerned with mass appeal. Yes, I need to sell copies, but I should not throw everything on the altar just to do it. Ultimately, if I am not making the game that I want to, I will lose passion. And if I don't make a game with targeted appeal, the odds are equally against me.

What Went Right:
I don't have the greatest feedback mechanisms but it seems people are generally happy and impressed with my work so far. Somehow things are all coming together in the code, in ways I would not expect. I had never written a fluid simulator, yet it turned out well. I had never written a character animation system, but I was pleased with the results. I had never written a networking client or server (beyond trivial examples), yet somehow I did it (even though it is a simple TCP deterministic architecture, it was not trivial to write). I guess if nothing else, I have gained faith that I can tackle pretty much any task, given enough time.

Other than that, not really sure what to put here. There are plenty of ups and downs, but I remain confident in the outcome of the future.



Technical Notes
The character animation system presented several new challenges. First of all, how do you efficiently ray cast with hundreds of dynamic limbs moving around on the screen? Well, limbs share a common trait: they are attached, and hence in the same proximity. So you only need to compute an intersection for one AABB (or sphere if you prefer) and that will let you know if you are anywhere near to hitting a limb in that body. Then you need not march into every limb of the body, but do an analytical prepass to determine roughly which shapes get hit, and collect some of them and march into those with a more complex algorithm. In this case, everything is just a line-line distance (one line being the view ray, the other line being the bone segment in question).

I had initial fears about passing in a bunch of bone data to the GPU, that the bottleneck would choke performance. But really its not so bad (really no different in practice than passing bone data to a vertex mesh), and you can animate a pretty large crowd - its not going to do Lord of the Rings scale battles, but that is ok (quality vs quantity).

Some of the biggest challenges came from trying to wrangle a physics system. There is a dichotomy between how the physics world wants to behave and how the user wants it to responsively react. This was compounded by trying to do complex animation systems with dynamically-oriented limbs over a custom collider for the voxel data of the terrain.

I'm going to add a few other technical notes soon as well, when I get a moment.


​
FAQ

• When is VQ going to be released?

The only honest answer I have to this is "I don't know" - I'd like to give a definitive date (and trust me, I have an internal one for that), but I've found in the past that giving any sort of date just sets it up to be missed. The two parameters I have for release are stability and fun factor. If it is not stable, and it is not remotely fun, it will not be released. It doesn't have to be anywhere near feature-complete, but it does need those two parameters. It is pretty stable overall, but I am still working towards making it fun. The first alpha release is targeted for "soon" - that is about as hard a date as I can give.

• Where is the gameplay?

As usual, I am working on it. Hopefully as this is progressing, you are getting a better idea of things to come. Nothing is set in stone yet and most things created up to this point have just been the pieces needed to build a game. I am about 2.5 years into development, and that may seem like a long time, but I did set an initial target for 5 years, and I know more than one person (among independent developers) who is on year 7+. The fact that this is built from the ground up contributes largely to that (and there is a reason for that, see next question). And the usual reminder: I am just one man, underfunded, fighting against all odds. While raising a baby.

• Why a custom engine?

Several reasons:

1. My ultimate goal is to empower *individuals* to create stuff. Not teams of 5 to 300 skilled people - software already exists for that. I want it to be easy for a single person to create something cool, and there is a gap in the spectrum. In the low end, you have things like Minecraft - extremely approachable, and its allows a lot of creative freedom, but the flexibility is rather limited. On the high end there is Unity, Unreal, etc - the sky is the limit, but so is the learning curve and manpower required. In the middle I think there exists a gap for people to work within acceptable constraints and produce content really fast - be it games, or movies, or animations, or whatever. Normal people won't go and pick up an engine. But they will pick up an engine disguised as a game.
2. Making games (and coding in general) is an art. From a business perspective, yes we can keep cranking out the same games on the same engines forever, and turn a profit. And if profit were my only goal, I would probably do that. But who is going to innovate? Who is going to take the risks?
3. The current system is broken. Make a game, ship it, throw away all the work and start a new game. I am a big fan of games that live on indefinitely, like Dwarf Fortress. If you are going to go in and make a game with a "forever" attitude, you probably want to own and be familiar with all of its code.
4. Like so many people, I have a dream game in my head. Maybe it is unrealistic (ok, it definitely is), but I am content with even pushing the envelope just slightly. Success is not black or white. Current engines are very well designed at producing your typical AAA static, linear game. They are not well designed for making the game that I dream of.
5. Custom built stuff is what I am good at. I am not good at using other engines, and in general I don't even like to use other people's code. I started doing what had the lowest mental barrier for me, and I continue to. I am not saying this is "right" or "wrong" - it is just a personal choice. There are things I can do with my own code that would be difficult or nearly impossible to unravel in a pre-built system that is ill-suited for the given purpose.
6. Back in the 80s and 90s, the glory went to 1 or 2 people. Now there are 300 person teams, and some guy's job is just to make the main character's right arm look really good (I wish I was joking). There is no shame in this, its a job and it takes a ton of skill to do well. But its hard to have any sort of individual expression when you are just a cog in a large machine. Nothing has changed since the 80s other than we figured out we could make a bigger, statistically stabler profit by adding more people to a team. I am just writing a game like it is still 1980.