sandsmas - A LÖVE Editor

[EntranceJew]

sandsmas
A strange name for a strange tool. It's meant to be a visual editor for LÖVE, written to run inside LÖVE, that runs regular LÖVE games.


click for gif

Features

• Written for LÖVE, so it runs from your favorite editor.
• Runs regular LÖVE games inside the editor by wrapping them with a library written for this purpose, named projector.
• Game instances run in a sandbox with the default references to love callbacks removed.
• Runs in a single thread. Traces from the game will bubble through the editor. Permits the use of threads in games as usual.
• Shares its instance of love with games, no canvas switches.
• Exposes sandsmas to the game scope, so games can utilize editor features.
• Has a console component, a basic object registration system, and a basic type-guessing inspector view.

More info is available on the github repo. I was experimenting with this over the last week and I just wanted to show this around a little. The goal is to have an editor that anyone could possibly integrate into their game without too many opinions being imposed by the editor. One feature that I don't particularly plan on supporting is text editing for source files, because the power of a lua-only editor is being able to use our existing tools.

[Ulydev]

Can't wait to try this out!

[airstruck]

Looks pretty cool! Going to have a closer look later, have been thinking about how something like this would look lately, curious how you handled some things.

[AntonioModer]

EntranceJew, keep going please, don't stop, awesome !!!

[EntranceJew]

In today's update:

• A really basic type guesser via a sequence of checker functions.
• Editing a value in the inspector now edits the value in the execution live.
• Registering your own type UI via a lookup for typename against a function table.
• A hierarchy view, which represents objects that have explicitly stated their relationship with their parent.
• The ability to control what is visible in the inspector via manipulating what is selected in the hierarchy.
• The ability to open and close items in the hierarchy view.

Clicking on the yellow square changes the UI mode, ordinarily color4 renders as 4 separate rgba values.


Having things open in the hierarchy view makes them visible in the inspector, which you can then open/close whenever you want.


CTRL+Click will allow you to select multiple items in the hierarchy.

Looks pretty cool! Going to have a closer look later, have been thinking about how something like this would look lately, curious how you handled some things.

Chances are, the sandbox is leaking in one way or another. I know for certain I still haven't:

• Completely isolated package.*
• Allowed for restarting game execution. Should be as simple as destroying and reloading a sandbox, but properly releasing memory / threads will complicate this.
• Utilized a game's own love.run (initial thought: run as thread, but then architecture shifts greatly)
• Emulated love.window.* behavior, or respecting the conf.lua for a project.
• Emulated love.keyboard.isDown via the state of signals sent via keyboard callbacks being passed through. Currently this only looks like it is functioning due to focus emulation.
• Allowed for pausing the draw/preview, right now live editing hinges on the game constantly rendering itself.

The most important component for rendering a love window (or anything that might naturally happen in a love.draw()) is the UIHelper's PostRender stack that takes the position / size of an active imgui panel and draws there later. This does not yet handle partial obstructions, like being inside a scroll-able view. (This will be necessary for utilizing love's text objects and per-character colorization.)

The single most important part of this, from the beginning, is the utilization of UIDs to allow for really weak references to objects without trapping more than a single direct reference to them in memory. It will also allow for a lot of the structure to be imposed without embedding elements or expecting keys everywhere. The only two magic keys are "id" and "name" on any object, but even those could be lifted away.

[Fenrir]

Impressive usage of imgui, good luck with this project!
If you don't mind I'll add it to the example galery on the imgui post.

[EntranceJew]

Impressive usage of imgui, good luck with this project!
If you don't mind I'll add it to the example galery on the imgui post.

Go for it, more eyes helps me.

Today's update:

The default inspector iterates over objects and runs many type check callbacks against them. Here we wrote our own "type" by providing a checker and a custom GUI.

• A component is defined as a property or table on a registered object.
• sandsmas.imgui is now exposed for the sake of sharing editor state and preventing any side effects of having a project include imgui itself.
• You can manually register inspector types and GUI functions that control saving and loading of values.
• A valid TypeIdentifier callback takes a type and returns true if the table matches the given type. Depending on how you do this, you only have to do this once.
• A valid TypeGUI callback takes a type and draws each of its values, detecting changes in the constituent members, and returning a true/false if our values changed coupled with an instance of the object to assign to the member.

In the above examples, we save the data manually to our component within the TypeGUI callback and simply return a reference to the existing class, as it is already the latest value that should be assigned. If TypeGUI returns 3 or more arguments, a table containing all arguments after the first will be assigned to the property instead of just assigning the second value.

In the future, I am thinking of having:

• Manual registration of components, treating them like objects, stored by type. This will allow for use of UIDs as weak references to component tables to allow for interoperability between components / garbage prevention. Different component implementations could serve the same purpose as long as their methods are similarly named.
• Having a register-able widget method to allow interaction with objects and components within the game world. Since this requires dealing with many love callbacks at once I need to consider how this should be done.
• A standard recursive table inspector, reducing the necessity to write one's own inspector for simple data components that utilize known type.
• A generic collapse-able heading for the inspector components. For big data.

I am really looking for feedback on today's update and what I am thinking of doing in it's place, as I'm starting to really shape the use cases and example code necessary to make something tick.

[EntranceJew]

Today's update:

Projection now emulates mouse focus and window focus better. This effectively lets us treat the imgui window like our regular game. The game code uses normal love callbacks, acting like normal.

• Documents are available at https://entrancejew.github.io/sandsmas/.
• Documentation now inlined in RTFM docblocks and generated with a script in ./tools/generate_docs.sh.
• FakeLove now contains mouse variables, Projector now properly fakes mouse status.
• Fixed some submodules and typos thanks to videah and TsT.
• Removed errors being raised by using imgui.BeginMenuBar() on linux and not on windows. (Not sure why they wouldn't raise on windows / from within my ZeroBrane instance.)

If you're looking to extend or contribute, keep in mind:

• Documentation appreciated. Especially prettying up the index.
• FakeLove is meant to simply be a container for love data and callbacks.
• Projector contains all the complicated logic that helps maintain the love state using love callbacks.
• An instance of FakeLove has a .store table, containing tables that should reflect data stored by those love modules.
• Even with Projector, you will need to manage some of your emulated window state in the implementation in order to prevent an immediate dependency on imgui.

[Viomi]

I'm in LÖVE...

Please keep this up! You should throw up your bitcoin address or something similar so people can throw donations at you. Finally having a way to allow my team members to contribute to the creation of the game without being programmers is super awesome!

This totally has my approval.

However, I have a couple things to complain about:

• imgui.dll is included in your github, rather than a submodule of imgui. The result is that someone building on linux (such as myself) must go and manually build imgui separately and then manually put imgui.so in there, and remove imgui.dll
• love main.lua throws an error how it doesn't see imgui.dll or imgui.so (depending on what os you're building on). Apparently it's looking for imgui.so / imgui.dll a folder above wherever you run it; So you must make everything except imgui into a .love package and then run it.

[Positive07]

love main.lua throws an error how it doesn't see imgui.dll or imgui.so (depending on what os you're building on). Apparently it's looking for imgui.so / imgui.dll a folder above wherever you run it; So you must make everything except imgui into a .love package and then run it.

LÖVE (nor any other program) can't access dll (so) files inside a zip (love) file, they must be next to the executable or someplace LÖVE can search for it like the save folder when running in fused mode.