What made you decide to use Unreal Engine for RESEARCH and DESTROY?Willacy: Between the three of us, there are about 30 to 40 odd years of combined experience in various Unreal Engines so I don’t think we ever even discussed it, it was just assumed. We’ve been lending our Unreal Engine expertise to other studios to help fund RESEARCH and DESTROY over the last six years and every project you work on you learn more. So stuff that was done early in production may have been redone once or twice over that development period as we learned new or better ways to do things.
Were there particular elements of the engine that attracted you to using it for your game?
Markiewicz: Its cross-platform capabilities, and we were already using it all the time in our “day job” helping clients with their projects.
Willacy: I found that as long as I could understand the “when” and the “why,” Unreal took a lot of the “how” out of the day-to-day math duties that various disciplines perform, and as a guy who’s not that strong at math, that’s a huge thing for me.
Gajentaan: Unreal Engine has always been a fantastic tool for artists. There are always lots of ways you can add variety to your content using a relatively small pool of simple source assets.
Are there any design challenges that you overcame that you could walk us through?
Willacy: I think most of our design challenges were born out of being a small team creating an ambitious title on a modest budget.
The biggest challenge for me in designing a lot of the weapons and gadgets and gameplay actors was just making it all kind of fit together in a coherent way. There was a lot of emergent gameplay that became part of the design just because a weapon and a gadget revealed some kind of interplay we hadn’t anticipated.
There are nine weapons with two fire modes and eight upgrade combinations per weapon, as well as nine gadgets with two potential upgrades each, and they often influence each other in different ways. Those numbers make my head hurt. Thankfully it wasn’t just me on my own, the other guys have keen design sensibilities and our team was small enough to bounce ideas off each other and contribute without workflows getting bogged down.
A concrete example would be centralizing all of our battle data externally in spreadsheets. Since I was the only member doing level design and wrote the enemy spawning system I had to write something I could use to flesh out battles and iterate on them quickly. Using spreadsheets and Unreal Engine’s data import system meant I could quickly visualize problems with battle over/underloading. I could graph them up, create arrays of UE4 readable links, and have them validated before importing and such. That would have saved weeks or months of work over the course of the project.
UE4 is very good when you take a data-driven approach; you can save a lot of time.
Another example would be that I’m also wearing the audio hat on the team but I didn’t have huge amounts of time to make the background music so I came up with a dynamic music system that changes based on various things like whose turn it is, who you are controlling, gameplay events and such. Firstly, this was done with UE’s Time Synth and later with Quartz, which is basically the thing I have been waiting for since forever. It allowed me to create something that has been swirling around in my head, but couldn’t do for one reason or another for about 15 years, which is hugely gratifying. I’d like to take it even further in future projects, if possible.
Markiewicz: A core element of our game is the idea that when characters run out of time, they freeze. It doesn’t matter if they were running, flying, falling, or in the middle of a ragdoll freakout. They need to stop what they are doing, but be able to resume immediately at a moment’s notice. This ended up being a bigger challenge than I had anticipated, especially once you go into online multiplayer.
For example, if you launch a werewolf into the air with an explosion—and why would you do that, you monster? That werewolf is a single parent with two kids!—they’d end up frozen in mid-air, in a pose determined entirely by ragdoll physics. We can have a lot of characters in play at a time, and a lot of explosions, so that can result in a load of frozen ragdolls.
Synchronizing them over the network wasn’t really in the cards at the time we implemented the system. I tried a few approaches, but it never quite worked out, especially under bad network conditions. The thing is, in most games, ragdolls kick in once characters get killed, and at that point are mostly cosmetic.
In our game, you can still take your time and try to headshot that werewolf who is frozen in mid-explosion (YOU. MONSTER.) I ended up addressing this problem by making all weapon hit detection client authoritative. That is to say: the client decides whether they hit or not and lets the server know, instead of the usual pattern of having the server decide what’s hit and what isn’t. Were this a competitive game, this would open up a huge can of potential cheating worms, but we’re not too concerned here. What’s most important is that if the client player lines up a shot on a frozen/flying enemy’s noggin, they HAVE to hit, even if that head is positioned slightly differently on the host. We don’t care too much if things occasionally look a little weird for the host player because of that, because the shooting player’s experience takes precedence.
Source: Unreal Engine Blog