I was on the UI team for the XB1/PS4 console port of this surprisingly popular MMO. I had never heard of it personally when the project began, but a number of people in the office happened to already play it when the project was offered to our studio. In fact, our lead loved it. It was virtually the only game he had played for over a year. He was overjoyed to get to work on it. Quite good luck…or so it seemed.

The primary concern for the UI team was that the hundreds of panels all needed to be controller navigable. All of the selection code was incredibly mouse-centric so we had to work out ways to hook into the custom UE3 engine they had built to highlight and select buttons through other means. This wasn’t too burdensome a task, but got complicated at times with the lack of English comments and often confusing combination of complex systems. Systems complete with plenty of hacks, typical of the codebases for big games like this.

The UI lead implemented a navigation grid system for the team to use that ended up being quite problematic. He is an intelligent guy and a great lead, but this was his first lead UI role. As the grid structures had rigid rows and columns, it was woefully ill-equipped to deal with the mass amounts of varying panel shapes and sizes that often did not fit such an orderly format. Worse yet, you had to manually specify every position slot for every widget to be in and it required elaborate special case code to override behavior for the many widgets that weren’t quite lined up.

The team worked on a dozen or so panels in this manner, but it was slow going. It got so bad that there was even some dissension amongst the ranks. Team members complained about the ineffectiveness of the grids and started implementing their own special-case code to deal with each individual panel. This made things worse. As panels began to be implemented differently, it was hard for others to understand or fix up issues with them. Of course, a standardized system was more desirable; this is a facet of coding big projects that too often gets undervalued until it’s too late.

To deal with this, I knew we needed something that everyone would be happy using to unite the team. So, it had to be easy to use. I had previously suggested a graph structure that would default to sensible navigation using the rough positions of the surrounding widgets. This had been shot down as “too unpredictable”, but now that the seams were falling apart with the grids I got the green light.

The graph was much easier to work with because it had no enforced structure. It used a cone shape pointing in the direction pressed that iteratively widened until hitting a widget to navigate to. This resulted in going where you would usually expect first, but still allowed you to reach any widget in the general direction if the panel was more sparse. Truth be told, it worked so well that even I was a bit surprised. I had little UI experience at the time but later learned that a graph is much more typical of the common pattern to use for a system like this. And lo and behold, it nearly got all the navigation the way it was wanted straight away!

This brought the development time for each panel down from days to a matter of hours. You could just throw all the widgets in it without having to visually calculate rows/columns or add everything in a set order. It wasn’t perfect; panels still needed some special case directions provided explicitly for a couple navigation points. For this, I hooked up a function that that let you specify overrides very easily with an origin widget, a direction, and a target widget. This was much better than the complicated web of interacting grids in the original system and much easier to visualize.

We later found out that some panels were dynamically populated over the network so had no initial set configurations. The old system wouldn’t have worked at all for these whereas the new one dealt with it naturally.

The column lists were another challenge that needed to be tackled. Initial implementations were index based. We would keep track of what element index we were on, divide this by the total number of elements in the list, and then scroll to that percentage of the overall box. This seemed like a sensible plan initially, but it had a few drawbacks. One of those was that the scroll would often be slightly off.

After thinking on it a bit, I realized the index-based approach was sort of backwards. What did we really want? We wanted to scroll so that the selection would be in the center, so I implemented a new system which calculated how far away the center of the selected widget was from the center of the list, in pixels, and simply scrolled that many pixels. This was, of course, pixel perfect because it just directly did what was desired.

Anyway, these fascinating technical details ended up all for naught. After the port was completed and everything was running smoothly on the consoles, the publisher decided that they no longer wanted to release it. Yes, that’s right, after they had already paid for all of it! It was all a bit mysterious, but I heard they realized that some other console MMO that released shortly prior to the completion of this one wasn’t faring so well. Allegedly, they feared it might be embarrassing/damaging to the company’s image if they were to release an MMO on a console. This was not something the players would want, or so they now thought. Allegedly thought. I suppose we’ll never know for sure.

The moral tale on the value of better planning aside, this actually turned out to be one of the projects I am most fond of. Despite the bitter ending, the project was a blast because the team loved games. We played games like Mario Kart, Helldivers, Heroes of the Storm, and Lost Castle every day at lunch. It was disappointing that my efforts didn’t see the light of day, but it was great to work with a motivated team that was doing their best for the sake of the game because we all enjoyed them significantly.

But, yes, as for what to gleam on the technical side of this – when designing a UI system, a graph is a safe bet and will likely get the job done in good time. Automatic initialization of directions can save a good chunk of time as well. You often hear the platitude that thinking ahead can save you in the long run, but this project had some good practical examples showing that in action. It would have been nice if the publisher had a high level of skill in that regard though…