we should define something: API is just another level of abstraction your game will be built ontop of API is NOT your game like how steel is not a car, but you use steel to make the frame of the car to make a car making unique steel wont make an unique car design(which is what your customer look at) and i dont see what minigame api your plugin would really needs: very basic ones just need a way to run a game modest one maybe want to run multiple games advanced ones maybe want same static arena, or multiple arena in one world which is really why the api is here for, suit the normal use cases that you can build your game ontop of but i would agree that there's no better way other than to create your own if say the library dont support multi world games which is critical for your minigame
Exactly, that was what I meant. Imagine you started to code using a minigame API, and you encounter a situation like that one, where the minigame API doesn't support multi-world games. Unless you have everything clear before you start to code, but this is subject to change. You simply can't assure a minigame API will fit all your game requirements, and if this happens you will either have to bother in opening an issue on the relevant repository, or code a fresh new plugin.
You treat opening an issue like a sin. Open source is there to collaborate. You can't expect a project ran by one person to suit all your needs without you explaining all of them. If you are able to code a fresh new plugin, why not contribute to the existing API to make it even better than it is?
Uhhh that's why I'm starting a NEW minigame API? An API shouldn't limit you to anything, it's should be up to the dev what they want to do with it.
i totally can see this happening which is why i am thinking of crazy ways one would want to use it to reduce the chance of this happening tho if they developer(s) is still active i dont see why they wouldnt accommodate you
Do you understand what an API is? It is something that is supposed to be extended. It is not there to limit you.
I'm also pretty unsure as to how much a mini-game "api" should do and how much it should do. Especially on the "compatibility" topic for multiple games, in my opinion the api should not rely on anything that is not done by it, or by the extending plugin/game. For example just teleporting a player into a "game" world shouldn't cause the "api" to do anything. Should the API even handle events? Should it just rely on the plugin telling it everything? Should it even rely on an "Arena" concept? There are many questions and many answers. For me personally though, I would only start to use such "apis" if they had 1) Great documentation (e.g. easy to learn, no hours figuring out how to do stuff) 2) Actually take workload off me (e.g. allow me to write less functional code) -> faster minigame development 3) Don't limit me at all (...) Solely these three are very hard to fulfill. I didn't create many minigames yet, but espeically 2) and 3) are a problem. When you write your own PlayerManagers/Queues/Arena/Area code, you exactly know how it behaves and what it does when and how. If you just spend hours to debug why players are teleported there, or how to adjust certain functionality, you're faster with writing it on your own. Your own code is also perfectly adjusted to your game, and only does what your game needs. The only actual thing very common in minigames is some kind of "queuing" code, but the rest is often very different.