Author
Topic: A Plugin-Based Level Editor (Read 1809 times)

Recently, I've been wanting to work on my level editor for the Zelda Oracles games, ZOLE, but because there's two versions of it, adding features is quite the pain. I've had an idea to create a new version of ZOLE that runs completely off of plugins, with some core stuff for showing the map and other additional information. That way, once I integrate the core for the other version, they both would use the same plugin (Plugins could be things like a chest editor, a text editor, or even something that launches a hex editor and automatically notes the changes). I would make the cores of each version override-able, so if someone wanted to, for example, hardcode sprite loading for certain interactions, they could. That said, anybody would be able to add something to the program and either keep it for themselves or share it. It's much more easily modified than just editing the source for ZOLE.

I want some feedback on this. My friend says it's quite useless, as nobody else would develop plugins but me, but I still see it as a big shortcut in the future and the idea just seems cool. What do you guys think?

What is the goal of the plugins? If others will really develop plugins, then it would be worth it. But it sounds like you expect the biggest benefit would be making things easier to program. There are other approaches you could use to make it simpler to manage multiple versions that don't require a plug-in architecture. And if you're the only one adding features, it seems like the effort would be better spent on new features than a plug-in system. Man I'm such a buzzkill.

Well, things would be easier to program, other people could develop plugins or change things they don't like, ZOLE would be neater, and all the other Zelda Oracles tools I've made would be inside ZOLE and wouldn't require reloading the ROM. At this point, I think I'll be making a new version of ZOLE from scratch and this is the system I want to implement.

Well, it looks like you want to do it regardless. That said, it is a good idea, at least. In any case, it gives other people a chance to make the editor better. At worst case, I've realized that our past selves, our present selves, and are future selves can behave differently, almost as if you have become a different person, so... it might be helpful if you end up picking this up after a long hiatus (although, that's what comments and proper code reuse methods are for, but whatever).

tl;dr: it's your project, your call.

Logged

Who will quote me next?Disclaimer: If it sounds wrong, I may have been posting while asleep.

I agree with this completely. I just wanted to be clear about what the benefits of a plug-in system were (and weren't). A plug-in system doesn't make it any easier for a single party to maintain a program. There are other approaches that require less effort and make the program more maintainable. But "I want to do it for the experience", or "I want other people to be able to contribute" or "I want people to pick and choose which components the program will use" can all be great reasons to use a plug-in system. I recently wrote a program with a full-fledged plug-in system. It was a lot of work, and didn't benefit the program in any way what-so-ever. (In fact, all the effort setting up the plug-in system meant less time spent on other parts of the program, which really did more harm than good.) But it was very educational.