1. Anders Ruud
  2. love
  3. Issues

Issues

Issue #1238 new

Proposal: Include love-nuklear as a Native GUI Framework

Landon Manning
created an issue

While I am aware that LOVE follows the general principles of Lua in that we don't want to bloat the API with cruft, I believe that one feature severely missing from LOVE is a native GUI module. There have been several attempts to make various GUI frameworks for love, all of which fall flat (including my own). I've been tinkering around with love-nuklear recently and it feels like a strong contender for something that could be included natively with LOVE. nuklear itself is an ANSI C header-only library and love-nuklear is a pretty decent Lua binding for it.

I really think LOVE could use a native GUI module, it would help round off all the major features in a framework that we already have, such as networking and physics. I'm not necessarily looking for a fast decision here, but perhaps we could discuss this?

Comments (57)

  1. lai weichih

    I think it can make LOVE more like a formal game framework, such as libgdx, unity, godot and game maker. Especially more and more gui library are stopping maintain and the rest are lack of complete feature. Of course if LOVE has stable graphic api then we can build our gui system from ground up. Before that happens, nuklear maybe a good alternative for the gui solution of LOVE. That can reduce a lot of effort for game developer.

    BTW, throw these problem by plugin system may be a choice. (~ OwO )~

  2. Andrew McWatters

    Please don't. I'd stop working with LÖVE if it decided to become more than the solid framework it has become. My team relies on LÖVE as a reliable Lua game framework, and we recently made the decision in Grid 8 to move away from our abstraction layers over LÖVE to using LÖVE directly in examples, so that people familiar with the ecosystem didn't have to learn another piece of software.

    We originally used abstraction layers over LÖVE to provide a means of moving away from the framework in the event we wanted to pursue extending the engine to either have 3D capabilities (in the realm of LÖVR's design, sans the VR focus), or stop using LÖVE all together. By making changes like this, my team and I would have to revert our decision, and possibly start moving away from this framework.

    In fact, our whole engine's tag line is "a game engine built on LÖVE" and in the past we've reported what issues with LÖVE we've stumbled on while building out parts of the engine.

    The way I see LÖVE is that it's a game framework. It exposes to Lua routines related to window management, graphics, audio, image loading, and these low level concepts in a high level programming language. Planimeter's engine builds on this, and provides high level concepts like ui, client server architecture, maps, entities, pathfinding, and other engine-level implementations.

    Unity is not a game framework, it's an engine.

  3. Jan Werder

    If find that logic hard to follow. Don't get me wrong, but from my point of view, you are essentially saying that Löve can't evolve in a direction you don't want it to evolve, because you use it in a certain way.

    If we are quoting taglines here then, I want to quote Löve's tagline: It's a "[...] framework you can use to make 2D games in Lua". GUIs are an integral part of fully featured games, and one Löve doesn't provide a solution for. This led to the repitition and heterogeneous landscape that we find, when we're looking for a GUI solution for Löve. Grid, after all, is just one more repitition of that same problem.

    From my point of view, it would be a good idea to solve that problem once and for all. That doesn't require anyone necessarily to use the "gui module". You could still roll your own, if you are not satisfied with what the Löve nuklear integration offers you, but at least it's an solution for people who want to make 2D games.

    In conclusion I don't disagree with you, when you say it's only a framwork, but I would count a basic gui solution to the basics of a game framework, not the higher level problems like pathfinding, entities and client server architecture.

  4. Andrew McWatters

    Well, yes, that's absolutely what I'm saying. People invest time in technologies, and when they uproot their foundations, it affects those who relied on it being what it used to be. Imagine if SDL became a game engine instead of a library to handle window creation and cross-platform issues.

    What about XNA? That provided similar callback handlers back in its heyday, why not a GUI layer as well?

    It's a shame LÖVE has this nice ecosystem, but no one has created a good enough GUI library for people to use. Maybe tackle this issue yourself, or contribute to one of the implementations available.

    But to suggest an immediate mode GUI library as something to include by default? Are you asking for low FPS? I don't understand how a GUI system that isn't utilizing invalidation or canvases or anything to that effect as being suitable for the go to solution.

  5. Landon Manning reporter

    What? LOVE is not SDL, don't be silly. That's a very poor comparison. No one is asking for LOVE to become a fully fledged engine. a GUI is a very important part of all games and is something LOVE is severely lacking. As I said in my OP, many people have tried, and failed (including myself) to make a GUI module for LOVE. GUIs are hard. nuklear is very light weight, very robust, and would be great as a default option. But like every other module in LOVE, you can simply switch it off in conf.lua and never have to use it.

    Also, immediate mode GUIs are not inherently bad at performance. Why not give love-nuklear a spin and see how it functions for you? The fact that it's so light weight yet so completely customizable is nothing short of impressive.

    Edit: That love-panel lib you pointed out has some very bad design practices. Mainly that it infects a project with globals.

    Edit2: Oh my god, that love-panel thing, the more I look at it, makes me cringe. Not only does it infect global state, it actively monkey patches both love and lua. That's really bad. I would never use that library.

  6. Andrew McWatters

    Also, immediate mode GUIs are not inherently bad at performance.

    Yes, they are. I've built an entire engine that's virtually the size of LÖVE itself and found that we couldn't use LoveFrames because the author didn't use optimized mouseover algorithms nor invalidation techniques to cut back on draw time. So we built our own subsystem that allowed us to develop more advanced usage. Vibrancy, and frames in worldspace were also goals and no one else had them but us.

    Mainly that it infects a project with globals.

    You use a framework built on Lua 5.1, get over it. We also patch LÖVE and Lua to add additional features that provide powerful constructs to developers. These come from https://github.com/Planimeter/lauxlib, https://github.com/Planimeter/love-package, https://github.com/Planimeter/love-conf, and https://github.com/Planimeter/love-graphics

  7. Alex Szpakowski

    I strongly recommend not monkey-patching love like that. It makes any change in love's APIs drastically more likely to break more code than it would otherwise, if that code uses your library.

    Keep in mind that an "immediate-mode GUI API" doesn't mean that batching and culling optimizations aren't possible, it just means the external API doesn't surface them.

    If love were to get a built-in UI API, it would not require you to throw away your existing work since love.graphics isn't going away. (This isn't a statement about whether a UI API will or will not be included in love, though.)

  8. Landon Manning reporter

    loveframes is garbage, even the author admits that. loveframes is also not an immediate mode framework, so I don't see what your point here is.

    Just because you write some code, doesn't mean it is good. Infecting global state is considered very bad practice in general, not just in Lua. Monkey patching is also considered to be a questionable practice. Predictability is very important for a codebase, and when one developer decides to break that predictability with their own code, it can cause a lot of havoc. This is why encapsulation can be a great thing: each bit of code runs in its own little sandbox.

    An example: What if you decided to add a global string.split function to your module that took two arguments: string and delimiter. But another module also creates its own string.split that take sin delimiter and string. One of them is going to overwrite the other, and the overwritten module is going to break. However, if each module creates its own local string_split function, they can be used internally without affecting each other.

    Edit: Your UI doesn't exactly look complex. It looks nice for sure, but I would hardly call it complex.

  9. Andrew McWatters

    I strongly recommend not monkey-patching love like that.

    I don't like monkey-patching things if I don't need to, but I can't think of a solution for most of the problems solved by these libraries that doesn't involve much more code and maintenance. At some point, you have to give up some ideological pureness for practical implementations.

    Keep in mind that an "immediate-mode GUI API" doesn't mean that batching and culling optimizations aren't possible, it just means the external API doesn't surface them.

    It certainly also means a lot of involved work to implement these basics. If the community couldn't write a GUI library, it sure isn't going to do these things, either.

  10. Andrew McWatters

    An example: What if you decided to add a global string.split function to your module that took two arguments: string and delimiter. But another module also creates its own string.split that take sin delimiter and string. One of them is going to overwrite the other, and the overwritten module is going to break. However, if each module creates its own local string_split function, they can be used internally without affecting each other.

    When someone uses my engine, they subscribe to my architecture. If you're developing against my codebase, and there's already a util function that exists with a name you wanted, pick another name. This argument is used consistently by developers, but when it comes down to a large platform you're using, it's all thrown out the window. If you're an individual library author, sure, don't do it. If you're a platform architect, who cares?

  11. Landon Manning reporter

    Because the community couldn't create a solid GUI library is precisely why I suggest we include one natively. GUIs are generally very important for most games, and have an out of the box solution would be a huge improvement to love as a framework. If you don't want to use the built-in, you don't have to. Just like many people turn off love.physics and instead use bump.lua, you too could turn off love.gui and roll your own.

    Not to mention nuklear is written in C89 with zero dependancies, it's just plain fast.

  12. Landon Manning reporter

    When someone uses my engine, they subscribe to my architecture. If you're developing against my codebase, and there's already a util function that exists with a name you wanted, pick another name. This argument is used consistently by developers, but when it comes down to a large platform you're using, it's all thrown out the window. If you're an individual library author, sure, don't do it. If you're a platform architect, who cares?

    That is an extremely poor attitude to have. Why should your module take presidence over any other module? If I included love-panel in my project, why should I be forced to remove other modules I need because your module is so selfish?

  13. Gabe Stilez

    I'd also mention that just like the default font included with Löve (which is small, and iirc lacks CJK), it's there so the framework can (mostly) function in that regard, having a font to print out text; if i want CJK or a fixed-width font, i'll have to include it myself.

    Also, nuklear wouldn't be a GUI that one would end up using in a release build, but to start out with, and experiment; it might just be worth it, not to mention the fact that it's one header file.

    Landon Manning He made an engine, you probably wouldn't just include it in your project anyway.

  14. Andrew McWatters

    Well, you're free to use a solution that while drawing the UI alone, you can't get a solid 60 FPS when fullscreened, or you can use my team's.

    Not to mention nuklear is written in C89 with zero dependancies[sic], it's just plain fast.

    I have a feeling pure Lua is faster when using LuaJIT.

    Just like many people turn off love.physics and instead use bump.lua, you too could turn off love.gui and roll your own.

    Nice, lets keep adding to LÖVE until a majority of the binary size isn't actually used by most developers using the framework. 👌

  15. Landon Manning reporter

    Pure Lua is NOT faster with LuaJIT. In an apples-to-apples comparison, C is going to be faster almost all of the time.

    I suspect the vast majority of people would use the built-in GUI module, especially if it is nuklear, because it is actually good. Some people opting for their own is no reason to not include something for everyone else.

  16. Andrew McWatters

    There is overhead in calling from Lua -> C -> Lua, that many times LuaJIT does not have when running equivalent functionality, or using FFI. C isn't faster almost all of the time, and it's why some authors choose to use FFI over the Lua C API.

  17. Andrew McWatters

    Except immediate mode GUI is shit, and I don't know a single professional designer who would advise using it over a traditional stateful UI subsystem. If you implement any optimization techniques, guess what, you need state anyway.

  18. Landon Manning reporter

    I am well aware of the overhead. That doesn't mean LuaJIT is magically faster than C. While it may be able to contend in some cases, C is almost always going to come out on top.

  19. Landon Manning reporter

    It is also worth noting that LOVE officially supports platforms where JIT is not available (iOS, for example). Creating a cross platform game with mobile in mind is immediately going to cause you performance problems. You simply cannot rely on JIT when using LOVE in every case, so having a native gui module over a Lua module is going to be just that much faster.

    And again, nuklear is completely fine. Immediate mode GUIs aren't inherently bad or even slow. For the vast majority of games that would be built in love, it is a perfectly acceptable and performant solution. I suspect it would even be fine for a menu-heavy RPG. If for whatever reason nuklear just wasn't working out for you, you could simply not use it. It's a single header file that compiles to about 200kb. If you were so worried about raw binary size, you could even compile your own binary when you release your game.

    Not including a gui module in love simply because some people wouldn't use it, especially when gui's are about the number one pain point that crop up on the forums, is extremely short-sighted and selfish.

  20. Andrew McWatters

    No, it's a blatant disregard for developer well-being by spreading shitty design on a bunch of hobbyists who can already barely code as it is, and influencing the proliferation of shit. Good job if this gets through.

  21. Andrew McWatters

    Yeah, I'm the one spreading bad design, that's for sure. Come back and tell me that when you've designed and written some actual comprehensive layouts. And when you do, let me know if you do it without state. 🙄

    I recommend we add no module, which would require even less state, and no globals! It's so pure of a solution, there's no locals, either. 😉

  22. Landon Manning reporter

    I was more pointing out the whole "hobbyists who can already barely code as it is" bit in your statement. But yeah, also the proliferation of bad design is definitely something you seem to be doing.

  23. Aatu Hieta

    I seriously don't think this is the place to get your fix of EgoBoost, mr "Award winning developer" (funny how you listed that on your resume, but not a single award...). I see that you argue about love-nuklear adding to binary size, and not justifying said addition by being unused, which is funny, because we already have things like love.physics, which are widely unused, yet you don't seem to care about their existence.

    I personally think we need a solid, yet minimal(*) native GUI lib for löve. This would make development a lot easier, as people wouldn't have to care about choosing a GUI lib (which is pretty common topic. And as other löve features, these are optional, and can be disabled, and you can compile your own binary without it.

    But I understand your point. I know why you are saying what you are saying. You feel threatened. You fear that people will stop using your shitty excuse-of-an-engine if love gets native GUI. You feel threatened, so you go running your mouth, spouting nonsense. Someone points your (horrible, if I may add) coding practices. I didn't know this was possible, but you get even more defensive. You begin quoting your own "award winning" work, while sadly, the code is out there, for all of us to see. Btw, did you know that the usage of module() is considered bad practice?

    I suggest you remove your egoist nonsense, and let grown-ups discuss good design, as you clearly have no valuable input to this matter.

    EDIT: I tried to make footnotes, but I failed. Anyway, nuklear is small AF

  24. Andrew McWatters

    "excuse-of-an-engine", reading my resume, monkey-patching (Landon works on a project which uses monkey-patching as a prominent feature), egoist, grown-ups

    lots of highlights here and big talk for a guy who looks like he's twelve

  25. Landon Manning reporter

    love is self-contained in a single namespace. there are some cases where you need globals, love being one of them. Throwing globals all over the place when you don't need to is very, very poor code design.

    In my game code, I tend to have about 4 or 5 globals: love, gamestate, signals, preferences, and some flags. Now, preferences and flags don't need to be global, but they are self-contained tables that do not affect any other part of my code and it is very useful to be able to query _G.PREFERENCES to grab sfx volume, for instance. Gamestate is used as a callback instance mechanism and it needs to be controlled on a global level. love also has this attribute where it needs to carry state with it regardless of where you are using it.

    Globals themselves are not explicitly bad, it's the rampant disregard for designing your code that is abhorrent. If you feel like you need to use globals to get a job done, you can almost always redesign your code to not require them. Same with monkey patching. It looks like your monkey patchig mostly adds caching to love. There is a self-contained module that already does that and does not require any patches to any monkeys. https://github.com/airstruck/knife/blob/master/knife/memoize.lua

    Landon works on a project which uses monkey-patching as a prominent feature

    No I don't? If you are referring to LOVE3D, the monkey-patching is an optional flag and was since removed (maybe not upstream) because it was awful and didn't even work well.

  26. Aatu Hieta

    "linking me to a article on lua-users, which answers the question I asked, isn't answering the question I asked". Cool beans bro.

    How about this. You quit using löve. You get your toxic, egoistic, uneducated ass out of this community. We don't need you. We don't want you. Feel free to rewrite your engine with something else. I think C++ would be perfect for you, just don't use anything too new :)

    As for your listed "highlights", I don't get what you mean? No one is perfect, I know, but at least I stand by my words, and don't outright lie. You are clearly egoist (you lie to make yourself look better, which is not cool), and you are certainly not grown-up. You have brought next to none to this conversation about löve, yet about half of the text here is written by you.

    This is not your personal playground, we are not your personal army. We are here to discuss future of löve, and you are not contributing. Please, leave.

    EDIT: About reading your resume, yes, I did. You yourself quoted your work, so I had to check it out. I wish I hadn't.

  27. Alex Szpakowski

    Hi all. Please chill – this issue tracker is about LÖVE's code and APIs, and this specific issue is about whether nuklear could be included in LÖVE. It is not for promoting or discussing other people's APIs built using LÖVE or otherwise, or anything that does not directly pertain to LÖVE's own code and APIs.


    love is a global largely for legacy reasons. In 0.11.0, the third party modules included with LÖVE (enet, luasocket) will no longer export themselves as globals automatically when you require them.

  28. Nicola Orlando

    If I may at least try to get this back on topic, I think adding a GUI to LÖVE would only be beneficial, having tried to code one myself as well, and I really don't think your reasons for not adding one are really valid - just don't use it. If you're concerned about binary size, build LÖVE on your own without the extra module[s], especially since you have to build it anyway for the only platforms where size matters if I recall correctly (although 200KB is pretty much nil).

  29. Landon Manning reporter

    fwiw, I have 500 nuklear panels open right now running at 60fps (vsynced). Bumping up to 1000 drops me to 47fps. Seems performant enough.

    throwing several ui elements inside each window (500 windows) brings me to 25fps.

    50 windows with some ui elements gets me back up to 60fps (vsynced).

  30. lai weichih

    I think spending 200kb for making gui design easier is quite fair, especially for games in beta version. Changing gui design already kill me inside, I do not to worry about choosing gui library any more. Besides, we will manually optimize ui before release anyway. To start out and experiment with gui is matter.

    Edit: For one worry about binary bloat as me, comment unused module and re-compile love for release version could be helpful.

  31. Jan Werder

    To even the odds: One thing I found irretating is that the state of nuklear in its current form seems to be kind of final (https://github.com/vurtun/nuklear/issues/157) This is a shame, because in the case that our needs expand, it seems unlikely that the base nuklear is going to cover it, which might lead to a Löve specific fork. All in theory of course and I'm still for an inclusion, but I just wanted to throw that out there.

  32. Landon Manning reporter

    What are some things that nuklear is currently missing that may seem beneficial in the future? nuklear definitely has all the basics that the vast majority of lovers would be likely to use, so I wouldn't want to write it off because it doesn't include some obscure widget that, like, 5 people maybe really be interested in.

  33. Jan Werder

    My point isn't to write it off, because it doesn't have feature X, but that it might be hard to get feature X, IF we ever think we need it. For examples on what might be missing at the moment, the author himself names a few: "[...] not because there are no more things to fix (like better graph support) or add (tables, shortcuts, docking, more widgets, ...) "

  34. Landon Manning reporter

    It's something to consider. I definitely think that what nuklear currently offers is very close to what most lovers need. It's got your buttons, your labels, sliders, etc. Nearly every GUI that's popped up in the love community over the years generally only supplied those basic widgets. One of the biggest issues (besides performance and stability) has been stylability, and nuklear also provides a pretty decent theming/styling system.

  35. Jan Werder

    Sure, and if you wanted to extend nuklear for table capability (i.e.), you could always just spawn an empty nuklear window and do the rest yourself with Löve. The only thing we wouldn't be able to extend or improve are the built-in things, like graph handling, docking and so on. Still this would be a pretty solid solution though.

  36. Landon Manning reporter

    Yeah, there's nothing stopping a lover from making an in-love widget. And there's nothing really stopping love devs from patching the nuklear module (and even sending up stream) if it is deemed necessary.

  37. lai weichih

    I don't want to have to maintain a dependency.

    I totally understand that maintain extra dependency is no use. But if we do not use other gui lubrary( nuklear, or even imgui ), will Löve has it own build-in gui module?

  38. Landon Manning reporter

    nuklear is still in active development. New features may not be common but bug fixes seem pretty constant and reliable. I don't think we would need to maintain nuklear.

  39. Log in to comment