[LIB] MGLib - Fully-featured Minigame API

MGLib is a library I created to make minigame plugin creation easier. Here's the BukkitDev page, and here's the description from it:

What is MGLib?

MGLib is a library designed with ease-of-use in mind, and made to assist plugin developers in creating minigame plugins. Generally speaking, almost all minigame plugins have the same basic functionality built into them. However, this basic functionality (e.g. round management) takes a lot of time to create. If all the core code is effectively the same, why not just use the same exact code instead of rewriting it every time? This is where MGLib comes into play. MGLib provides an API for minigame plugins to use, so that they don't need to write it themselves. This can drastically reduce the size and time investment of individual plugins. MGLib boasts an easy-to-use and understand API, paired with a large featureset, with more functionality being planned and implemented every day.

What MGLib is NOT

MGLib, while installed as a standalone plugin, is not a plugin in itself. It won't do anything but waste CPU cycles if you don't have another plugin to take advantage of it installed alongside it. MGLib is also not a magic plugin-maker. You'll still need to write your own code for making your plugin unique. Likewise, you'll also need to have some sort of an idea of what you're doing, the same as you would if you were making your plugin from scratch. MGLib is designed to save time and ultimately redundant effort. It's meant to make your job easier, not do it for you.

There's plenty more about the library on the DBO page itself; I've just included the most important bits here. I submitted the first build about 24 hours prior to posting this thread, so hopefully, it should become available in the next day or two. Seeing as I've just made it public, I'd appreciate any feedback you could give on it. Even if it's not terribly interesting, I want to make this library as expansive and easy-to-use as possible. Thanks for reading, and good luck with your minigame plugins!

Edit #1: formatting

Edit #2: The first alpha build has been approved, and is now available for download.

 

ShadyPotato support to signs, arenas and scoreboards?

 

zDubsCrazy Just see the bukkit dev page, have some information
ShadyPotato Great API, i will test!

 

Interesting, I've looked at the source code for this and I find it good so far, I'll try to use it when it releases on BukktiDev.

 

Signs are supported via an automatic lobby engine. Arenas are of course supported, though it uses a slightly unorthodox approach. It should suit most needs, though. I'm considering adding a specialized scoreboard API within the next couple of updates, but I'm not set on it.

luigieai LordVakar Glad to hear the support!

 

Nice little library you have there, I particularly liked logging/rollback feature, so I skimmed through its code. I noticed few things I'm curious about.

- Is there a way to not log stuff by default? Could it have logging enabled per-plugin/per-arena, and control types of logging separately?
- You set static IMMEDIATE_LOGGING, but rollback manager is not using it. Does it serve another purpose?
- Key "immediate-logging" does not have a value in default config. (not that I don't like this, I would probably never enable such thing)

And the last thing, what about license? The library itself looks fine, but if I ever used it, I'd probably want to fork and modify it.

 

raGan.
To address your concerns:

Nice catch with the logging variables. They're a combination of artifacts from a system I abandoned and a new system I forgot to fully implement. They'll be fixed in the next build for sure.

I didn't think it would be necessary to allow for disabling of the rollback system, as I couldn't think of a case where it would be necessary. But if you think I should, I could certainly add a couple of methods to the config manager class.

Right now, it's under an ARR license, though I may change this at some point. However, forking isn't really an option due to the very way the library operates. Rather than include it in your JAR, it's installed as a standalone plugin on the server. It would be... tricky... to create your own implementation, since you wouldn't be able to easily use new features, and you'd run into potential problems if the server is running a vanilla copy of MGLib as well. It could also be confusing for the server owner to need to maintain two different versions of it.

 

Disabling unnecessary logging could reduce some overhead especially when immediate logging is enabled. I can see how not having to write to disk so often could save performance. (imagine 50 or more players constantly digging in the arena, that's a lot of IO operations)
By this I am not trying to force you to add those options, I was just thinking some people might find it useful.

I can see how it could be tricky, but I don't think it would be that hard to extract bits and pieces. Of course I would not be shading whole library into a plugin. The best thing about lib included in the plugin is server owner not having to care about it at all.

Forking is always an option, isn't it?

 

Personally, I can't see a case where you wouldn't want an arena rolled back. In the case of random arenas (which I'll implement quite soon) like SG, rollbacks would be completely disabled anyway. But, since it's not much work to add, I may do it just in case someone finds it useful.

While I personally wouldn't recommend it, you're free to do as you wish as long as you don't distribute it per sé (i.e. not packaged with a plugin), and it doesn't interfere with a running standalone instance.
I know it's easier on a server owner to include the library with the plugin, but I figure with a standalone implementation, it'll be more efficient and allow for smaller plugin sizes as well as automatic updating. Mainly the last bit though. Despite all my testing, my code tends to be somewhat buggy when I push it. This way, I can quickly and directly patch anything I missed in the last build.

Sorry, what I meant was, it could be tricky to create your own implementation from a fork. Forking alone is of course an option, and an easy one at that.

I feel it's worth mentioning that I'm completely open to suggestions via tickets on the DBO page, or pull requests via BitBucket. If you have any features you want added or fixed, submit one of the two, and if it's reasonable, I'll be happy to add it.