Best Practices For Bringing Your Unity Game To Steam Deck

First, just start by telling me a bit about yourself, your background, and giving me the elevator pitch for the game!

I'm Josh Steinhauer-Li, a Game Developer who started in the Adobe Flash days, and nowadays I spend quite a bit of my time as a Unity dev, both professionally and as a hobby. I'm the Lead Developer of Ardenfall, an open-world RPG focused on player freedom, inspired by the likes of Morrowind and Fallout New Vegas. 

We recently released a controller update to our Ardenfall Demo, which allowed the game to run on Steam Deck. This is an early look, and we've learned a lot, both in the development process and players' feedback!

What specific technical and UX challenges did you encounter when implementing controller input, especially for systems that were initially built around keyboard/mouse?

The first difficulty was getting gameplay to feel good on the controller – the main issue was aiming and looking around, which requires a balance of speed and precision. Our current solution is an aim curve, which makes low delta movements on the joystick rotate your camera slowly, and high delta movements on the joystick rotate the camera quickly. This gives players precision when they need it, but also lets them spin the camera around quickly when desired. 

UI turned out to be the main difficulty, however. Every element must "connect" to another, allowing the player to navigate smoothly. Every button must be tied to a controller or keyboard input. Selection now had to be communicated as well. When the user is pressing down on a list, the list should automatically scroll. So many details!

Selecting UI Elements must be communicated well:

Auto-scrolling:

We also had to replace all of our dropdown menus with a scrollable menu!

Another complication in a few places was input suppression. On the controller, you can use the directional buttons while playing to trigger various inputs, such as opening the map. But once you walk up to a crate, you need to use the D-pad for navigating the menu! Our solution was to disable all uses of the D-pad when this menu appears.

Once the quickloot menu appears, the D-pad is used for navigating the menu:

Another difficulty was ensuring controllers and keyboards would support rebinding. During this update, we switched from Unity's old Input Manager (which relied on our own version of rebinding) to Unity's "new" Input System. Along with this came new restrictions, but also new flexibility. The Input System supports rebinding built in, using the PerformInteractiveRebinding method.

Our action map setup using Unity's "new" Input System:

Ardenfall's rebinding menu:

When you added controller support, were there any core gameplay systems (menus, targeting, movement) that required rethinking or redesign to feel natural on analog sticks and gamepads? How did you address those?

There were several menus that had to have a good amount of thought in terms of interaction. The trade menu was the most hectic - two inventories next to each other, with the ability to switch categories and transfer items. This is effortless on a mouse and keyboard, but with the controller, we had to add a "focus" system, allowing for the player to switch between each menu to then manipulate it.

Switching focus between two inventories:

Something else we had to reconsider was hover tooltips – a bunch of UI elements originally had icons you could hover over to find more information. We replaced these tooltips with just displaying more information outright, which turned out to be great for PC players as well, as it turns out many players weren't hovering over the information in the first place.

Supporting a platform like the Steam Deck often demands both performance and UI/UX considerations. What optimization techniques (rendering, LOD, quality scaling, etc.) have you used or are planning to ensure a smooth handheld experience?

Ardenfall has a lot of techniques to ensure the game runs smoothly – from the very beginning, we wanted this game to run on low-end devices. 

Our world is split into cells, with a 3x3 grid of cells always active around the player. To achieve far render distances, we create "Distant Cells". These are stripped-down versions of every cell in the game, with all collision, most scripts, and all small objects removed. What remains is a very light and simple object we can activate in the distance.

Our terrain is also simplified at a distance, and the splatmap is baked down into a single texture. Example of terrain shrinking:

Normal cell (1306 meshes) versus Distant Cell (219 meshes):

We also have an Offline AI system, which allows NPCs to simulate their jobs without actually existing. Once the player gets close enough, they'll spawn in as if they existed all along! AI in general also scales in update rate, depending on how close they are to the camera.

One high cost in Unity (and even worse on Steam Deck) is skinned mesh renderers. These are meshes that can be morphed with bones, usually used for characters. We automatically combine skinned meshes when possible, using Unity Jobs (multithreading) to ensure characters are as optimized as possible. This can turn an entire armor set from 5 skinned meshes into 1!

This armor set is usually 5 pieces, and is merged into 1:

Speaking of UI, many clients built for desktops suffer from tiny UI elements or navigation issues on handheld screens. What lessons from UI/UX design did you apply to ensure menus, inventories, and text are playable on the Deck's display?

We quickly learned that some of our UI was too small, and have started making some elements larger. We're starting to build some rules on the smallest text size, smallest button size, and so on to ensure we can have a consistent experience on both PC and Steam Deck.

