Solarus could use a UI framework

[alexgleason]

I've been focusing on menus lately. At first I found them intimidating but I'm starting to get the hang of it now. As a web developer, creating menus by drawing pixels is very weird. I know this is just how games work, though.

Still, I'm tempted to start breaking my menus into reusable components like in Vue.js. For example, I have multiple menus which contain a grid of items the player may highlight and select. I could see having an API like

Code ( lua) Select Expand

-- Example menu with reusable components

local title_bar = require("scripts/ui/components/title_bar")
local item_picker = require("scripts/ui/components/item_picker")

local menu = {
  components = {
    title_bar:new({bg_color={0,0,0}, text="Inventory"),
    item_picker:new({row=3, col=5, gutter=8})
  }
}

function menu:on_draw()
  for _, component in ipairs(self.components) do
    component:draw(self)
  end
end

return menu

idk, I haven't fully thought this through obviously, but I'd love to see some sort of component-based design in action. I haven't fully worked out how this needs to happen in Lua.

[llamazing]

For one of my demo projects I did exactly what you suggest where I made a script library solely for creating ui menus, and it is broken up into scripts for each type of component (button, text field, scrollbar, etc.). That library can be found here and is fully functional, and if you run the demo quest you can even see it in action (the demo quest makes heavy use of various types of menus). I don't recommend using that ui library as it is now, though, as there are a bunch of things that I don't like about the way I implemented it.

I've been working feverishly the last few months on improving just that library and making it more universally usable. There have been some significant changes in its implementation for the better. It's going to be another few months before I'm anywhere near ready to release anything, though.

My library only deals with placing components that don't resize, which greatly simplifies things, and resizing components is not something that a solarus quest should really need anyway. The library included in the demo project only deals with mouse/keyboard interaction, but I do intend to add controller support too.

I think having some sort of ui support built-in to solarus is a good idea, even if it only covers some of the lower-level stuff.

[alexgleason]

I've been working feverishly the last few months on improving just that library and making it more universally usable. There have been some significant changes in its implementation for the better. It's going to be another few months before I'm anywhere near ready to release anything, though.

That's super awesome!! Glad I brought it up, I'll look forward to using your library once you release it. For now I'm coding my menus in a horrible way that I'll surely regret, lol.

I think having some sort of ui support built-in to solarus is a good idea, even if it only covers some of the lower-level stuff.

I'm wondering if a package manager to manage third-party libraries would be a more flexible solution. I'm aware of LuaRocks (although I've never used it). But yeah, having something like a package.json (Node) or requirements.txt (Python) that lets you install a list of modules with a single command would be great.

[Max]

I'm amazing at everything and I'm currently in the process of solving everyone's problems.

Dude, this is great to hear. Menus are so hard, hahaha. Myself and @Vathox are trying to get an actual menu together to keep track of sidequests in Ocean's Heart (all my test players are like, I cannot keep track of all this, you need a sidequest log immediately.), and having a really tough time trying to figure it out. I haven't even really gotten a good grasp of the logic behind how you'd do something like that, so it's good to hear someone else is in favor of a little more support for developers in this area : )

But like, how much would you recommend against not using your old libraries? Is it like an "I wouldn't drive without insurance" recommendation, or an "I wouldn't jump off a cliff" kind of recommendation? Haha.

[llamazing]

But like, how much would you recommend against not using your old libraries?

The biggest thing I don't like about the old library is the way I was trying to cache images to reduce redundant processing, but in the end it gets too complicated and more than likely will just cause memory leaks. So I'm doing away with that mostly. The way properties are used to create new controls is significantly different too (but it is more streamlined and logical now), which means updating data files from the old library to the new one will be a significant undertaking.

However, the old library is perfectly fine for studying and better understanding how menus work.

Myself and @Vathox are trying to get an actual menu together to keep track of sidequests in Ocean's Heart (all my test players are like, I cannot keep track of all this, you need a sidequest log immediately.), and having a really tough time trying to figure it out.

If you want to send me a sketch up of what you envision the menu looking like, I'd be willing to whip something together that should at least be enough for you to take it the rest of the way.

[Max]

That's really gracious of you! I sent you a PM, and I'm planning on looking through your library later this weekend to learn as much as I can : )

[oclero]

Actually Chris planned this for Solarus 1.7, I believe