After a lengthy period of thought (like, a minute or two), I decided to completely restart my work on All Things Die and start in a new engine with new content, new code, and new… everything. So I wrote about it:
Basically, I’ve invested a lot of money in this game (and some very, very generous money from others) and I’m consistently on the verge of going broke every couple of weeks because of it. So, I’ve done a few things. One of which is that I’ve started a donations page on Joy Machine’s site. In addition to that, I’ve started a Patreon page where, in addition to just supporting/getting the game, I plan to work on Unreal Engine 4 tutorials that, basically, take the information I’ve had to learn about that engine and document the results.
It’s all fun. And scary.
Anyway, it’s also worth noting that a majority of my new content/blog posts are at Joy Machine’s blog page now. Mostly because I really dig Squarespace’s content editor. But also because I’m most interested in increasing awareness of Joy Machine as a company.
So, like, hi/bye.
Joy Machine is our collaborative development name for the titles that we’ll be releasing (as side-projects, mostly) in the future. That means All Things Die will be the first game shipped under that label. I am unlikely to update this site with any frequency, so check joy-machine.com for ongoing developmenet things.
By now, I’m basically so far down the rabbit hole in tech for my next game, All Things Die, that… I’m not going to lie, I didn’t have a fully-prepared metaphor (you’d think I’d plan ahead for the first sentence).
Anyway, as I was about to be saying.
About a month ago, I figured I’d create a Twitter account that would detail my progress on the game. So, you know, I did that. I’m currently at Revision 468, so approximately 468 revisions worth of things have been done. I’ve also [been forced to due to no Git/Mercurial repo seems to allow for variable repository sizes] set up a couple ancillary repositories that also post to that account. I’ll go into what secrets those hold in a moment. Point is: this Twitter account of my endeavors is a thing that exists, whether any of us like it or not. I like to think it holds me accountable to making continual progress… But, in reality, it just has four followers, one of whom is me, one of whom is a bot, and two of whom are friends of mine. So, I can’t say that it’s the most successful forms of peer pressure I’ve ever concocted. Though, I also have Bitbucket hooked into Joy Machine’s slack channel, which is a handy summary of changes to refer to when Source Tree is just too far away. Which happens often.
I had previously been imagining All Things Die as a relatively flat game, as I literally had the game taking place on a flat plane that represented “land” and then some simple low-poly props to serve as mountains, trees, bushes, and basically any other kind of set decoration. I was a huge fan of the low-poly look, but I felt like, as a god game, I was missing a crucial element of the fantasy: massive, level-alteration formation/deformation. So, I did what I’m sometimes prone to do: go massively overboard.
Enter Voxelfarm. I was first made aware of this middleware (middle-aware?) when it was part of the pitch for the Crowfall kickstarter. It looked neat but, at the time, it had no real pricing options for a game of my meager funding abilities (more on that later) but, when I was revisiting technology for the game world of All Things Die, Voxelfarm was fresh out of the gate with an Indie pricing plan and a Unity plugin, albeit a Windows-only plugin. Though, at the time, I was a Mac-only kind of person on account of having only a MacBook Pro. But, like no smart adult has ever said, spending money can be completely cathartic. Long story short, it’s been a rough couple of months and I ended up with a shiny, new Razer Blade.
Suddenly, Windows development was on the table. I’ve been a huge proponent of cross-platform gaming and game development but, hell, now I could have fancy new tech, take advantage of DirectX 11 features, and also… Finally justify the Unity Popcorn FX plugin. Also a DirectX 11 time of day, atmospheric scattering, and volume cloud rendering solution.
Long story short, I’ve put a non-insignificant amount of money into All Things Die. It’s by far the most big-budget hobby game of mine, though previously SUPERCHROMA was my biggest budget on a game, so maybe this is not the best of paths to be on.
I’m now broke is what I’m saying.
First, let’s talk about Popcorn FX. I’ve always been an overly big proponent of big, flashy, gaudy particle effects. For a while, Unity’s Shuriken was a pretty great and fun-to-use particle engine. Then it became… Insufficient. Then I had fun with the Particle Playground for a bit, but its performance is, at best, sub-par. The feature set is solid, but the performance makes it pretty much unviable. Popcorn FX, though, has a highly-touted Unity runtime that supposedly performs almost as well, if not better than, the Shuriken equivalent particle system, and PFX supports per-particle scripting (along with a whole host of other features). The main barrier, for me, was always that the Popcorn FX is Windows-only. But, with that new, fancy Razer Blade. Well. The world was full of possibilities.
Authoring effects in Popcorn FX is just joyous. It’s so much fun. The feedback you get with every change is instantaneous, the editor is feature-rich, and the control and the randomness that you’re given access to is unparalleled in the effects editors that I’ve used in the past. If it sounds like I’m gushing: I am. It’s just a wonderful tool (and the customer support is pretty superb as well). I could do with the Unity runtime supporting lighting or a more flexible integration than it currently has, but at some point I’m just being needy. The learning curve for using the tool is pretty generous, though it does take a while to actually start getting good results from it. It’s easy to wander around pretty aimlessly with creations to the point where one effect in All Things Die took 19 variations before I found one I was okay sticking with. And I can say with just about 100% certainty that there are more variations on that particular effect (the obelisk effect) to come.
As easy as Popcorn FX is to get into and get integrated and start having fun with is just about how hard, contrived, and unenjoyable it is to get Voxelfarm set up. That’s not to say that the results aren’t worthwhile; they totally are. It’s just not fun to get there. Once you establish your foothold with the technology, which entails basically just getting a solid terrain set to render within your engine of choice (ie, Unity for me), it’s much easier to start wrapping your head around what Voxel Studio (Voxelfarm’s proprietary authoring tool) is capable of doing.
Getting there, however, is fraught with several layers of difficulty. First, you need to figure out a pipeline for generating the base height map for your terrain (stored as a 16-bit grayscale RAW file). Then every texture needs, at least, a single diffuse BMP (ideally a diffuse, normal, and displacement BMP), and must be the same resolution. Beyond that, you also need to have 8-bit bitmap masks for every layer of the biome (which indicates how textures are distributed along the terrain). And displacement maps for… additional displacement? I haven’t fully figured out how it all pieces together quite yet, I eventually just found a good sample project (three are provided, one of which is all terrain-based and not a mixture of buildings and terrain) and working off of that from there. There’s also a prefab and instance system which are integral to getting a good looking dataset to render, though which is which and how you author them are somewhat contrary to what you might initially think.
Once you get that foothold established in Voxelfarm’s structure and get a good dataset for your needs, you then need to get the SDK integrated into your renderer, which is also a task. It took me a solid two days to realize why my dataset wasn’t rendering anywhere even close to properly (I run in linear color space, the integration and associated demo project used gamma color space) and then another day or two before I figured out a fix (Unity’s texture sampler creation takes an optional, undocumented final parameter for “isLinear”). Voxelfarm’s support personnel were more than happy to help, but ultimately I had to figure out the solution for the problems I was experiencing, that’s just part of what you get into with what is ultimately a young toolset solving complicated problems. And, boy, is it dire need of some built-in content generation solutions (noise library, rudimentary height map generation, anything).
I haven’t even gotten to the dynamic formation/deformation of land yet (that’s this weekend’s task), but I am finally in a place where that is a realistic possibility, rather than it being a pipe dream in a distant dimension.
I’m even getting to the point where it’s almost viable to start adding programmatic constructs to levels in order to give them notable monuments/set pieces. Last night’s attempts at this yielded a cantor dust city and fractal tree:
So, while the initial experience offered by Voxelfarm is awful and it’s somewhat pricey ($250 + $20/month + 5% of gross after $100k), now that I have my foothold, it’s proving to be a very promising module.
The addition of Truesky is the most recent one and I’m still getting used to it, but it does render some pretty atmospheric visuals.
Anyway. I’ll get to making the game again at some point in the future.
All Things Die, my forthcoming AI-driven RTS god game, has received a number of compliments of its style. So, I thought I’d break down an image effect-by-effect.
The Bare-Bones Scene
So, you know, that’s what we’re starting with. All of the style at this point comes solely from the models done by a fellow named beffio. And they’re great. Anyway, let’s add some Screen Space Ambient Occlusion to add some shading and depth to the scene.
It’s a little hard to tell what this does for the scene, but what’s going on is that we’re providing some shading to pixels on the screen that are exposed to ambient light. It’s most obvious if you look at any part of the scene where two pieces of geometry intersect.
It’s always amazing to me what a good sky can provide to a scene. In this case, my sky contains actual 3D volumetric clouds, not just some well-placed particle effects. The framerate also suffers for it. Now, my beloved bloom:
As anyone who has worked with me in the past knows: I love my bloom. I really, really love my bloom. It just makes a scene pop so much more for me. In this, I’m using a bloom technique that also overlays tiny specks of dirt in high-light emission areas of the screen. I have no good reason for it. Maybe the cameraperson dropped it or something. Whatever.
Color grading is the process of tuning the shadows, midtones, and highlights (basically, dark color values, moderate values, and high values). I actually, in the process of doing this, realized that I need to do a pretty significant color grading pass on this scene as it’s not quite having the atmosphere that I’m going for. Oh, yeah, color grading:
Now, especially, the sky and the trees really pop in the environment. Now, let’s add the atmospheric scattering associated with the lighting from the sun in the distance:
Now everything in the distance has its proper atmospheric scattering going for it; basically, you can think of atmospheric scattering as colored fog — like when the sun first rises in the morning and you see a layer of fog over a lake. Maybe you’re not a lake person, just go with it.
And finally, since I’m rendering all of this to High-Dynamic Range (HDR) buffers, I need to ensure that that the whites/blacks don’t get washed out in the final composition. So, I add a tone mapper with a custom graph and we end up with the final composition:
And there you have it, that’s me avoiding making any actual progress on the game whatsoever for an hour.