With House of the Dragon as its foundation, Game of Thrones: Dragonfirecombines large-scale multiplayer strategy and dragon combat into a free-to-play experience built for modern mobile hardware.

Players step into the role of a Valyrian descendant tasked with hatching, raising, and commanding dragons while competing with thousands of other players for control of the Iron Throne. Delivering that fantasy required balancing high-quality visuals, scalable performance, and live multiplayer systems across a wide range of devices.

We spoke with Ara Yessayan, technical director, and Taia Lee, advanced technical artist, about building dragons for mobile hardware, supporting large-scale strategy gameplay, and using Unity to bring the world of Westeros to life.

What strategies have you used to minimize load times for both new and returning players, and how do these experiences differ?

For a new install, the focus is to require as little data upfront as possible. We’ve explored techniques to reduce the amount of data that we need to download or load into memory before bringing players to the start of our experience, as well as using transitions as opportunities to cover some of those loads. For a returning player, we need more data to build up your player state and put you in the right spot on the map. While the premise is similar (minimize waiting on data), the techniques focus more on deserialization costs and strategic ways to require less upfront.

“Good design is not decoration alone. It creates meaningful, functional, and intuitive experiences that help people interact effortlessly, confidently, and purposefully every day.”

Ethan Carter

How did you identify your biggest load-time bottlenecks during development?

To tackle load times, we used a few approaches. To get an overall sense of where our bottlenecks were, we set up custom profiling events for each stage of our loading process, which were written out to a CSV file. We aggregated values across multiple sessions to identify which stages were hot spots. We also transformed these into Chrome Trace Events and OpenTelemetry traces so we could better visualize how the stages were loading in parallel.