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:
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.
I think this is what scientists call "meatspace" pic.twitter.com/IX4TddIi0l
— Gavan Woolery (@gavanw) January 13, 2016
Well, that escalated quickly pic.twitter.com/Yb642jAry6
— Gavan Woolery (@gavanw) January 12, 2016
A few lines of code to create some basic Conifers (all based off of a single pt-line distance) #gamedev #merryxmas pic.twitter.com/BtsS6MpJyH
— Gavan Woolery (@gavanw) December 23, 2015
What Went Wrong:
- Lack of focus. I bounced between many areas for a couple reasons. A smaller part of it was external input, which comes from many sources: people I interact with financially, those I talk with about design, and others as well. 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.
More characters, random color variations pic.twitter.com/lHwv7B8zva
— Gavan Woolery (@gavanw) December 17, 2015
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.
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.
Golf just got a little more x-treme #gamedev pic.twitter.com/Z6iAoXsBqR
— Gavan Woolery (@gavanw) December 9, 2015
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.
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.
Procedural (drunken?) swordplay WIP. Sword angle is random, hands figure out where to go. #gamedev pic.twitter.com/dTs6bpdUZx
— Gavan Woolery (@gavanw) December 3, 2015
FAQ
- When is VQ going to be released?
- Where is the gameplay?
- Why a custom engine?
- 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.
- 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?
- 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.
- 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.
- 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.
- 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.
Now holds pose well + ground contact. Kinematic/dynamic hybrid allows responsiveness to user as well as to world. pic.twitter.com/wCUGYsf1Jq
— Gavan Woolery (@gavanw) November 25, 2015
Debug squid 2.0: Added in arbitrary limb generation with automatic placement and constraint solving #gamedev pic.twitter.com/SISHIIdO72
— Gavan Woolery (@gavanw) November 17, 2015
Holding a pose with just ball joints (no motors or springs). Angles of rotation need constraint still. Built-in IK pic.twitter.com/ad6buYl2Ge
— Gavan Woolery (@gavanw) November 20, 2015
Not your mom's volumetric destruction algorithm #gamedev pic.twitter.com/nTksNanTfK
— Gavan Woolery (@gavanw) October 23, 2015
Came up with a pretty cool pathfinding algorithm - faster than A* and more flexible than jump point search #gamedev pic.twitter.com/a4jPmBeVry
— Gavan Woolery (@gavanw) September 17, 2015
¯\_(ツ)_/¯ #gamedev pic.twitter.com/tZjSk0OCPz
— Gavan Woolery (@gavanw) August 27, 2015
Added a little voronoi magic to the clouds...much better! #gamedev pic.twitter.com/5kZNeaSaTH
— Gavan Woolery (@gavanw) September 25, 2015
RSS Feed