Love Editor

[yintercept]

After realizing I needed more versatile tools, I left for a while to learn web development.

I'd be happy to hear from you all about what I've missed, new games made with Love, and other news.

Now that I got some initial skills under my belt I want to talk about what I'm working on:

Game development, at least for beginners and hobbyists is pretty limited: You have GM, which is proprietary
(not a bad thing if you want regular support!) but also has periodic online-only check-ins and is owned by a foreign company that could
shut off the spigot one day without cause or reason.
You have Unity, which has a whole lot of baggage attached to it, more oriented towards 3d games, and thus has a lot more fragmented
support in tooling and thus a lot more overhead.
And then theres a smattering of others tools out there, but really those are the two big ones in 2d development, the C# ecosystem and GM.

Now, what took ages in C# and unity (because they're more framework and tooling than proper editors) was about ten times faster in GM, and for a while I could be satisfied with that. Problems with GM is it's marketplace for additional tooling is fragmented, anemic, and will always just fall short. Worse, it feels...unprofessional. Thats a horrible and old complaint coming from a guy using GM, least of all when so many polished games have come out of that toolset. I'd be embarrassed to pitch to a publisher though when anything I made had the attached logos and branding of GM.

Then I found Love2d and what took four months to make in GM, took under two weeks in moonscript and L2D.

I was blown away. But some things were missing, namely asset browsers, object editors, and editors in general. Building these in L2D was, to say the least, a pain in the ***. Virtual sandboxes will do that to you. I understand the reasoning why, and undoubtedly it was necessary, but I needed more.

And so I left, learned some other things, and came back, and now here I am.

So then, what have I been up to?

Mostly learning html, js, and css. I picked up nw.js along the way (lighter and saner than electron).

My goal is to build a set of editors for Love2D, with support for moonscript, lua, and javascript (exporting to phaser2d).
It's less about supporting the community, as meeting my own development needs, but I want to put it out there. Maybe far down the line there will be some optional patreon support, but the money would primarily go to Love2D, phaser, and others for bounties and supporting continuing development.

I wrote an overview or draft of what I'm thinking its posted below.

OVERVIEW
You don't need a 'game engine'.
What you need are tools that work together and speed up
your process.

Things like a level/scene editor so you can layout your
levels and GUI and see it visually as you edit, set
object transparencies, set starting scripts, the works.


Scene/level editor
Object editor as well as instance editor.

Asset browser.


Level editor, as well as main editor, should let you hit a single
button to test, and/or non-debug playtest.

Json should be the export type, or bson, or something similar.
You should have a framework for deserializing json into game objects.

Thats it, everything else is cake built on top.

Maybe an easy configuration editor, for various settings based on say platform exported.


LEVEL EDITOR

Level editors probably need a few things, but minimum is
1. setting the tileset at the start
2. placing tiles
3. placing objects.
4. specifying a script or start/onready script to load at start.


If you want more and better, you're at least looking at
1. layers, layer names, transparency, blending, shaders/effects, color or tint, scroll amount/parallax, order, depth
(depth is loosely based on order)
2. tileset per layer
3. object instance prototypes per layer, instance custom data per layer
4. start script (or initialization/setup script), main script/events, possibly render script (comes as default).
In particular render scripts might come in various flavors to handle different types of level data.
You might want to render level data in chunks for example.
5. Map properties (name, map id, width, height, layers, starting object, 'global/default' map to start when
play begins, etc).


TILE/SPRITE EDITORS
Might include the basic ability to assign a tile name, tile 'data' (a string, like how stencyl does it), and collision group.
Later would be assigning collision *shapes*


COLLISION EDITOR
Collision editor would allow the creation of 1. new groups, 2. naming the group, 3. determining
what other groups it collides with.


ASSET MANAGER
At minimum it just shows you a list of known assets by type, and allows renaming them. Clicking on
an asset opens up the relevant editor, either an external one if specified, or an internal one
if available. Ideally you can create folders, and put files in them, and this will be mirrored
back to the folder structure externally, the one stored in the project. The project
should make copies of all files that are imported, to be stored and manipulated as relevant.


FRAMEWORKS
While ideally frameworks should be avoided, some default stuff might be useful so as not to
reinvent the wheel.
Namely saving/loading/data serialization, deserialization to some common object types, level loading,
basic tile rendering, basic depth rendering, basic whole screen effects (tint, flash, etc),
common things like tweening and cameras. Also a basic collision script.

Other stuff can be developed as you go along of course. More advanced stuff will naturally
follow from the tools developed. Advanced stuff might be particle effects, more advanced
lighting, path finding, state machines/fsms, behavior trees, dialogue systems/tree editors, etc.


ADVANCED EDITORS - Out there 'maybe' type stuff.


FSM, Behavior Tree, Dialogue System/Tree Editor, Path follow editor, Cutscene/Automation editor,
manual animation editor (think dope sheets). Particle effect editor.
Text/font layout editor (handles what example text will LOOK like in game, break points, wrapping, etc).
Collision shape/type/category editor. Song/music/effects editor (used for simple things
like arranging music, effects, environmental sounds, etc).

Todo list / Kanban list editor et al. Time tracker? (project management stuff)

Design Doc Manager

List to be expanded as I go along.



WHERE TO NOW

It will not be swift, but I'm at the point in my web development skills where I can reasonably say a lot of this
is possible or doable for me. So probably the first things on the list are going to be an asset manager and
a scene editor, and I'll release those as I develop them. I won't be taking feature requests per se, because
software development is notoriously unpredictable and I'm a commitment phobe
But I'll be keeping things people suggest in mind.

My bigger motive is just to demonstrate what I can do for future employers, and I'm not overly concerned
that being hired by someone will effect the time I have for development because I program for fun even
when I'm not programming for a living. (call me a shut in if you like, to each their own!)

Thats my plan anyway.

I'm open to suggestions, and input, though I know these forums can sometimes be slow and anemic sometimes.


OTHER EDITORS

As I was posting this I just noticed a couple other editors have already been released.
To the developers of those, rock on!
For others wondering, this is more of a personnel project, and I wanted to do it in something
accessible (nw.js, plain html5/css/js) so it would be 1. portable, 2. easy to modify for others, 3. easy to maintain and add to.
I don't really think C# fits that bill but then again I'm not a c# developer!

If you're one of the developers of those tools, I encourage you to continue doing what you do.

[ReFreezed]

There are several things here I disagree with, but I'll just say this: What you're describing is essentially Unity and it's "ecosystem". A big reason people like LÖVE is because it doesn't require, or encourage, all this extra baggage of integrated tools and editors. Or in other words, LÖVE doesn't have an opinion about how things should work or be, giving developers maximum freedom.

