Thank you to the Rainbow Six Siege UI & Phoenix Technology Group teams, for helping with this article.
Rainbow 6 Siege was launched eons ago, at least with respect to the video gaming world. And when you launch a game, you dream that it’ll thrive for years to come, but the reality is that very few games can pull it off. For those that do, the game developers then encounter a new but very interesting kind of challenge: keeping up with technology.
In that spirit, in 2018, the Rainbow 6 Siege dev team forecasted a problem for its live game: the game’s user interface (UI) was primarily running on Flash, and using Flash to create its menus and heads-up displays (HUD). Other businesses also mainly used Flash, so most artists were trained to work with it. As you know, Adobe stopped supporting Flash and no longer releases application updates. Since our UI was developed on Fire, which is an in-house solution similar to Scaleform (Scaleform produces APIs that communicate directly between Flash content and game engines, as well as premade integrations for more popular engines such as Unity or Unreal Engine), we were somewhat protected from Adobe’s updates and didn’t feel an urgent need to act while being aware that the deadline was looming on the horizon. In the meantime, Ubisoft’s Technology Group was starting a new project, a complete solution that would depend on no external technologies to create UIs: Phoenix Studio.
The Technology Group’s mission is to improve productivity and efficiency of Ubisoft’s different videogame pipelines. One of the challenges we’re often confronted with is that of anticipating changes in the industry, and Adobe’s depreciation of Flash was, in that sense, inevitable. But that didn’t make it a simple problem. An external solution would carry important implications over many years; some inconveniences, but also numerous benefits that we’d otherwise have to provide within Ubisoft, most notably the creation of an intuitive and flexible editor that would allow us to continue leveraging our pool of talented UI developers.
And so, while simultaneously maintaining and supporting the existing software, a small team within the Technology Group started developing the Phoenix platform. Phoenix is a feature-rich application built to develop and integrate UI game content (HUD, menus, signs and feedback) with sharing and extensibility top of mind. It consists of Phoenix Studio, a node-based UI editor, a lightweight Runtime library that is integrated into our various game engines, and the Phoenix Widget Library that shares existing, common base elements.
It is still evolving towards maturity today, offering more advanced functionalities, but has proved itself in production, having been used in many Ubisoft games such as For Honor, Trials, Anno, Hyper Scape and the Ghost Recon franchise.
Through this evolution, Phoenix grew to become an excellent tool for creating, maintaining and debugging UI, and numerous projects starting choosing it over Fire. As for Rainbow 6 Siege? Well, Rainbow 6 Siege was already live, with a full and functional UI made in Flash. But to stay on top, we had to upgrade to a technology that would set us up for the future. We knew we had to make the jump!
Phoenix allows our teams and all Ubisoft teams to be more creative than ever, delivering UI content that can be worked on and updated more easily. Obviously, one of this solution’s most important benefits is that it 100% belongs to Ubisoft, which gives teams like ours more control over the functionalities developed by the Technology Group. It also allows us to share and improve the tools via our brands and helps stabilize our versioning. The Technology Group is inspired by industry standards and makes it a priority to track industry trends to ensure it is offering world-class tools, tools we use daily on Rainbow 6 Siege.
As we investigated this new technology, it became clear that we needed a better application framework; it would allow us to migrate to Phoenix from Fire more easily as well as improve our work methods. We took the time to identify our pipeline’s weaknesses and associated improvements.
The framework should support multiple views (both Fire and Phoenix) for any given UI. This had to happen in order to make the migration possible, as well as to more “easily” support any necessary changes in artistic direction, special events, design changes, and more.
The framework would need to focus on stability and optimization. We added a test framework that would allow us to more rapidly catch issues to the features list; we wanted it to run better than the Fire version.
The framework would also need to ensure that framework code and game code were properly separated, and offer the building blocks necessary for developing UI for any kind of game. As such, we opted for a model-view-view model (MVVM) architecture that helps us enforce a better structure and consistency across the code base. MVVM is a software architecture pattern that facilitates separating the graphical user interface (the view) from the development of game logic or back-end logic (the model), which means the view remains independent from the model’s specific platform.
Ultimately, we felt that the “final” product met our requirements and the goals we had set for ourselves at the onset.
Once the foundations were set, it was time to port menu and HUD elements to Phoenix from Fire. Since the migration had to happen concurrently with game maintenance, we had to recruit programmers and artists. We started with an easy migration to allow our people to get used to working with Phoenix and the new framework.
And then the major migration work started.
The first step in any port is creating a switch for the module that is being ported. This allows us to rapidly switch back to Fire if something goes awry.
UI modules typically exist on their own screen. For most menu ports, we reused existing screens, but in some cases (mainly HUDs), a new screen had to be added to the User Interface Factory. The factory is responsible for creating and hosting all the different sequencers, compositions and screens you see in game. This is executed in the code and, once it’s in Anvil, the programmer is also tasked with submitting screen data.
The next step is determining whether the new view model is required for each screen being ported. We try reusing view models if they’re accessible within the screen’s context and they already contain the necessary information. In most cases, we had to create new, dedicated view models. Once those were developed, we would typically submit the view models to the codebase without connecting them to the gameplay so artists could start working on them as early as possible.
While the artists were hard at work integrating assets and creating data bindings, our programmers were adding signals to the different game systems so that the new view models could connect to the view’s constantly updated values. For instance, each time a player changes direction, a signal is sent to the view model’s compass to ensure all values are properly updated and the compass rotates accordingly.
Once the models’ characteristics are ported to the new system, UI dev testers get their hands on them. If they don’t find any issues and behaviour remains 1:1, we flip the switch that allows all testers to test the port. If it’s all green lights, the port remains activated, and we send it off to our players!
We’re finally reaching the end of our journey. As we write these lines, 90% of our menus and HUDs have been ported and activated for our players.
We’re seeing major Fire crashes decrease and close as we remove the Fire menus. We’re rapidly seeing the updates and improvements to the Phoenix menus take shape.
So what’s next? Maybe we’ll develop a UI robot that tests each menu automatically… but that’s for another blog post
