GUI Customization Features

[stickgrinder]

Topic

Providing a set of GUI customization features to game developers.

Goals

This issue will synthesize a discussion @mapedorr, and I had yesterday about the epic of GUI features.

The goals of this discussion are:

• to clearly identify the target user(s) of this feature set
• to clarify the conceptual entities that define a GUI
• to come up with a set of viable solutions and (if necessary) a sort of roadmap / step-by-step breakdown of what Popochiu will provide to the target audience(s)

Current status

I'll list what we know:

• GUIs are a pretty complex topic because they tend to vary quite a lot between games. We can say that the GUI defines the game as much as its setting, story, and puzzles.
• Godot makes creating GUIs pretty easy. The engine features in that area are accessible, simple, consistent, and well-documented. Despite this, creating a custom GUI from scratch requires both a solid understanding of all Control nodes and theming and a set of information about how to tie in with Popochiu events and logic.
• Many game developers will expect Popochiu to provide an opinionated view - and related features - on how to create every element of an adventure game. So, GUIs must be considered first-class citizens.
• Creating a GUI is different from creating a room or a character because the GUI scene (that is necessarily a scene by itself) can't be seen "in place", so it requires a bit of abstraction to understand how it will behave once the game is run.

A key point is identifying who we are creating these features for.

The spectrum goes from "I select a GUI among the ones available" to "I want a totally custom GUI to support innovative gameplay, so we may want to:

1. provide tools to quickly theme the GUI elements without knowing Godot theming system (that is pretty complex to grasp and not very user-friendly)
2. let the users mix and match different readymade GUI components to create one coherent variant of the GUIs we already provide
3. give users a set of GUI elements they can place on the scene the same way they do with room elements (buttons, sliders, grids, panels of sorts) that are already tied with a base logic to function out of the box
4. provide a clearly defined API (signals, hooks, virtual functions, properties, etc.) that allows ANY GUI to be created (the idea of commands goes in this direction)

The further down the list below we go, the more important documentation becomes: binding Control nodes to the engine logic (point 4) is already more than feasible, but it's probably not coherent or documented.

Record of decisions taken

• To partially address point 2 in the list above, we speculated that current GUI components (the ones providing macro functionalities like an inventory, save and load popup, command buttons, etc) will be divided in categories. This way we may have three components in the "Character speech" category, four in the "Inventory" category, one in the "Game settings" category, and so on.
• The currently hidden "GUI" tab of the main doc can allow users to select which among the available components they want in their GUI, for each category. This way they can achieve incoerent results (the "Caption" speech won't play well with the "9-Verbs" command panel, for example), but they can achieve a degree of personalization without knowing that much about how GUIs work either in Godot and in Popochiu.

This will address point 2 above and, paired with a decent set of preset GUIs to kickstart a game, it's in itself a valuable tool under each indie dev's belt.

• We need to analyze the other points and decide how to address them, providing a split and a possible roadmap (priorities, not delivery dates) for these features.