Interview with PCGamesN

I did an interview with PCGamesN a few weeks ago with Jeremy Peel to talk about Steel Hunters, its guiding design principles, a bit about our approach to the design and development of systems, and references to immersive sims. Which ended up giving the interview the title of “Making it Unreal: immersive sims meet mechs in Steel Hunters. I never really thought about Steel Hunters as an immersive sim other than saying we draw ideas from them, but… It’s actually not an inaccurate way to refer to the game.

The idea is that by letting the player be responsible for their own choices in the chop shop and leaving the engine to handle the consequences, Steel Hunters will be somewhat self-balancing.

“That’s what we’re really hoping for by not just relying on classifications for things,” says Polack. “We’re not gonna say, ‘This is the heavy weapon’. This is a weapon, it has a certain amount of mass – how do you want to fit that into your build?”

Jeremy Peel, “Making it in Unreal: immersive sims meet mechs in Steel Hunters”

Monthly Joyful Update – April 2017


Between wrapping-up GDC and this whole making-a-game thing, it’s been a little bit since we sent out a newsletter. So, gear up for a heap of exciting updates.

Trent, Scott, and Melissa mingle at the MIX GDC Event. Trent loves to mingle.

Conference Wrap-Ups

GDC 2017

Thank you for everyone who showed up to the MIX Event and tried out Steel Hunters. We received a ton of excellent feedback and reactions. People especially loved blowing things up. (And let’s be honest, who doesn’t?)

Our GDC schedule was jam-packed with exciting meetings. These included chatting with various publishers about the future of Steel Hunters and some good meetings with our partners at Simul (trueSKY), PopcornFX, NVIDIA, and Epic.

PAX East

Trent and Jason spent a day in Boston to meet with some more folks about Steel Hunters. Highlights from the trip included Jason, who is originally from Boston, getting the two of them completely lost in a quest for Trent’s Red Bull.

The first-ever screenshot from Steel Hunters development as featured in Trent’s Cartrdge article.

New Articles

No new design articles lately, as we’ve been neck-deep in our production and workflow processes, so Trent has been writing about that kind of stuff. Well, until he tried to employ the scientific method to a color-grading and post-processing stack tuning pass. That went… Well.

Todoist for Project Management

