Steel Hunters Update
What I Missed in Past Days Shall be Made Up for with… WORDS
Hi! I exist still. And it’s been a fair while since I’ve written a proper status update on Steel Hunters. I’ve had some people ask me if progress on the game has stalled or it’s in limbo or some such. It is quite active. That said: this whole project is really just a solo endeavor for the most part right now. As I mentioned in a post earlier this year: I have zero moneydollars to bootstrap this endeavor. That said, work on the project itself is on me, but the Joy Machine core team continues to pitch-in as they can on the other tasks necessary to complete in tandem with the project. And my Melissa (CCO), Jason (CFO), Fredrik (Art Director), and Mona (lawyer) who keeps showing up in the nick of time before I do something stupid like —
HOW DOES SHE DO THAT
Anyway, I’ve worked professionally in a lot of different roles before: engine/gameplay/graphics programmer, designer, writer, creative director, executive producer, technical artist, and vfx artist — I… think that’s all of them. And that has turned out to be super useful because right now I’m doing all of that at once (and more!).
It was ridiculous, unfair amounts of fun. Then it became hard. Well, harder. But even if no one can be full-time (including myself; I do contract work alongside this), having that support around is so, so, so crucial. And it’s especially crucial when you decide to tackle some of the most unrewarding-but-necessary tasks ahead of time. More on that to come. And if you get sick of words, the latter half of this post has all the pictures.
Fun Fact! Sadness!
A few days after that post was published, all of the logic that was powering the prototype that I showed at GDC (the third major prototype iteration; each was actually fairly solid, but I wanted to hone in on some things)… No longer existed.
I was upgrading the Unreal Engine 4 codebase to a new version release that had a lot of lovely features (I can’t remember which one exactly) and it went swimmingly. It took about a couple days since I had a completely isolated engine code repository from the repository that Epic maintains (this has since changed), but everything was building and happy and all was joyous. I loaded up the editor and… It crashed.
I figured it was something I missed in the update. It didn’t seem to be. So, launched again in the debugger; the crash was actually occurring due to a windmill actor I had in the background.
I went through, deleted the assets that would allow those actors to ever exist and the editor loaded properly. Yay! Then I opened up my primary mech blueprint to — oh, crash. Huh. Maybe an odd one-off so I can — oh, nope, crash again.
Anyway, this went on for a bit, but the end result is that the way I had been using some engine/blueprint functionality didn’t really jive very well with how that functionality was intended to work. I had, basically, used a UE4 component (Child Component Actor) as a sort of Unity-esque “prefab”, as that workflow was just so familiar to me. And it allowed me to create, essentially, a primary container for a bunch of other classes all derived from an interface blueprint (for each mech part).
Something changed in the engine version upgrade that made this setup, for some reason, no longer viable. I tried hacking and hacking away at functionality to at least get the blueprints open to recreate them anew, but the core of how the setup was working just wouldn’t have any of it.
I had a friend with an older version of the game on his computer (as I wasn’t going to go off to GDC without a few solid backups on top of the existing repositories; I’m paranoid like that) load it up, screen shot as much of the blueprint logic as possible, and I decided I’d just implement everything in C++. This had to be done eventually anyway, I was just hoping it would hold off a bit.
It took some time to get accustomed to working in C++ with UE4, but it wasn’t too bad, just had a bit of a learning curve. And my C++ was a little rusty. But after a couple weeks (why it took this long is forthcoming) I had the primary mech with some rudimentary part implementations all up and running again. The structure of the whole thing was actually very similar to what I had in blueprint, but the C++ implementation was able to more finely handle when and where child components were setup/initialized/destroyed/etc.
And hats off to some folks at Epic who gave me some helpful guideposts to handle all this properly; they’re just the loveliest folks (this is not sarcasm at all, this is how I talk, I’m sorry). For as, ahem, epic a company as Epic Games is, they are just so helpful always. It’s wonderful.
Blueprints.
Blueprints are actually incredibly powerful, but I will say this: do not treat them as a stand-in for complex logic/architecture.
Blueprints allowed the three prototype iterations I did to move pretty quickly, especially compared to the amount of time it took to handle things in C++, but always remember this important mantra: Don’t Be Trent.
If you think you’re being clever you either are being clever or you’re only clever so long as the way you’re being clever isn’t an unexpected usage of a system that will be changed. And if it’s changed in any significant way and the blueprint editor isn’t prepared to handle how that change affects the blueprint’s setup/flow, you could end up Being Like Trent: sad.
Going Forward
Which means that all aspects of getting the game up and running to be a solid demo (at which point we’ll work on our “announce” trailer) are kind of… On me. And a couple months ago I decided that I was going to use this time to get a lot of not fun at all backend functionality into the game to ensure that, come time for production, all the necessary foundation was in place to just get going on the game as a whole. This entailed a number of expected features.
The Data Editor
I’ve gotten accustomed to using JSON for a lot of game data config and storage and all sorts of other things. This largely came from working in the mobile space, but I think it’d be incredible handy to have a “hot fix” system to distribute game tuning updates, add new items based on preexisting in-game content, as well as set the stage for live-ops and events and such post-launch. Game loads, some updated text files are delivered, and YAY you’re now wearing a santa hat because it’s Christmas and you didn’t get coal this year.
Oh, yeah, Data Editor. I needed an intuitive way to edit all this data in a way that isn’t as error-prone as just tossing JSON into a text editor. The initial approach I took to this was to work on an in-editor window plugin for modifying text data without having to use an external editor. This is not advisable if it’s not super-necessary; making an editor is a non-trivial task. And since all the data I’m working with are non-UE4 managed JSON files, I was having to deal with UE4 serializing/deserializing input fields in the editor and data that, on occasion, would never actually make it out to the JSON file.
I ended up having our in-the-future-lead-developer work on an electron app for modifying various JSON schema (based on the kind of data being modified), and then developers (me in this case) can just click a button to refresh the in-game data from the updated file. It’s not incredibly elegant, but it took about 5–10% of the time to get done.
The World Simulation and Environment
The environments in the game (five of which are planned for launch) are spec’d to be 4km x 4km in size. I wanted to create a proper terrain dataset that could plausibly be future-robot-and-natural-disaster-terrorized Nevada. On top of that, I wanted to lay the groundwork for the world simulation logic that handles all the events, responses, weather, time of day, wind, and so on.
The World Simulation work I’ve done is, I mean, okay I’ll just say it: really awesome. It would also take a couple of dedicated articles alone to really do proper justice. For now, a piece I wrote for Venture Beat on systems-based game design can come… kind of close to that?
As for the environment: Fredrik and I put together are huge reference/information/resource page (below) to get a good idea of what kind of structure/style/visuals to constrain ourselves to and where good spots to really embellish on for our first environment (the launch target is five environments). And, remember, 16 square kilometers of land here. To give a reference for how large these maps are (and I’m working on filling out “sectors” with unique themes to give each part of the overall map a memorable enough feel to ensure player-familiarity with the area subconsciously over time and being… Well. Generally visually interesting, thematically reinforcing, and also lots of splodey bits.
Once we did this, I went into World Machine/GeoGlyph and started on a terrain dataset that had some prominent mesa formations to serve as a major line-of-site blockers as well as identifiable monuments while creating good spots for five-six discrete areas and a nice area in the middle-ish of the map for some solid showdown shootybangs.
For the first time in my history of working on terrain datasets (and I wrote a book on this stuff back in 2002), I actually got a perfect output by the time I imported the dataset into the game:
The landscape material is currently undergoing a revamp to make it more visually interesting and detailed as well. Maybe. If I ever decide to stop writing this article.
For a Size Reference
A lot of the screen shots I’ve been taking up until now have been largely centered on the area around the hangar, the motel, the gas station, and the nearby oil tankers and oil… harvesting… thingies. Well, that entire area occupies that spot just below the center of this screen:
What I’m saying here is that sixteen square kilometers is large. And here’s a little preview at the still-very-much-ongoing layout work:
Making BROBOT the Best Mech a Placeholder Asset Set Can Be
The initial C++ iteration on the core mech functionality was very much a rough first-pass. It got the job done, but it didn’t get all of the jobs that it needed to do done and it wasn’t as flexible nor as extensible as I felt it needed to be. And that’s not even to mention the fact that it wasn’t moving through the world properly. It would have simple collisions with world objects, but not the complex ones required to not look silly, it didn’t have any physical presence whatsoever (so you couldn’t, say, sprint at a trailer and knock it over on impact), and it wasn’t fully using the hybrid procedural/animated locomotion system properly.
This was, by the far, the most unexpectedly difficult and time-consuming task to get right (and it still has some issues moving across two separate types of geometry). I wrote about 20k lines of code trying to alter the existing UE4 character movement component functionality (what it uses for all of its demo human characters), but that just wasn’t even close to the right solution. It discretely was tracking moving, crouching, flying, swimming, and falling — almost none of which are necessary for our physics model. Falling, for instance, is just an inherent property of not actively colliding with grounding terrain/geometry (as gravity is constantly acting on game entities). Mechs don’t swim just like Machete don’t text. A crouching mech would be silly. And flying is handled via booster backpack parts (the backpack slot fulfills a variety of possible roles), which isn’t like Superman-style flying.
After a couple of weeks of trying to finagle something into existing UE4 functionality, I gave up, copied the most basic of the engine movement components over as a base for the game project, and have been building off that. And this may just be A Trent Thing, but I’ve ended up using that approach on a variety of different game functionality (game mode, game instance, player spawns, cameras, and camera booms for example) to ensure that the changes that are needed for the game don’t get altered in a future engine update. It’s much easier to cherry-pick changes from updates than it is to debug broken functionality.
A Pain in the Asset
After trying various materials out on the mech, I started realizing something: the five material channels setup (primary, secondary, accent, chrome, and “misc” — rubber, aluminum, whatever makes sense) on the mech weren’t exactly setup in any interesting way. So, I learned how to work with materials and UV mapping (automatic options in Maya; nothing crazy) in Maya. We actually aren’t doing any UV unwrapped mech mesh components because, ultimately, each mech part won’t be a single mesh: it’ll be a procedurally-assembled part from a two-five smaller meshes that gives items a unique look but, more importantly, that look also dictates how weapons function.
Regardless, the goal here is to make each mech as visually customizable as possible, and the first step in that was to get proper material assignments, so I clicked a lot (a lot of polygon faces) to assign out consistent material application as well as some decent UVs that can be manipulated in-game for texturing. Here are the the pistol arm backpack and the chassis (coloring is different due to switching from Maya LT to Maya 2018 as animation work necessitated it):
For reference, this is what the old mech assets’ material breakup yielded:
And I didn’t have the mech properly loading its parts from JSON at the time, so I did some real-time visualizations in Marmoset Toolbag and well, I think it was worth the painful monotony:
This whole image collection is up on Cartrdge as part of our Cartrdge project mini-galleries.
There is also going to be a fairly powerful system for applying decals to mechs that will allow for a surprising degree of power over the final look of your load out too, though that system is down the line.
A Material Mech in a Material World
Doing the material break-up was just the first step, though. What I’m now calling, by convention, “shaders” — which are just in-editor master materials of sufficient complexity to warrant being called a shader — are being developed from my old standard material sets to help us consolidate the materials into a smaller subset of core sources and limit the number of one-off materials (as, while it makes shader compiles quicker, also can create shading inconsistencies if conventions aren’t strictly-followed as well as getting lost in the fold when it comes time to do updates to materials). The first major shader set winner was, of course, BROBOT. And he received a metallic (base) and metallic (clear-coat) shader two-pack.
Metallic (Base): This is a shader for non-raw metals; in our case, largely for painted metals or generally roughed-up metallic surfaces that aren’t as reflective as, say, solid chrome. This is generally referred to as a “base coat” when referring to automobile paint finishes. The gunmetal, red-ish, and white scratched up accented areas of this quick preview represent this metal type:
Metallic (Clear-Coat): This shader is for more raw representations of metals that have unique texturing applied to them (brushed metal, cross-hatch, etc.) accenting the core metal shading. This shader is more expensive, but it also makes for a proper “clear coat” layer (on cars this is sprayed on top of the base coat). It makes for a glossy, transparent texture with visibility that is highly dependent on light refraction. It also takes advantage of UE4’s screen-space reflections to make for fine reflection rendering on the edges/bottoms of the metallic object. With a simple clear-coat applied, you can get a really solid, smooth chrome material (the chrome areas between the two gunmetal material parts):
For a more obvious example of a clear-coat texture layer above a base layer, here’s some gold bling:
Improve Upon Existing Tech and Adding Necessary Tech
This one won’t get its own section, but I wanted to get the necessary remaining tech in the game and working for my own piece of mind, even if some of it doesn’t get used for the demo.
- Lighting Solution: I’ve been reworking parts of the volumetric lighting and atmospherics system to be more visually responsive and interesting (it’s based initially on NVIDIA GameWorks’ Volumetric Lighting tech). As of yesterday, you can see that it’s going super well. Well, it actually is, but it’s just irresponsible to have a physically accurate lighting system without ensuring that it’s still physically accurate when you do some dubious things to it. I also disabled a fair amount of the global illumination I was working with as it wasn’t adding enough to the scene to be worth the fairly extensive frame time cost.
- Destruction: I had this pipe dream of full all-the-things-are-destructible for the game, but as I’ve been playing and experimenting and working on the codebase/content set, I don’t think that’s feasible. What is feasible is destructible objects throughout the world that are still substantial, interact with the world simulation, and can be destroyed using the physical data already infused into the world (I may have hacked the UE4 physics data structures a bit. Well, a bit more than a bit. A lot) to make for delightfully dynamic firefights that don’t ruin the overall visibility/sight-lines in the level that would degrade gameplay/strategy. So, I reached out to NVIDIA again and they tossed something our way that we talked about at GDC (have I mentioned that the NVIDIA folks are also amazing?) and thus: destruction via GameWorks Blast.
- VFX: Some of our visual effects will be handled via UE4’s Cascade particle system (primarily effects that need accurate lighting), but the weapon effects, explosions, environmental, and so on effects will mostly be authored in PopcornFX (which just released its v1.12 version). So, I got that all up and running with an updated integration to support the v1.12 changes. Yay VFX!
- trueSKY: I continue to iterate on the overall look of the Nevada map to find a good middle-ground between what would be a modern-day clear, blue sky and what we imagine the future’s death, sadness, gloominess, etc. to be. In tandem with the aforementioned lighting changes, I’m also working on some tweaks to trueSKY (on top the work they’re doing on it daily) to fully integrate it into the rendering and world simulation.
Maintaining Our Public GitHub Resources
I feel pretty awful about having to devote less time to writing actual informative articles and tutorials, so I try to contribute new information, links, resources, assets from the game, or whatever I can do to increase the usefulness of the Joy Machine — Repo of Things for others. I also am working on “Joy Create” which is a little Electron app that I want to try out as a proof of concept for some simple procedural mesh generation (also having a side project on top of a big main project on top of contract work means it doesn’t get a lot of love). But: I do love at least attempting to maintain something useful.
I actually thought about setting up a Patreon at some point to help justify more time on tutorials/articles again, but that’s just stuff I like to do to help others like the stuff that was always around me to learn from when I was a wee lad. So, I just promise I’ll do better when less plate-juggling is occurring.
Wrapping Up
This was actually going to be twice as long, then I realized it was already crazy long; the second part of this update was going to more into the “unexpected or at-least-not-this-soon work” that had to be done lately. It involves… Content… Reorganization and file naming convention adherence and… No. No more pain. Stay in a happy place. To close on, here are the things I worked on the last day and a half (again on Cartrdge as well). Most importantly: I have all of BROBOT’s animations and rigging working, exporting, and importing once again. This doesn’t sound impressive at all, but there is no bigger blind spot in my game development knowledge than animation and rigging. VIEW THE DISEMBODIED MOVEMENT:
And, finally, one step closer to really nailing the sand storm effect:
Remember to check out the Joy Machine site and sign-up for the newsletter, check the social board, or join a social media feed or what have you if you’d like: https://joy-machine.com/ and we also have a Discord Server for anyone to join as well.
