Creator Spotlight : Edgar Parente – Technical Director

creator spotlight edgar parente technical director

Tell us about your journey as a game developer and you came about to be working with Rogue Factor and as technical director on Hell is Us? 

Like many in this industry, I got involved with computers and video games at a young age. My first experience programming was a type-in game in Compute! Magazine. My interest in video games and computers was always present; I tinkered a lot with old PCs to upgrade memory or soundcards, etc. started making video games on the Nintendo DS in a small company (now defunct) called Wicked Studios. I spent a few years working on web games, then joined Cyanide Montreal as a gameplay programmer.

I have always been part of the core team at Rogue Factor. I held leadership positions on all our projects moving to Technical Direction as the studio grew larger. Interestingly, I still work with a majority of the team I was with at Wicked Studios. We merged back together at Cyanide Montreal before creating Rogue Factor. I’ve been working with the same people for over 20 years now!

I program less, but I still like keeping some systems to myself. When I don’t program for a few weeks, I miss it in my bones and start working on personal projects to scratch that itch.

Hell is Us was released simultaneously on Steam, Epic Games Store, PS5 and Xbox Series. What were the main technical challenges while developing a multiplatform game? 

One thing we did well was establish our performance targets on each platform early on. These targets changed somewhat as the project moved along, but always having that goal ensured we never lost focus.  

The Xbox Series S is quite different than a top of the line PC. We made sure the technology used in our game was scalable, and tailored the experience for that specific console. Each of the consoles require specific optimizations and tweaking to be at their best. This was many hours of playing the game finding choke points and analyzing how we could optimize that area of the game. 

Working with platform services also requires custom code, but they are generally pretty similar. We were able to merge our achievements code, for example, and have it connect to Steam, or PSN, or Epic Games Store. 

screenshot hell is us

All this work gets planned years ahead of the final release. We iterated and tested continuously on all platforms throughout production. It gives us time to have a semi optimized game during its creation, and reduces the QA overload at the end of the project when everyone is too busy to think about platform specific work. 

One of Hell is Us’ core design philosophy is « player-plattering » (no guidance, no quest markers, etc.). Were there technical challenges inherent to that approach to the game design? 

Making an immersive experience is always difficult. One area where we iterated a lot was how obvious interactions (doors, loot, etc) should be when you are running around in the world. We initially had a system which would not show interactable areas unless you stopped moving. In the end we opted to have a subdued sheen which was always present because we didn’t want someone to miss important elements. 

We always said we didn’t want the player to have a radar pointing him to all the things he could do, but having a compass to help guide the player was important. We localized the game in multiple languages, and had to make custom compass textures for all languages. 

In the concept of player-plattering, localization is key, as all the key elements need to be consistent and make sense in all languages. Localization can be difficult as the translators do not have all the same context as the developers. We spent a lot of time making sure they had as much data as possible, and had a good round of Localization QA to make sure the game was clear for native speakers. 

Hell is Us was developed in Unreal Engine 5. There is lot of talk online about games developed in UE5 that are released « badly optimized ». Still, Hell is Us has been praised both by reviewers and players for how stable it was at release. How did you approach the development to ensure that? 

People mention this to me a lot, and all I tend to say is: “We used the tools provided to us.” We are a gameplay team, we don’t have engine nor rendering programmers. We try and make the best game we can with the tools we are given.  

Unreal Engine has a lot of features, and these features tend to all have many different settings. Tweaking these settings, which are sometimes undocumented, for our game was crucial to have a pretty, and optimized game.  

We use many of Unreal’s latest technologies: Nanite, Lumen, MetaHuman, and others. Despite this, we still had to trim the fat and keep only the sub-features we wanted. For example, MetaHuman generates cinema quality characters, which would be too expensive. We spent some time removing features from the characters, like higher level of details, so they would contain only exactly what we needed for our game. 

screenshot hell is us

Shader compilation is one of the major causes of stutters the first time one plays the game. We opted for a twofold solution to mitigate stuttering. We do have some shader compilation at game start. Many players might not see it because it happens in the background as soon as the game is launched. We also compile shaders when first loading a level. We spread the load so the player isn’t inconvenienced, but we also make sure all the shader compilation is complete when a player starts moving around in a map. 

In our tests, stuttering also occured when loading new map areas. This was caused by collision data. We spent a fair bit of time creating optimized collision assets, and removing unneeded collisions from some game objects, to reduce that burden when loading new map areas. 

Very early on we implemented automated performance captures which helped us gauge how optimized the game was on the different platforms. This was a boon to understand many of our bottlenecks. 

Rogue Factor’s previous efforts were turn-based tactical strategy games. Which is a far cry from a third-person action-adventure game with a combat system to build from scratch. How did you approach that transition from a technical perspective? 

Mordheim and Necromunda, despite being turn-based tactics, had a third-person, dynamic camera. This gave us a leg up to understand the challenges inherent to this camera style in Hell Is Us. 

The Combat system is something we worked on continuously during the creation of Hell is Us; To make it interesting, to make it fun, to make it crunchy. We went through many variations. Doing something different with the health and stamina required us to play, iterate and validate our ideas. Hell is Us’ combat system is also built to be 2 on 2. Rémi and the Drone against a Hollow Walker and the Haze. We didn’t make it easy on ourselves! 

screenshot hell is us

The main technical challenge in combat systems is chaining effects. It sounds easy, but it’s difficult. The attack triggers a pushback which cancels your current attack, but you can’t get pushed back behind a wall, etc, etc. There are a lot of actions which compound and can create issues which are difficult to track down (to understand where in this big chain of events something went wrong). 

A priority for us in Hell is Us was to always have a stable build. You hear horror stories of game builds being unplayable for months, but we made sure to fix all crashes and major behaviour issues very quickly. This allowed us to keep iterating in the real world of the game as opposed to test maps.  

So really, technically, what I did was to make sure everyone had time and were not blocked when working on the combat mechanics. Because iteration takes time, and time is always what you need more of. 

Sometimes, the greatest technical achievements are invisible to the players. What would you say you are the proudest of in Hell is Us that players don’t necessarily notice? 

In Hell is Us there was a big focus in making each area of the game unique. Each map was tailored made, and that created challenges for all the teams to make that map shine. 

The mood in Talju required a lot of VFX, smoke and fog, embers, and also a special system to transform the wood boards into burned wood. In a map where visibility is reduced, we also wanted to make sure the distress smoke signals were visible. 

Arcas Spire, with its multitude of enemies, was particularly challenging. Our baseline in the game was 6 enemies at once maximum. In Arcas Spire, there is five times more per area! We created lightweight versions of the enemies to make this happen. We removed things like health bars to reduce their processing cost, and we changed their AI to provide a good feeling of waves. We had to put in place a system that completely deactivates the enemies per area so if you decide to charge through you don’t have enemies from both zones being calculated. It was a fun challenge! 

Hell is Us is Rogue Factor’s biggest title to date and releasing it into the wild is always scary. Especially on PC, you don’t know if the game will have issues or not despite all the testing we could have done; there are just too many variations of PC configurations. In the end everything went smoothly, and seeing people enjoy the game and saying the game is beautiful and well optimized is everything I could have asked for. All the credit goes to the different teams having worked hard to make this happen, and I couldn’t be prouder of them. 

screenshot hell is us

Publications similaires

Laissez un commentaire