Engine Changes - BigAnt

Our widget system didn't support ultrawide screens and even though ultrawide gamers only make up about 5% of PC users, I had a firm stance that we should support them as best we can.  Before my changes the widgets would scale incorrectly since our engine assumed you were running in 16:9, so added the correct logic for scaling and positioning  and keeping the UI in the centre of the screen.

We have been coasting on Noesis version of 3.1 which came out in 2021 and since then they have made strides in performance and better tooling. After requesting an update to our technical lead during some downtime, he allowed me to upgrade the SDK. It was a great experience to update our Noesis to 3.2.10. It did come with some unexpected hiccups however.They made the reflection they implemented case sensitive which wasn't a big issue for all of our bindings but when it came to our custom in house controls they all stopped working  so off  I go to find all the  incorrectly named controls
(eg. `workspace.controls.customcontrol` to `Workspace.Controls.CustomControl`)
I eventually found most of them so I wrote a new wiki page that allowed me to document these new changes  and new pitfalls that we could fall down.

When we got our new editor we had an easier pipeline to make tooling;
I made a Noesis Inspector that allowed us to track focus since we had an occasional issue where ItemsControls that were purely for data presentation were focusable. We found it hard to track those issues down without opening the NoesisGui Inspector(Official Noesis Tool) and using that to track focus (it crashes a lot).

 
View Refreshing: When we have a view, for example the frontend background, we previously had to reboot the game after small changes to test them. View Refreshing  allowed for faster iterations on screens. With that, I added a theme selector where you could paste the file path of the theme you wanted to apply and it would apply it .This was very handy when it came to HUDs and Wipes.

View Model Inspector: When we construct a view we also provide a ViewModel, this is all the data associated with the screen itself. (MVVM).
We ran into an issue debugging different screens where the data was dynamic, such as strings being cut off or triggers on different data. So I decided to make a ViewModel Inspector.
This grabbed the ViewModel from the screens that were currently loaded and formatted the data into clean , editable values that you could change on the fly. This made it easier to test different states and debus issues without needing to change the underlying data or reloading the screen.

For longest time, the career team had been dealing with pringing their debug infomation directly to he output window. So I started making a framework that they could take over, control and use to make their own tooling.

This allowed the to quickly view large amount of data, including:

• States of competitions

• Players infomation

With this tooling, they were able to work more effciently and were no longer bottlenercked by the UI team needing to implement screens before they could properly test their features

We use a generic screen control that scales up or down depending on the resolution and centres the UI to the screen. This control was made before I came to Big Ant and had the ability to fade the entire screen in and out, but I found that in most cases it fell flat and wasn't really being used.

So this year (2026), I expanded the intros and outros so they could also transition in and out from the left or right. It works by passing an enum through the XAML, and when you tell it to run the into and outro, it plays the correct storyboard.

It doesn't seem like much, but it really helps make the game feel that little bit smoother and more polished. I then showed it to the team how to use it and documented the system, and now our next product has screens swooshing across the screen in a consistent and coherent way