The founder of Joy Machine Trent Polack talked about some of the tools, tricks, and tweaks, which helped him to build games in a more efficient manner.
The founder of Joy Machine Trent Polack talked about some of the tools, tricks, and tweaks, which helped him to build games in a more efficient manner.
Introduction
Hey! I’m Trent. I’m the Founder of Joy Machine. I’ve been making games professionally since I graduated with an English degree from the University of Michigan back in 2007, starting with PC games, then PS3/PS4 titles, then mobile for a while, then a PC MMO, and lately I’ve been working in the edu-tech industry. But I just rejoined the games industry, am currently doing miscellaneous contract dev/design while I get the company I’m re-establishing in Michigan off the ground. But, mostly, I’ve been doing R&D and pre-production work on my new game.
Our last title, Sacrilege, ran into… some unrecoverable external issues. But that’s okay! We’re coming back with an unmatched level of passion and intensity (seriously, I’ll challenge anyone on that) for our current project: Steel Harvest. This is, essentially, the game I’ve always wanted to make, always wanted to play, and I feel like the last near-decade of professional development (as a developer, designer, creative director, technical artist, VFX artist, and exec. producer) has all culminated in me finally having the foundation I need for the work that needs to be done to make this game a reality.
Basically: we’re (I keep saying we because theoretically I will have money to hire some full-time game peoples, but right now it’s just me) making, essentially: third-person shooter mech Diablo with the structure of Monster Hunter. That’s Steel Hunters. I’ll probably talk about it more in a few seconds. Maybe.
Choosing Unreal Engine 4
I’ve used Unity since… God, well, Unity 2. It was… Different then. But, yeah, been using it a long time, and when UE4 went open-source I was all over it. I’ve really enjoyed being able to sink my brain into real-time rendering research and graphics enhancements I can make to my monstrosity of a UE4 fork. I get to work with some folks from NVIDIA from time to time on stuff too, which is always fun, because the first time I talked to NVIDIA was when I was drunk for a phone interview as a driver programmer intern about 13 years ago. I didn’t get the job.
Anyway!
I just really enjoy the power that UE4 exposes to game creators. I generally only have to sink into C++ code for rendering code, whereas — given the mostly-negligible performance impact — I rely on blueprints for game logic and systems. I mean, within reason. Start talking about really, really involved game systems that require some intense engineering, but for the most part I really haven’t run into something that I can’t handle through editor-only work in UE4. And that’s just a really, really nice break from writing code and it allows me to think through systems in entirely (and more effective) different ways.
I was making the point last night on the UE4 Discord server about blueprints and visual scripting: I firmly believe that anyone who doesn’t consider visual scripting as “programming” has really not dedicated much time to working with it. Visual scripting generally requires me to completely visualize and internalize every instruction that I string together to put together systems to a degree of understanding that really sticks with me for a long time. And that is almost subconscious to me when I write code (for better and worse). Obviously both are tools in the ever-growing toolkit of a game developer, but I enjoy the break from traditional programming so much that Blueprint is a godsend. Even if I end up rewriting the same logic in C++ later. Which I hope not to have to do.
But, yeah, to try and stay on topic for a paragraph: so far the entirety of Steel Harvest’s gameplay code is all handled through blueprints, interfaces, structures, child actors, and curves. And, honestly, so far that’s been absolutely perfect for all of my needs (and these are non-trivial needs — then again, some of my blueprints are terrifying). Though last night I was working on some logic for mass-affected leg movement for a biped mech and I’m fairly certain that if I got interrupted at any point I’d never have figured out my train of thought again:
sh_blueprint_walk_cycle_v1
Movement Blueprint v1
I never thought left foot, right foot, left foot, right foot would be so involved. Turns out walking is weird. I also wish this was the worst of my blueprints, but alas. And I try to be diligent about keeping functionality modular and reusable and clean.
But what really, really drew me to UE4 originally was just the concept of the material editor. One of my loves for a long time was just doing technical art and making pretty scenes — as there have been jobs where I couldn’t have full side-projects — and the material editor was like a dream come true for me. And about two months or so of the R&D I did for Steel Harvest was solely working on materials to fully realize the visual style I wanted for the game.
One of the most useful things I’ve changed about my UE4 workflow is that I try to avoid creating new master material graphs at all costs: after a week or two of reading PBR and general lighting/shading research papers, I started establishing a standard set of master materials that I derive 80-85% of my game’s material instances from — it helps me ensure consistency in shading throughout the scene, which helps me balance the overall scene intensity so the tonemapping/eye adaptation aren’t completely unpredictable as the time of day changes (I refuse to use baked lighting; dynamic lighting and GI all the way, framerate be damned). I’m hoping to release this material pack on the marketplace in the near future, as they’ve been incredibly helpful for me. Or maybe I’ll just toss it up on my site for free because who needs money (I do, I really do).
Speeding Up
One of the things that was instilled upon me at my first professional gig (at Stardock Entertainment) was how to develop and design in the most cost-efficient manner as possible. Granted, it’s taken me years upon years to really figure out good ways to figure out what that actually means, but I think I have a really good grasp of it for Steel Harvest. And I like to talk, so you can bet I’ll be posting a bunch of development blog entries on various systems that we employ for development of the game (once I get a bit more free time).
The biggest challenge for Steel Harvest, for instance, is figuring out how to possibly achieve the level of 3D content necessary to really build out the intended launch environment set and, the bigger issue, fill out the depths of possibilities to make the mech customization as visually and functionally varied as I want it to be. All of the ridiculously talented artists I see on this site all the time are hard to come by, you see.
For instance, there are seven major visual customization slots and four minor visual customizations — in addition to attachments per-item for visual variation — for each player’s mech. So, right now, my focus is on developing systems to take individual part meshes as far as I possibly can. Because, if I don’t, I’m looking at a pretty significant budget expansion for the amount of additional art requirements I’ll have for the full production. But, I’m currently pretty far into an experiment that allows me to completely avoid any texture creation whatsoever for any part meshes in the game. Completely. This means that I need to have fairly high detail meshes to work from, but I think that really is necessary for selling the mech styles we’re going for anyway. The best analog I have for the plans for the customization system is that in the Turn 10 Studio’s Forza games: customization is based on varying materials (which I’ll author to be as high-quality as I can), tinting them as-desired, and then applying decals to the mechs for additional personality. I’ll go into this system a bit more in the future when I have it a bit more nailed-down, but so far all of the experiments I’ve been running have been pretty successful. For instance, yesterday I made the chassis of a mech a blinged-out gold in honor of the Army of Two games:
sh_material_application_experiment_01
I’m hoping it all pans out. And by hoping, I mean I’m desperately counting on my brain to not let me down right now. But procedural generation of hard-surface assets (largely relying on procedural animation systems) can’t be as bad as the organic proc-gen in No Man’s Sky, right? Right?
Tweaks and Changes
I’m going to admit that this is one thing that I’m still constantly struggling to improve upon. Right now, I rely very heavily on child actors of blueprints as templates for items and mechs, then I then layer modifier after modifier upon in order to apply the randomized item properties that you’d expect out of a loot-oriented game. And I store all of those in theoretical .json files both locally and on an imaginary remote server for preventing the kind of cheating I know nothing about solving for (hint: I’m hoping to start hiring for Joy Machine soon, wink wink, nudge nudge). In case you haven’t sussed out the secret meaning behind my subtle reference: I have on idea how I’m doing that yet.
One thing I know for sure, though, is that I’m never designing an entire loot system in a spreadsheet ever again. I’ve made that mistake in the past (and I’m sure other system designers can make it work), and I won’t do it again. It’s nice to have an initial set of data to work off of, and neat charts and graphs to look at and show the rest of the team to help them understand the overall game balance… But, for me, I found it an entirely ineffective method of balancing a loot-based game in the long-term.
What I have found useful thus far is actually an incredibly simple little addition that I added to one of my blueprints: it’s an Unreal Engine 4 blutility button that I press whenever I want a randomly-generated item to analyze and inspect for anomalies. That kind of stuff is unbelievably handy. It’s simple, it’s quick, it lets me easily test for bugs and things that I’ve broken. Those are the kind of things I look to develop throughout a game’s pre-production that just prove to be invaluable in the long run.
As far as the technical limitations of the engine, I honestly don’t run into them all that often. Either that, or I run into them and just look for a workaround immediately. The biggest issues that I tend to really beat my head against the wall for are rendering ones where I have to wrestle with an engine that’s incredibly well-developed and structured to the point that I can barely wrap my human head around it at times. And those… Those can eat up a lot of time (water rendering on my last project was a big time-suck). And, Epic, if you’re reading, I would really adore working together on an official dynamic global illumination solution so I’m not combining LPVs and heightfield GI to somewhat-inconsistent (and expensive) results. Pretty please.
Combining UE4 with Different Tools
Oh boy. Well, a few months ago, my answer to this would have been very, very elaborate. For the longest time, I had tremendous difficulty getting my hands on reliably-detailed textures with all of the necessary additional texture data that I needed to properly shade the environment. And then Quixel. Oh, Quixel. Megascans are, in my opinion, going to go down as one of the most important, influential change to the game industry in a long time. I mean, you’re potentially looking at an all-needs-met library (down the road) of professional photogrammetric textures, the likes of which most indies can’t even dream about getting access to. I was actually going to refer back to the last interview I did with y’all for my go-to programs, but they’ve actually changed completely since then. So:
- Knald – Still the best multi-purpose texture data generator I’ve found.
- GeoGlyph 2 – GeoGlyph 2 just had its RC released yesterday, but it is, essentially, an entire gutting of the stagnant UI and workflow of World Machine 2 (last stable build a year or so ago), while keeping the really solid internals. And adding a ton of great terrain generation functionality along the way.
- Megascans Bridge/Studio – For the aforementioned reasons that Megascans are amazing (and studio just extends their practicality).
- Todoist – So, apparently, starting a company and getting a game funded is hard. Todoist is the most low-overhead way I’ve been able to manage projects/tasks with multiple people that I’ve found — and I’ve searched fairly exhaustively.
- Maya LT – Still a great budget alternative for 3D work (I refuse to acknowledge the archaic UI that has plagued Blender for… ages).
- trueSKY – trueSKY is plagued by a lot of bugs that crop up every now and again and take a bit to get resolved, but it’s still an amazing and well-priced middleware for its efficiency and quality.
- NVIDIA GameWorks – I still wish so many of these features were available as plugins (and I believe that’s the end-goal), but they still provide a lot of valuable graphical enhancements.
Okay, I think I probably bored everyone reading this by now. But, hey, check out the Joy Machine site – I plan to fill it with more and more content as I progress through this journey of studio creation, funding/money-hunting, and game production. And if you feel like chipping in on the Patreon for the game a while to help me along, you’ll very likely have a playable prototype in about a month! I hope! Or I may go insane and go live in the woods and talk to squirrels. More than usual, I mean.