Being burned out on this project means this post is pretty spruceless. Sorry in advance!

Finished-ish

So it's practically the end of the month hello! It's been fun to dive into a really large-scale project like this for the first time in a while.

Here's the result so far: (it's a video)

It's basic and doesn't look much but it does the things I want it to do!

• Loading and saving a special .lumi filetype.
• Editing those files to do different stuff.
• Running the game straight from the editor!

From here on out it's really just grunt work to add more Lua hooks in the engine, push more editor features and generally make things look prettier BUT I AM SO BURNED OUT. I did some not-good-praxis when working on this generally working in huge 10-hour sprints, sleeping then dreading the idea of the next big 10-hour sprint.

(To bolster how not-good this is Stefan Mischook sensei recommends to work shorter amounts of time when doing studies. Like "45mins/1h a day" shorter.)

So I've dropped it for now and I felt pretty awful about it until my friend Josh told me (and I'm paraphrasing like crazy):

It depends on if its a personal learning exercise or if it's something you seriously want people to use. If you started it to improve yourself once you learn what you set out to learn move onto something else.

Thank you Josh ily.

Design Flaws

You know the tab system? It was awesome until I had to stop and think of where to put everything pertaining to sprites. I checked GMS for >inspiration and a pretty solid argument for using windows over tabs sprung up.

Notice what happened? This is a very good method of abstraction. Users traverse through a tree-like-structure of editors and sub-editors. Start at the root (Sprite Properties editor) you can branch off into hitbox editing (Modify Mask) or subimage management (Edit Sprite) and so on.

This wouldn't work with a tab system where concerns are completely separated like a list of single nodes where each of them can be modified in isolation. Game assets do not lend themselves to this idea. They're much much too complicated. You realize that it's not a list but a list of lists (which themselves contain lists (which might also have a list)). There's a LOT of nested abstraction because games are complicated and concerning yourself with everything about a particular asset at once is overwhelming.

So do tabs suck? We chose them for a few pretty good reasons. There's always a solution without completely scrapping the idea, and while windows still seem like too much to me, GameMaker Studio 2 puts forward a pretty great solution:

It's just like the window system but the window's parent and branching abstraction is much more explicit. Coupled with it's own tab system you can see us and the creators had similar ideas regarding tabs and ran into the exact same roadblock.

But this doesn't really fix our "there's too mdany got ddang windoes" problem, so as an alternative (knowing the limits of what I can do with GUIs so far) I'd probably opt for a nested tab system like we had in the room editor:

As for other UX flaws, there's already a lotta text here so I'll save the discussion on other much more complicated problems. Maybe another time!

What I Learned

This was a surprisingly good practice in gang-of-four-style design patterns considering it was a GUI framework study. There's a pretty huge problem to solve when you're working with GUIs for example consider your main window has an instance of a class that manages a certain part of your GUI but those GUI components are only accessible from your main window.

It might be obvious how to solve this at first such as subclass dependency injection but making it as maintainable as possible was my top priority so injections-in-injections seemed like something to avoid. This lead me to find out about a few patterns such as the Singleton pattern and before I say anything else oh my god don't use this pattern.

My main window UI was only going to have one instance and I need access to it from a lot of places right? A singleton pattern makes too much sense! Where's the problem?

The problem: it was used in a lot of places. Many different subclasses modified a single part of the GUI which even if you're OK with violating the Single Responsibility Principle (for the sake of prototyping I swear) is something who's effects become more apparent only when you're in the thick of it. Common behavior kept being re-implemented and things got inconsistent.

In short, in comes the Facade pattern :tada: wherein this facade is an ultra-simple toolkit to do anything you need with GUI elements. This is created by the main window (where it's given access to certain UI components with limited functionality) and is what gets passed into these subclasses.

A bunch of other stuff was experimented with but I'm overstaying my welcome with this post enough already.

Future plans

I think I'm just going to stick with Löve2D for my game projects ahaha. The things I've learned here may or may not lead to a nice level editor, but for sure it'll be a great boon for my future code's architecture.

Thanks for reading this BIG update.

:fire: