Advice on making a level editor

[Germanunkol]

Yes and Yes, though I would never recommend this, since this only work with not packaged games.

Ah, I didn't think of that.
You can still use this method and alter the path (and move the main file) when you release it, I guess.
Or you can use https://love2d.org/wiki/love.filesystem.isFused to check if the game's in fused mode, and if so, use a different include path, but you'd still have to manually move the main file outside before fusing...

[Lugen]

Have you tried this solution:

Main file only chooses between running the game or the editor. You could even use a command-line switch for this (which would also work with .bat files, for example).
When, in the end, you want to distribute an .exe, you can simply change the main file to only load the game, then build your game.exe and then change it to only load the editor and build the editor.exe from it.

Code: Select all

--This will be your main.lua file
local released = false --Set to true when you release your game
local editor = false --Set to true if you wanna force the editor mode
love.load = function (args)
    for _, arg in ipairs(args) do
        if arg == "-editor" and not released then
            editor = true
        end
    end
    if editor then
        require "editor.lua" --Your editor "main.lua"
    else
        require "game.lua" --Your game "main.lua"
    end
    love.load(args)
end

Run from the console like:

Code: Select all

love path/to/the/game/folder -editor

Or put that in a .bat file and run it

Interesting. Didn't know love.load() took arguments from command-line, that's quite convenient. Heck that could be used for a lot of things. Haven't tried anything yet as I'm weighing my options but so far I'm leaning towards this one. Still thinking about the specifics of the editor itself and if I'm ready to have a go at it.

[Lugen]

Just replying to show the help I received was here was useful. Been working on this for a while now. The solution I went for was to have the game and editor as different branches inside the project and have command-line option determine which branch to load along with all the core stuff.

Still a mess but usable except I haven't got saving/loading to work yet and it's stalling me at the moment unfortunately. The issue being some of the objects points to userdata(art-assets, shaders etc) and I need to find a way to define this through text/lua-code so that the pointer is recreated when loading. The level will be written down as a lua table.

[Jasoco]

Creating an editor for your game is usually harder than creating the engine itself.

Screen Shot 2015-06-15 at 10.22.54 PM.png (108.13 KiB) Viewed 4099 times

But it's usually the most fun. And frustrating.

[Lugen]

Creating an editor for your game is usually harder than creating the engine itself.

But it's usually the most fun. And frustrating.

Indeed, additionally to make certain things work out I had to go back and make improvements/fixes on the "engine" itself which is quite satisfying. Seems like an editor is good trial of how versatile the base system is.

[Lugen]

Still stuck on the issue of saving levels, or rather coming up with ways to address userdata.

For instance, objects with a draw component have a field that point towards an art asset which by default is listed in my asset manager (or rather asset lister/loader at the moment). Since its userdata there seem to be no way of telling its source, like a file name or something that could be written down to the level-file (which is a lua table) so that when the object is recreated on loading it can find the assets it was using as well.
Most of the time the userdata is a mesh.

I was first thinking of storing the userdata in some kind of asset table containing additional information like name and stuff but I haven't figured out a solution that wouldn't overcomplicate using the asset during runtime.

Anyone had any similar experience, made some kind of asset system or perhaps knows some lua/love trick I'm not aware of?
Any ideas are welcome.

[s-ol]

Still stuck on the issue of saving levels, or rather coming up with ways to address userdata.

For instance, objects with a draw component have a field that point towards an art asset which by default is listed in my asset manager (or rather asset lister/loader at the moment). Since its userdata there seem to be no way of telling its source, like a file name or something that could be written down to the level-file (which is a lua table) so that when the object is recreated on loading it can find the assets it was using as well.
Most of the time the userdata is a mesh.

I was first thinking of storing the userdata in some kind of asset table containing additional information like name and stuff but I haven't figured out a solution that would overcomplicate using the asset during runtime.

Anyone had any similar experience, made some kind of asset system or perhaps knows some lua/love trick I'm not aware of?
Any ideas are welcome.

I would probably save all the "metadata" in an external table, indexed over the userdatas:

Code: Select all

metadata = {}
-- in your asset loading code
function loadImage(src)
  local img = love.graphics.newImage(src)
  metadata[img] = {type="image", src="src"}
end

then you can replace all userdata with the data in metadata on save. Of course it's more complicated for meshes, you would need to export them as lua code again.

To make things nicer to handle you might also build lua "object" wrappers around the userdata. These could implement an interface ":serialize()" that retuns lua code that reproduces them. If you implement all the original features (like ":setFilter" for example) and store the values, you can't forget to save those changes too.

[Lugen]

I would probably save all the "metadata" in an external table, indexed over the userdatas:

Code: Select all

metadata = {}
-- in your asset loading code
function loadImage(src)
  local img = love.graphics.newImage(src)
  metadata[img] = {type="image", src="src"}
end

then you can replace all userdata with the data in metadata on save. Of course it's more complicated for meshes, you would need to export them as lua code again.

To make things nicer to handle you might also build lua "object" wrappers around the userdata. These could implement an interface ":serialize()" that retuns lua code that reproduces them. If you implement all the original features (like ":setFilter" for example) and store the values, you can't forget to save those changes too.

Heading towards something similar. Interesting suggestions about the functions. Thanks.
My assets will probably be based around their function (props, animations etc) rather than data-type. Probably won't make any difference in implementation. Just mentioning for interest.

EDIT: Looked again at your example code and realized "img" is both userdata and a table key. Can you actually use that as a field?

[s-ol]

EDIT: Looked again at your example code and realized "img" is both userdata and a table key. Can you actually use that as a field?

If I understand your question correctly, yes, you can use userdata as table keys.

[Lugen]

EDIT: Looked again at your example code and realized "img" is both userdata and a table key. Can you actually use that as a field?

If I understand your question correctly, yes, you can use userdata as table keys.

I had no idea. That's really interesting.