How we use the simplicity, flexibility, and power of Todoist ( to handle our team tasking.

Joy Machine’s Production Tenets

A piece Trent wrote for our lovely friends at Cartrdge.

Steel Hunters – Post-Stack Tuning

Trent will no longer be allowed near any science experiment after his attempt to employ a scientific method to color tuning went… Awry.

A snazzy, new way to watch the rest of the team laugh at Trent.

Ongoing Development Work

Engine and Tech Page

As always, you can check out the Joy Engine page if you want to see what we’re violently hacking into Unreal Engine 4.

  • Full upgrade to Unreal Engine 4.15.
  • Re-worked integrations of various middleware.
    • trueSKY — Put some additional work into how it integrates with UE to help smooth some rough edges and make some performance enhancements.
  • NVIDIA GameWorks integrations
    • Flow — New integration for more types of visual effects.
    • Volumetric Lighting — With 4.15, we made updates to Volumetric Lighting to better-integrate it with our other technology changes.
    • WaveWorks — Resurrected with some assistance from a NVIDIA integration into UE 4.15. Now it’s pretty and shiny and fast again.
    • HBAO+ — Minor version and integration upgrade to our integration of HBAO+ (Horizon-Based Ambient Occlusion) which provides a much nicer AO solution than the UE default.
    • BLAST — Laying the framework for our integration of the BLAST tech. Nothing near finalized yet, but it’s something!
  • Full VoxelFarm 3.0 integration — we’re unsure if we’re going to use this tech for Steel Hunters or not yet, but we’re running some R&D experiments now.
  • PopcornFX — Fully integrated and starting to redo a lot of our stand-in visual effects with.
  • Graphine Software‘s Granite SDK — This is the biggest new tech change that we did over the last few weeks! Full integration which will allow us to have more fine-grained control over texture resolution and streaming throughout all of our environments, mechs, and assets.

Upcoming “Announce” Trailer

The team is hard at work on a slew of gameplay, system, and UI work to ensure that all of the game footage seen in our upcoming teaser trailer is 100% in-game and representative of the current functionality level of our working prototype. A new devlog post going into this work a little more. And keep you eyes peeled for the first Steel Hunters trailer within the next month!

And, earlier today, Trent somehow was able to convince one of his favorite bands to lend a track to be used in the trailer. So, even though no one other than Trent had heard of The Felix Culpa, he was still pretty psyched about it.

Site Updates

We’ve made a whole suite of tweaks to the site to make it more readable, snappier, and generally better. These include:

Looking Forward

Be on the lookout for more exciting changes over the next month as we continue to steam forward on development. You can look forward to the Steel Hunters teaser trailer, new devlog posts and plenty more of Trent’s development insights and gripes.

Joy Machine

NOTE: Trent will just post the newsletter manually until more people sign up for it.

Steel Hunters – Post-Stack Tuning

Generally, I do all of my game work on my primary monitor (Dell 27″ S2716DG) which I’ve run through a couple of color/brightness/etc. calibration tools. I have not done the same for my under-resolution — due to outputting to multiple displays from a laptop — Samsung 32″ (S32D850T). That monitor has not received the same love, since it’s already not running its intended resolution, so I figure it’s a lost cause until I can build a proper desktop computer.

That said, it’s a great test for a more “common” monitor display setup, as outside of the art/design/game development/film industries, there aren’t a whole lot of people with properly-calibrated displays.

Steel Hunters was basically 20% barely-discernible black color output, and that was in a still image, much less during gameplay. Though gameplay would have the benefit of dynamic lights illuminating the area (potentially).

Anyway. I wanted to fix that. So, because I needed a new article on this site (or so I’m told by the team), I decided to make this project my article. And also my way to not just blindly tweak post values because: A) I needed reasoning for this article, B) I have a tendency to just continue the cycle of tuning to my primary monitor.

An attempt to solve both these problems is to just define a bookmarked position in-editor (so if it crashes, I don’t lose this reference point) which has a complex scene composition — a wide variety of exposure values — and balance iteratively and take notes every step of the way. And a screen shot of each annotated iteration from the same bookmarked perspective at 2x editor resolution, which ends up being 3722×2656.

All of this arose entirely out of playing Ghost Recon: Wildlands for a week straight and then binging Metal Gear Solid 5: Phantom Pain upon realizing that I never got anywhere even close to completing it. The most striking difference between the two games, which sounds negligible at first, is how they handle scene lighting at night. In Wildlands, the scene is barely visible at night if you’re not actively in a lit area (through spotlights, car headlights, streetlights, etc.). I assumed initially (and the resulting conclusion doesn’t negate this) that my, somewhat ironically, completely uncalibrated television display near a window lacking proper blackout curtains was the cause of this. But playing in the same conditions over the course of no-it’s-not-important-how-many-hours-were-spent-on-these two days of MGS5, it became clear that this may have actually been a design decision.

Spoilers: benefit of the doubt tossed in  Wildlands‘s general direction may be wrongly-placed. RESULTS IN THE ARTICLE CONCLUSION!

Granted, it also ended up taking about five times as long as it would have otherwise. C’est la vie.

Starting Point: post_work_iter_00

All items to follow have been changed in a later iteration, based on this starting point, so here are their original values for posterity.

  • Color Grading
    • Global
      • Contrast: 1.13
  • Tonemapper
    • Slope: 0.9
  • Auto Exposure
    • Min Brightness: 0.03
    • Max Brightness: 2.0
    • Exposure Bias: -0.1
  • Bloom:
    • Intensity: 2.0
    • Threshold: 1.5
    • Advanced
      • Size scale: 8.0

Iteration: post_work_iter_01

Generally trying to improve dimly-lit/heavily-shadowed area visibility, while also tweaking the results of the bloom a bit as it’s in the stack and doing things, just nothing really of note.

