Godoku v0.2.4

Update

This one took a while, huh?  It seems small from the user's perspective, with few new features, but we're pretty proud of this update.

• Pop-up menus - now referred to as `modals` in our project, - for name entry, settings, etc have improved "exclusivity" behavior. They no longer overlap each other incorrectly when one is intended to be on "top".
• Modals now handle pause behavior in a uniform way, reducing the cases where a pause state can get stuck.
• Modals now have universal behavior for hiding when the "ui_cancel" input is received.
• Modals now hide before changing scenes
• We fixed the score sorting bug *again*.
• Unified some UI on menus, added menu titles and ES translations

Godot Development

Windows, Popups, and UI

As you may recall from our previous post, we went with the Window node approach to take advantage of the robust window management already present in Godot. Unfortunately, we couldn't find a combination of settings to get just the behavior we were looking for.

No combination of settings seemed to produce a truly exclusive modal dialog; it was very easy to get one modal stuck behind another in cases where a pop-up menu might want to pop up a sub-menu.

So we replaced it with a straightforward Control node approach with a custom script. It's all very simple code, but it's very easy to get some behaviors wrong when dealing with an aggregate stack of UI elements.

Big Crash Kapow

That would have been enough work for one update, but we ran head-first into an exotic race condition.

Our base `modal.gd` script is on a `modal_base.tscn` scene, and each menu is a scene that inherits from `modal_base.tscn` using Godot's inherited scene feature.

The scene `modal_settings_menu.tscn` contained a `MenuTitle` node, which was analogous to nodes in other scenes: `PauseTitle`, `DifficultyTitle`, etc. To unify all that on our base scene, we added `MenuTitle` to scene `modal_base.tscn`. This caused all inherited scenes to get a `MenuTitle` node, including `modal_settings_menu.tscn` which already had one.

This causes a name clash with two nodes named `MenuTitle`. Normally, when the editor detects a name clash, it displays a warning and renames the node automatically. So `modal_settings_menu.tscn` gets `MenuTitle` and `MenuTitle2`, and we just delete the extra. Simple, right?

Godot didn't think so. The editor couldn't reconcile the two on launch, causing the scene to fail loading. Which meant all scripts that referred to that scene failed to load, which cascaded through all other scripts referring to anything in that chain. It would then leak a bunch of memory and crash.

Since we didn't know the cause at the time and only saw the crashing, we resorted to some drastic testing. We started deleting scenes and relaunching until it succeeded. We narrowed it down from there by using a plain text editor outside Godot and finding each link in the load failing chain until we discovered the offending name clash.

The biggest mystery is why the usual name clash resolution failed and saved the project in an unlaunchable state. In a fresh project, the same scenario causes it to correctly rename a node to "MenuTitle2".

Overall, this has been one of the *roughest* updates with Godot. There are under-documented features, unpredictable behaviors, and opaque error messages. As a community-driven, open source project, it's up to us to improve them, but it's very difficult to balance the role of "Engine Maintainer" on top of all the other gamedev hats.