Gamasutra: The Art & Business of Making Gamesspacer
arrowPress Releases






If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

The Tools and Tech of All Things Die

by Trent Polack on 05/14/15 02:14:00 pm   Expert Blogs   Featured Blogs

6 comments Share on Twitter    RSS

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

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.

Anyway. Again.

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.

kerackvoxel_victorycrash_attempt

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.

voxel_city

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).

voxelfarm_sample_projectvoxelfarm_progressvoxelfarm_terrainproject3_shot

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.

sandbox_pretty

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:

beautiful_treeprocedural_city

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.

sky_hazy

Anyway. I'll get to making the game again at some point in the future.


Related Jobs

Cignition
Cignition — Palo Alto, California, United States
[12.14.18]

Game Programmer
Wombat Studio
Wombat Studio — Santa Clara, California, United States
[12.14.18]

Mobile Engineer
Wombat Studio
Wombat Studio — SANTA CLARA, California, United States
[12.13.18]

Graphics Engineer (Tech Art focused)
Nerve Software
Nerve Software — Dallas, Texas, United States
[12.13.18]

Senior Software Engineer





Loading Comments

loader image