Trying to alter the tonemapping curve (which is to set to “filmic” in UE4, which I believe is ACES) to expose the dimly-lit areas rather than just tweaking the color grading values themselves — as those are applied later in the post stack and degrade overall composition quality.

Changed this Iteration

  • Color Grading
    • Global
      • Contrast: 1.25
  • Tonemapper:
    • Slope: 0.7
  • Bloom:
    • Intensity: 1.0
    • Threshold: -1.0

Iteration: post_work_iter_02

The bloom is way too omnipresent to the point of no longer highlighting/accenting bright areas and, instead, just applying an entirely different camera lens (totally altering the intended composition style).

Also, no values I’m using are really highlighting intentionally-overexposed emissive materials, so using the gas sign as an example of a reasonable value.

Changed this Iteration

  • Bloom:
    • Intensity: 3.0
    • Threshold: 0.5
    • Advanced
      • Size scale: 6.0

NOTE: Also updated the following materials/material instances:

  • mi_building_gas_station_01_light
    • Just to test the intended level of emission from an emissive material in the scene (and what it would take to get it factored into the bloom pass with decent results).

Iteration: post_work_iter_03

Dig the changes to the bloom, restoring the changes from _iter_01 to see how it fits into the original scene.

The resulting image is, overall, a bit lighter in the more heavily-shadowed areas, but nothing that’s really an experience-changing difference.

Changed this Iteration

Restored to Base
  • Color Grading
    • Global
      • Contrast: 1.13
  • Tonemapper:
    • Slope: 0.9

Iteration: post_work_iter_04

The resulting bloom changes and injection of another overexposed item in the composition with the gas sign material change actually ended up with a slightly more balanced final composition than I expected. Though, still not enough to really resolve the issue for most players/viewers. Scratch that, had the wrong initial values written down because I started this article after iteration 1. The lovely Jan on our team sanity-checked for me and this resulted in _iter_03 having a more desirable bloom effect, but no change whatsoever in composition darkness/brightness. Which is… Far more what I would have expected given that the responsible parameters were reverted to their original state.

So, opening the HDR Histogram to visualize the scene exposure values showed this:

The heavily-overexposed GAS sign is very intentional, and the overexposure of the sun and surrounding clouds (for those that are new to TRENT’S WORLD: all things are dynamic always forever, including the results of the trueSKY-based cloud renderer) are not explicitly intentional, but also not surprising nor undesirable overall. Checking our existing min/max brightness values in the Eye Adaptation step of the postprocessor stack against UE4’s defaults just proved-out that they were good changes for us to make.

So, yeah. Huh.

Abrupt Conclusion

While checking out the skylight/sunlight (directional light) values/settings in our “world” actor (generally controls atmospheric/environmental world systems, lighting included) resulted in me needing to use my Event_trueSKY_Calibrate editor function to restore my scene settings. Apparently editing a component within an actor instance musses up something in our lighting pipeline. Anyway, the resulting point of this entire post is: if you have a function to calibrate your entire scene to a specific setting/time-of-day, best check it before starting an article where you dictate your color grading/post-stack tuning steps. Because this is what the calibration yielded:

And, yeah, while the problems that started this whole endeavor are still occurring in the same areas, the scene composition is changed enough that it somewhat negates the meticulous step-by-step process that would’ve led to a solid conclusion.

Oh well. On the plus side: I didn’t have to make it to iteration fifteen like I was worried I would.

Next time maybe I’ll just video capture this whole thing.

Oh, Yeah, the MGS5/Wildlands Thing

Metal Gear Solid 5 provides a somewhat-hybrid Night-Vision/Thermal device (view mode) for the player to use in dimly-lit situations. And at higher upgrade levels, even adapts well in broad daylight (I’m not there yet).

