Like any respectable 4x game, we need UI. Widgets… Lots of widgets… Modular and procedural widgets within other widgets that fit into lists of widgets that are integrated into the grand “Main_UI”.
Once design and implementation stopped eating each other alive, it was finally time to put actual, visible content into the game in a form we could see and interact with.This was the phase where the first proper in-engine framework started taking shape. Nodes got their own structure, widgets started appearing, the data foundations were laid in properly, and the project started shifting from logs and strings printed to the screen to actual widgets.Of course, this brings about its own set of problems: Where should this widget be? What should it contain? Where do the buttons go? How does the player interact with them? Oh wait… Do we still have room for a frame in that huge stew of buttons and text?! Nope - ok, redesign - rinse and repeat.Needless to say, unless you have a big team and lots of dev time, as a very small team or solo dev, we find that the best approach is to make things game-ready as early as possible, and “No ragrets”! That also means you need to make sure the actual content you want in the game is the one being displayed on your widgets instead of white squares and “lorem ipsums” that never reveal just how bad your actual text or buttons will look like.Unlike some devs, I like doing UI, and unlike most devs, I like doing UI in Unreal. So I can’t say I didn’t enjoy it. But I also can’t say with confidence that I’m any good at it, especially UX. So, quite a lot of redesigns were needed, but since my templating is usually solid enough, it was basically a sliding-puzzle.Probably one of the first moments where the project began to feel like a real game rather than a promising organizational problem.(March 2026)