From a technical perspective, how do you handle input detection and switching between controller and keyboard/mouse – especially in Unity? Did you build custom systems for fallback navigation logic, or rely on Unity/Steam Input subsystems?

We built a system that detects the last device used, and dynamically updates input mode and glyphs whenever the input changes. Every frame, we poll each device – for keyboard, we read anyKey, and for controller, we manually poll each input button. If there is no device detected, we fall back to keyboard and mouse on PC, and the Steam controller on the Steam Deck. This was built on top of Unity Input. 

We also ensured that a controller disconnect causes the game to pause, this is actually a requirement from Steam to flag your game as having controller support!

Steam Deck hardware can vary performance-wise from desktop PCs. How are you approaching performance profiling and optimization? Are there certain engine systems or content types that you've prioritized tuning for handheld?

Our profiling pipeline is quite simple – uploading a dev build to an internal Steam branch, and using Unity's profiler over the network to collect frame data. Since we're targeting pretty low-end PCs, the difference between a Steam Deck and a PC in terms of performance is negligible, instead, the main difference is battery life and thermals, making it similar to a mobile device.

Battery life and thermal constraints on handhelds are important. Have you implemented (or considered) dynamic quality scaling, frame capping, or device-specific presets to help maintain consistent performance on devices like Steam Deck?

Lower resolutions and especially frame capping are absolutely the easiest way to increase battery life. I've dealt with this in the past with mobile titles in Unity, it's by far the biggest limiter on graphics fidelity on mobile devices at the moment. Sure, you can make the game pretty, but does it burn your hands or wipe your battery? 

At the moment, we expect players to fiddle with the settings as they see fit, but we plan on adding a special "Steam Deck" preset for graphics to have a good starting experience, and also a battery saver mode that forces a 30 FPS frame cap and lower resolution! 

We're also planning on hooking into Unity's dynamic resolution feature, which allows us to reduce the resolution when the framerate dips. This is especially useful on the Steam Deck, as lowering resolutions is less noticeable on handhelds.

Controller support extends beyond just mapping buttons and includes things like icon glyphs, radial wheels, text navigation, and contextual prompts as well. What tools or approaches are you using to ensure the UI communicates effectively regardless of input method?

When adding support for controllers, we indeed implemented several types of glyphs, updated all menu buttons to display glyphs, and added context panels to communicate how to navigate menus. 

Some glyphs had to be integrated into the text, using a dynamically assigned TextMeshPro Spritesheet.

Contextual Panels need to be used in practically every menu.

Our game uses quickslots for using items with the 0-9 keys, so we added a quickslot wheel to easily switch between items. This turned out to be very useful for pc players as well, as pressing the 0 key on the keyboard is uncomfortable.

One little trick we did was give the first quickslot item a default binding on the controller, and ensured any quickslots that have a binding will correctly appear in the UI. This gives the player full power to bind however they want.

What have been some of the most surprising player expectations or feedback regarding handheld/controller support during the Steam Next Fest demo, and how has that shaped your development priorities?

A lot of players ran into issues with the controls on the Steam Deck, while many people generally praised the controller support. We plan on doing a big pass for default Steam Deck controls to ensure they feel correct!

Looking forward, do you plan to formalize Steam Deck/handheld optimization as part of your ongoing development pipeline? What advice would you give to other indie developers approaching similar support for Unity games?

We plan on doing a lot more work with Steam Deck, this first phase was just the beginning! We plan on officially supporting the Steam Deck for Ardenfall Early Access. 

As advice, the most obvious thing to do is go out and buy a Deck if you don't have one. There's absolutely no way to make a good experience without testing it physically. Second, have players test it and give feedback. I myself am not a controller type of person, so I greatly rely on other players to tell me what feels good and what feels bad. Feedback is huge!

It's also a great idea to at the very least have controller support in the back of your mind when implementing UI, if you want to eventually support it. Avoid tooltips when possible, and consider navigation flow. Controllers can be a difficult beast to work with, especially with their heavy limitations compared to keyboard+mouse. But these days, gamers seem to expect support even on Steam, and now the Steam Deck is the big new reason to consider adding support, who wouldn't want to play your wonderful game on the bus or in bed?

Josh Steinhauer-Li, Project Lead & Programmer at Ardenfall

Interview conducted by David Jagneaux

Don't forget to subscribe to our Newsletter, join our 80 Level Talent platform, follow us on Twitter, LinkedIn, Telegram, and Instagram, where we share breakdowns, the latest news, awesome artworks, and more.

Are you a fan of what we do here at 80 Level? Then make sure to set us as a Preferred Source on Google to see more of our content in your feed.