This is somewhat different from Ghost Recon: Wildlands‘ separate Night-Vision and Thermal devices (separate view modes). The NV device in Wildlands is a usable option from the very get-go, but the Thermal device is gated behind a skill progression tree — implying the Thermal device is either more advanced and requires more player knowledge of the game to use properly or is, generally, more useful than night-vision. The resulting gameplay experience is… A little of both? Thermal is largely for discerning enemies (known and unknown) amidst the incredibly complex scene that is typical for the game. So, maybe, the impetus the game is providing for its difficult-to-discern dim lighting scenes is to ensure you’re using your secret agent devices like you’re supposed to.

In MGS5, I end up using my Night-Vision Goggles because I want to and think they’ll be beneficial… But their use isn’t necessary to play the game at any time of day in varying lighting conditions.

Given my experience with the MGS5 compared to much more time over a longer interval with Wildlands, I’m inclined to think that Wildlands didn’t bother enough with the kind of experiment I just [attempted] to run.

Update: Localized Tonemapping

This isn’t going to be the kind of thing that really gets remedied with a late night or anything, but I remember adoring this series on Localized Tonemapping by Bart Wronski (here’s part two).

I think, at the end of the day, balancing this test composition without some kind of substantial change to how tonemapping/eye adaptation is handled at a low-level is going to be a Sisyphean endeavor. I have a few experiments I’m still going to run (though not accompanied with devlog posts as I do them because, well, this happened) to see how best I can skirt by the issue in the short-term, but if the time ever opens up to really gut UE4’s tonemapping and replace it, localized tonemapping seems like a neat starting point. And, regardless, the idea of a more flexible, adaptive tonemapper would seem more appropriate for a game where it’s incredibly hard to predict what kinds of situations players will get into, much less balance compositions well for them using a “best fit” parameter configuration. No, I will not get obsessed with this topic. Not right now. But… soon?

Joy Machine’s Production Tenets

Continuing on the (completely unintentional) trend of writing about our production/development process for Steel Hunters, here’s another piece that I wrote for our friends over at Cartrdge.

And I also, well, not frequently, but when I can write articles on rendering/ engine/gameplay development stuff I’m doing or, lately, about the design approach we’re taking with Steel Hunters which is fairly unique (it’s a grounds-up system-driven design). You can find everything I’ve posted so far on our Joy Machine Devlog.

The thing is: the chances of someone stealing your game idea are slim-to- none. And, if they do, there is no chance in hell that anyone is going to execute on that idea the way that you’re going to. And that’s not even to mention the tech-side of things; I’m confident that our custom fork of UE4 would be incredibly difficult for anyone to guess on the feature set and then develop complete parity with. And, again, even if that happened: no one is going to design the game like I am, and no one is going to focus on the nuances of the design/implementation of the game like our team will.

Read the whole thing here.

Todoist for Project Management

Todoist is our task management tool for Joy Machine and Steel Hunters. There are an abundance of reasons that we’ve decided on this as opposed to traditional tasking solutions like JIRA, Asana, Trello, etc.

  • I hates Kanban (Trello).
  • Todoist is a very light, customizable solution for project management.
    • This allows us a great deal of flexibility in how we setup our particular task assignment/update/completion process.
    • While not initially intuitive, Todoist offers a lot of flexibility with filters and labels that make customized “dashboards” incredibly easy to define (once you know the query strings).
  • Todoist has a very solid interpreter whenever you type out a task:
    • “Implement an MMO by Tuesday at 3:30pm.” — This will translate to a task for “Implement an MMO” with a deadline of the following Tuesday at 3:30pm.
    • “Meet with Trent every Wednesday at 11:30pm” — This translates to a recurring task every Wednesday at 11:30 for “Meet with Trent”.
    • “Game doesn’t work. @bug p1 #steelhunters +trent” — This translates to a task “Game doesn’t work.”, filed with a label of “bug” (any number of labels can be specified), put into the project “steelhunters” (limit is one project), and assigns the task to Trent (limit is one assignee).
      • If you want to notify multiple people on any changes to the task or any comments, just create a comment after creating the task and tag people in the notification panel as-desired.
    • If you’re not a fan of the string-based shortcuts, the GUI has components to accomplish all of the same functionality.
  • Sharing projects with differing groups of people is absolutely trivial.
  • Todoist is almost too good at emailing/pushing notifications based on any changes made.
  • If there’s a website in existence, it almost assuredly has a Todoist integration.
  • The Todoist web-app is incredibly solid, but they also have a native application for every platform.
  • Finally, Todoist has a really well-done REST API for querying details on tasks/projects/etc., which we can integrate into our website for communicating progress to our community.
  • I really, really, really hates Kanban.

