vittorioromeo/SSVOpenHexagon

Make the Menu UI Scriptable

Morxemplum opened this issue · 0 comments

One of the issues that I have pinned for this repository is issue #333, the issue that involves heavily polishing the menu UI started in 2.0.3 to fix a variety of issues with the current menu. This menu is definitely a step up from previous menu UI, but it is not perfect.

When looking at the current code for the 2.0.3+ UI, it is quite a mess. It's hard to follow along due to the lack of documentation. But another core philosophy we have at Open Hexagon is how moddable the game is. Open Hexagon's biggest selling point is the fact people can make their own levels and packs. I think it is time that we introduce a new category that packs developers or new developers can give a shot at, and that is custom UI development.

Essentially, we want to make the UI scriptable. Not only would this be useful to people who want to fork the game, but it would also benefit our goal of finishing issue #333. We'd almost be working from a clean slate, but it is important that we try and make sure that any new code we add to the repository doesn't turn out to be spaghetti code. We are still trying to recover from a lot of the spaghetti code and we want to stop more spaghetti from being introduced.

Think of this issue as trying to create the toolbox that is needed when we script #333's new UI. Below is a checklist of features that I would like to see incorporated in this "toolbox" to ensure that we have the full power to create the new UI.

  1. Represent different types of UI elements that can be created (either as classes or following "data orientation")
  • Scenes
    - These will be the individual screens that will be displayed throughout the game (that isn't the actual game). Each scene is meant to represent a different aspect of the game (Main Menu, Level Selection, Leaderboards, Settings).
  • Dialogs
    - These behave similarly to scenes, but they are treated different in terms of the render logic. They are meant to overlay a scene and not replace them.
  • Frames
    - The simplest UI element. Can be used to draw basic UI elements such as backgrounds and decorative UI. Usually used as a parent that contains the children UI elements
  • Text
    - The basic UI element to represent text.
    - Some forms of text can be modified through user input.
  • Buttons
    - A basic UI element that allows us to do basic input. Buttons must be clickable with a cursor and can also be activated by a keyboard
  • Images/Sprites
    - A UI element that allows us to quickly implement rasterized graphics in the game (vector graphics?)
  • Sliders
    - A slider is a useful configuration option that allows us to slide from a minimum value to a maximum value. Features a knob that can be adjusted with a cursor. Keyboards can use left and right to adjust the amount.
  • Checkbox / Radiobox
    - A checkbox / radiobox contains boolean values and useful for configuration. Can be toggled with a keyboard activation press or through the click of a mouse.
  • Dropdown menus
    - A quick menu of pre-selected options that the player can expand to read additional options. They can select one of these options and it will be the newly assigned value.
  • Preview Area
    - A singleton element that represents an abridged version of the Hexagon Game.
    - Should be able to apply level styles to it
    - Must render: Background panels and central polygon with stroke and cap
    - Optional: 3D Skew and 3D layers
    - Must NOT render: The player
  1. Represent Scenes through a Stack for easy navigation and rendering.
  • Make sure only the scene at the top of the stack is rendered on the frame.
  • Any Dialog options on top of the Stack will interrupt input on any lower inputs. It'll render lower elements down to the first available Scene.
  • Add Lua functions that allow developers to push and pop Scenes / Dialogs to and from the stack
  1. Add Lua functions to retrieve metadata (Recommended to add a new prefix "ui_"). These include but are not limited to.
  • Profile / General Metadata (ui_getCurrentProfile(), ui_isOnline(), ui_getLoadedPacks(), ...)
  • Pack Metadata (ui_getPackName(disambiguator, packId), ui_getPackAuthor( .. ), ui_getPackVersion( .. ), ui_getPackLevels( .. ))
  • Level Metadata (ui_getPersonalBest(disambiguator, packId, levelId), [Other attributes found in the level and associated music JSON])
  • Leaderboard Data (ui_getTopNScores(disambiguator, packId, levelId, N), ui_getScoreRange( .., startingPos, endingPos), ui_getOnlinePersonalBest( .. ))
    - These will only work if user is connected and logged in. Also, possibly make the server limit the number of calls to avoid abuse.
  • Configuration Metadata (ui_getAvailableResolutions(), ui_setFullscreen(boolean), [Look at config.json])
  1. (Optional) Add a tweening system for customizable animation through C++/Lua interfacing

There may be other things I'm missing and this checklist is subject to modification. However, this should give a good idea of what we need to do to make a scriptable UI.