A lot of what you're saying does make sense on some level, but I don't think making a million general-purpose editors for others to use aligns with the philosophy of LÖVE (or Lua's, which is very similar). If you need a tool for a game you're making, just make that tool for that game.

(Also, as a side note, making tools that are actually useful to people is a lot of work and require lots of time - time that could be spent actually making games, which is what most people are here for anyway, right?)

(Also, don't take this the wrong way - it just seems our opinions are a bit different. You do what you want, of course!)

[yintercept]

Oh no worries, I'm actually a very abrasive person by nature so just tell it as it is.
I'm not much of a 'philosophical' kind of guy so excuse me if I run roughshod over any sacred cows lol.

In any case, like I wrote, it's primarily for my own usage but I'll share as it goes. I think just because people
use love because it is low level, it doesn't exclude the possibility that a lot of people would find additional
tooling a welcome change.

"If you need a tool for a game you're making, just make that tool for that game."
Actually thats exactly why, no use keeping it to myself though.

Btw your hot particle editor is cool af.

Also I'd like to know more about what you object to and why.

[zorg]

There is a curated awesome-love2d repo on github that already has libraries for most of the things you listed... then again, i too like to design my own stuff as well, so i can definitely get where you're coming from

[ReFreezed]

(Prepare for opinions and rambling!)

I'm not much of a 'philosophical' kind of guy (...)

I just mean that LÖVE is a small but powerful API that doesn't force you to do things in any specific way, and likewise, Lua is a small language with few but powerful features. I felt that the post was very "there should be a thing that does this, and one that does that, and one that does that other specific thing as well" which, if everyone had that mindset, would quickly create a messy/crowded environment and the smallness and simplicity of LÖVE/Lua would be lost and we'd suddenly be in Unity Asset Store Land™. It's just very different from what people have provided for LÖVE and Lua so far generally.

Now, to make a game you probably have an in-house suite of editors and tools during the development, which is fine. The question is if it would actually be beneficial for other developers to be exposed to that complexity, and whether the time spent making the tools public would be time well spent.

In any case, like I wrote, it's primarily for my own usage but I'll share as it goes. I think just because people use love because it is low level, it doesn't exclude the possibility that a lot of people would find additional tooling a welcome change.

I like that mentality, but I don't think it's enough. It's very popular nowadays to share code and software as open source, but the reality is that most freely available code and software is useless and/or poorly supported. I too, as one who develops general-purpose tools sometimes, do welcome new tools in general because I think it's interesting, but at the same time I want the existing stuff to be better, and just having *more* software that's not being serious about its usefulness to others is just going to pollute the environment (so to speak) and the actually useful software will just get more buried. You mention being a "commitment phobe" which I think is a part of an actual widespread problem in the whole code-sharing community.

So, more new stuff is good, but only if it's actually better than what we already have or if it solves a previously unsolved problem.

If you're just writing updates about what's happening and what you're learning as a blog then it's different (i.e. sharing acquired knowledge), but just blindly "throwing code out there" I think is a mistake.

All that said though, maybe what you make will actually be useful to others.

"If you need a tool for a game you're making, just make that tool for that game."
Actually thats exactly why, no use keeping it to myself though.

I don't think I was clear with what I meant. To iterate on the idea that there's "too much" publicly available code/software already, I would urge you and anyone else to at least think about how the thing that is being shared is useful to others, and maybe sometimes actively choose not to share it and just keep it private. (This is just me trying to keep the complexity of the world down - I'm not saying you shouldn't share what you're making if you actually think it's a good thing.)

Also I'd like to know more about what you object to and why.

I refrained from pointing out specific stuff because I don't think the comments/discussion would be that helpful. My reply was more of a reaction to the general mentality of the post and an attempt to get one to think again from a different perspective (i.e. think about why something should be done, but also think about why the same thing should not be done).

Btw your hot particle editor is cool af.

Thanks!

(I spent way too much time writing all this. )

[gilzoide]

I would say that for textual assets you are better off using any good code editor out there, like Sublime Text, Atom or Visual Studio Code, to name a few.

For asset browsing and project management, you can use your OS file browser to do everything you mentioned, even filtering by type using the file name or extension. They can even have the same format, so you can, for example, have several JSON encoded asset types but use the file extension to differentiate them, like my_level.level and my_tilemap.tilemap. You can then map these file extensions for your own editors in your file browser configuration. You could also use your code editor builtin file browser, if supported (most of them do).

While ideally frameworks should be avoided ...

I don't think you should avoid libraries/frameworks, just pick up the ones that fit your project. You actually can't have a level/tile/sprite/collision file output by your editor, but no way to actually load/use them in your game, so you'll need a library for that (well, unless your editor outputs Lua/Javascript code directly, but this is a far more complex and error prone solution). Ditto for having a debug/non-debug test button. Your tool will most likely be or have a library/framework counterpart.


After saying all of that, I would say that unless you really want to develop a code editor and asset browser, but rather just have a good one to use, I would advise to check out the great tools that are out there (as already pointed out, also check out the awesome-love2d repo) and focus on developing the original stuff, like your asset editors and runtime.
And finally, go for it!

[yintercept]

With all the complexity that goes around I can definitely understand
the wish to remain in simpler times. There is always, with new challenges,
the desire to simplify those. Actually the beauty of that, limitations, is
what lead to so many great games being released through things like Pico.
I think though, at some point, people who have good ideas but not a lot of
skill hit a ceiling, making, as you said, their own tools and editors to compensate.
And the problem with that is they started out wanting to make a game, not
tooling.

I think it's a fun and worthwhile exercise, making tools and editors, for
people who want to give back and enable that group.

In fact, I think theres a very good middle ground to be reached. Something
far below NPMs js-itis, and something above the current release rate.
All in all my gut tells me sharing is *usually* more beneficial than harmful.
So much so I encourage you to share what you've made!

We can all toil away like gnomes in underground burrows, making our own tooling
or editors, which is a great educational exercise, or we can share and get
on with the task of creating what we love.

> "So, more new stuff is good, but only if it's actually better"
I mostly agree that when someone releases something, it should generally actually be better
than whats available, except say for beginners showing what they've been working on but I digress.
I'm also not averse to competition, which has been an attitude I've seen fall away in the
software industry, the aversion to conflict, but all thats secondary. As much as many people
talk about sharing and cooperation I really don't think, even *today*, that there is enough
cooperation between people on shared interests.

On the specifics, what I'm going for is one overarching 'editor', just an 1. asset browser that
loads data, 2. and a configuration list that lets you choose external tooling to associate
with each asset, so existing editors and tooling can seamlessly interoperate and people can
switch out between defaults, non-love editors (e.x. audacity, pixel tools, etc), and
more game-specific editors made for love, or even build there own as some of us do.
Right now I have a project manager, and an asset browser, and I'm working on the tile map editor,
but actually I see no reason why there couldn't be links in the tooling to the homepage of
various editors such as yours, for people to choose from.

What do you think?


> I refrained from pointing out specific stuff because I don't think the comments/discussion would be that helpful.

I strongly disagree. I've found too many people shy away from "unproductive" discussions because
many assume it might become toxic. It really depends on the participants. I don't know if thats
the real reason or not and I'd much rather just hear what you have to say, especially considering
you already have substantial experience writing your own editors.


Edit: Thats actually what I've been doing for a while gilzoide! How did you read my mind?
I'm actually using a bunch of stuff from the love repo now. Would be useful to tie it all together.

[gilzoide]

Would be useful to tie it all together.

Well, it is a way of living.
I'm more fond of the UNIX philosophy where you "Write programs that do one thing and do it well" and "Write programs to work together".
I really don't see why have a separate asset/file browser if it doesn't do more than the one you already have installed in your OS (I'm assuming it doesn't, sorry if it is not the case). I would say the filesystem itself is how it is all tied together, so you can just worry about the rest, like building your objects and assembling your game.

If you are saying about tying the awesome-love2d libraries together, then you would have your own game engine/framework, or at least another library that integrates the more specific ones =P
And this is fine, if this helps you make good games ^^