Catching Up: Refactors and UI Screens

Author: Sreenath Premkumar Sreekala

For the past few weeks, I've been playing catch-up after implementing an Entity-Component-System model to the Engine code which meant that a lot of the features that had in implemented in previous builds had to be re-done to work with this new paradigm. After about 2 weeks of mostly pushing changes that were behind the scenes and not visibly new features to the game, I've shifted my focus onto things that can be seen and interfaced with while playing the game. The obvious place to start this was the game UI, which was the focus of this last sprint.

For ease of managing the code I'm writing, I decided to use an open-source Immediate mode UI library called Nuklear to handle UI primitive generation and layouting. While I expected this to be straightforward, issues inevitably popped up in both the Rendering and Input Processing Interfaces. I'll be talking briefly about the challenges with the Input Interface for the UI in this post.

Nuklear primarily targets the PC platform and is designed around a Keyboard and Mouse Input model. In the past, most projects I've worked on had also exclusively used these Input devices but for this project I'd decided to prioritize Controller support and had not implemented any Keyboard/Mouse Input handling into my Engine yet. UI Navigation with a Controller is slightly more complicated than what I was used to with additional state needing to be stored like the Current Active Widget and information about what widget should be selected when a Navigation input is received on the Current Widget. Combining my inexperience with the fact that Nuklear was designed not to include this kind of additional state tracking meant and a refactor of the Input System from a lot of global behavior handled in one place all together to a more component-focused model led to a lot of questions about what the best way to implement UI Input Processing was in terms of scalability for future builds.

While the current system approaches this by separating the drawing and Input tick and storing the widget navigation information in the Input Tick function that gets called, it's still not as granular as I would like it and it's scalability when having multiple different menus on screen, as one is wont to do in an ARPG with inventory, stats and ability management. It still serves as a useful starting point to further refine as more complicated testcases arise in later weeks and isn't too much sunk cost to end up being difficult to refactor later on if need be.