Comment Threads

While we all use and read Slack and coordinate efforts and tasks and such using that, Slack is not a useful tool for status updates, questions, issues, schedule updates (including if you think you’ll miss the assigned date — which isn’t usually a problem, but it’s helpful for us to know), and, most importantly, when you are blocked on something.

Whenever you comment, you can always choose to notify anyone you wish on the project just to ensure people are aware of your updates. At the minimum, ensure you mark <your relevant people/producer> regardless of what the task is about, as we are running the production/schedule for the project. You should also opt-in anyone that’s related to the task as well.

Finally : Even I forget this from time-to-time (always), but Todoist has complete support for file/image attachments in comment threads. So feel free to use and abuse that.


There’s a “Karma” functionality built-in to Todoist which, essentially, is just a bit of gamification/statistics to try and encourage consistent task completion/monitoring. It’s stupid and simple, but also it can appeal to people. Like me, who loves stats more than I do most people. Look!


Labels are, well, labels (or tags, more appropriately). They are just ways of classifying the miscellaneous areas of the project a given task is related to. It’s helpful for creating search filters as well. For the most part, you can just choose a task’s label based on the available ones we’ve setup, but there is one very important label you must all use:

The “Blocked” Label

Of all the varying labels, the “Blocked” label ( @blocked ) is an important way that <your producers/project managers> can all quickly identify tasks that have been blocked (always leave a comment in the task when you mark a task as blocked — including tagging the relevant people for notification.

The Rest of the Labels

  • bug
  • team
  • business
  • content
  • engine
  • gameplay
  • backend
  • networking
  • design
  • ui/ux
  • docs
  • tools
  • meeting
  • marketing
  • site
  • future-work — This label is exempt from most search queries related to due dates or lack of assigned team member.
  • And then there are always labels for relevant upcoming milestones.


Filters are the absolute best thing ever. It sounds like an incredibly simple thing, but Todoist has a unique search system that allows you to setup and customize your filters for whatever things you need to track. Whether it’s “Assigned to Me”, “Overdue Tasks”, etc.

The most important part of filters is that you can set your opening screen/page in Todoist to whatever filter is most useful for you. You can find this in “Todoist Settings” as “Start Page.”

Unfortunately, as of the time of writing, we cannot simply share filters or create team-wide filters, so you’ll need to create your own manually. LUCKILY WE HAVE A LIST BELOW!

Helpful Filters and Their Query String

My Tasks

assigned to: me

View All

view all

My Tasks — Today

assigned to: me & today

My Tasks — Blocked

assigned to: me & @blocked

My Tasks — Overdue

assigned to: me & over due

My Tasks — No Due Date

assigned to: me & no date & !(@future-work)

Team’s Tasks — Blocked

shared & @blocked

Team’s Tasks — Today

shared & today

Team’s Tasks — Overdue

shared & over due

Team’s Tasks — Unassigned

shared & !assigned

Future Improvements

I don’t think Todoist is by any means perfect and it’s definitely not as feature-rich as a lot of other task management solutions, but at the same time — how many people actually know how to use JIRA to its full capabilities? The most important thing for me as far as Todoist as our chosen software for project management is concerned is that, since I first started using it a year ago, it has improved in incredibly smart and clean ways. It’s just an easy-to-use and well-designed application.

The biggest things that Todoist is lacking from our perspective right now is visualizations of timelines and overall schedules for a project (which, to be fair, I don’t think it’s actually meant for that). But that’s something that a couple of the Joy Machine folks are working on resolving as we speak. And such visualizations may get integrated into this internet website. WHO’S TO SAY?