SkGame

[kaylendog]

Is your feature request related to a problem? Please describe. While SkGame (or more accurately what currently exists of it) currently resides in https://github.com/dumbdogdiner/SkGame, as per the last meeting, people suggested combining it with StickyAPI entirely.

Pros v Cons

Obviously, I'm not going to be able to produce a completely unbiased list here, but I will try my best.

Pros:

• Everything is in one place - centralization is always nice.
• We are still able to use Kotlin if we want to.

Cons:

• Minigame and other plugin utilities combined into one library - potentially harder to maintain?
• Was planning to write most of it in Kotlin.
• I myself would like to keep a Kotlin API out of a Java one, given the whole Java API, Kotlin plugin trend I was following, but as per the last meeting, I understand not everyone likes this.
• SkGame will deal with explicitly Bukkit-related things, whereas StickyAPI deals with both.

Describe the solution you'd like Honestly, as someone who is probably going to be maintaining SkGame a lot once I get round to writing it, I would like it to be a separate project from the rest of StickyAPI, simply because the nature of the plugins it will be designed to work with isn't your generic plugin, but instead specifically a minigame plugin. That being said, there is nothing wrong with non-minigame plugins using parts of the library, so perhaps it would be best if it were included in StickyAPI.

Additional context

• Issue with implementation spec: https://github.com/DumbDogDiner/SkGame/issues/1

• JCX's comment about Kotlin support in API:

  jcx: something like stickyapi:skgame:module would work - easy enough to impl with a hybird java/kotlin across the whole project

• I'm so gay omg

[kaylendog]

Opinions required pls, otherwise will just stick to using the existing repo.

[kaylendog]

Added a note about SkGame being related to Bukkit runtimes over Bungeecord ones.

[aakatz3]

I see some parts, such as holograms and particles, being very useful in other plugins. You can write it in kotlin inside StickyAPI (provided you use some @JVMStatics so things work in java), but I do also understand the potential issues if it's largely independent. We could also take a git submodule approach to let it continue independently under stickyapi if you prefer. I see benefits with each; the main drawback of keeping it separate is that plugins will often need to import both, some utilities will likely be duplicated, and non-game plugins will likely import skgame anyway

[kaylendog]

I see some parts, such as holograms and particles, being very useful in other plugins. You can write it in kotlin inside StickyAPI (provided you use some @JVMStatics so things work in java), but I do also understand the potential issues if it's largely independent. We could also take a git submodule approach to let it continue independently under stickyapi if you prefer. I see benefits with each; the main drawback of keeping it separate is that plugins will often need to import both, some utilities will likely be duplicated, and non-game plugins will likely import skgame anyway

If you think enough non-minigame plugins would use holograms, then it's a module that can go in StickyAPI. Imo it's better to keep the minigame-specific modules separate from the rest of StickyAPI.

[aakatz3]

Holograms, particles, guis, would all be useful in stickyapi. What is the scope of what SkGame is to contain?

[kaylendog]

https://github.com/DumbDogDiner/SkGame/issues/1 - updated to include in post.

[aakatz3]

Scoreboard, kit, and animation seem useful for lobby and/or stickycommands; Kit would also be useful in a patch on Illegal stack/exploitfixer

[aakatz3]

Do you have a proposed architecture for Minigame? And what is arena actually doing?

Also schematics is likely useful for stickyapi.

If you don't want to merge them (besides holograms, animations, and possibly kits (because it's items/inventory/gui)), can you make sure it's modular so it's easier to use for non-minigame plugins?

Animations have bits already in stickyapi, and holograms are useful as a part of that.

Again, I don't mind kotlin in StickyAPI, if my word has any meaning on the subject

[spazzylemons]

Perhaps we could keep working on SkGame utilities in SkGame until we find that non-minigame plugins could benefit, not that they could in some point in the future but that they are at a point where their code could be simplified with the use of SkGame

[spazzylemons]

I also have a feeling that we might benefit from several smaller, more focused library projects instead of a single (albeit modular) API for all plugins

[aakatz3]

I see pros and cons to that, I like the ability to just "make" an API by adding a module to StickyAPI, which makes it very flexible. I'd personally prefer one big but modular library so all utilities are in one place, allowing for better integration if one module needs to work with another. I don't mind adding kotlin, or groovy, or raw JVM support to StickyAPI. I think it would also be easier to maintain one project compared to two. Alternatively, I could have it integrated as a submodule, if preferred, so development can be independent. I just like the idea of small modular components that can easily interact compared to separate libraries

[aakatz3]

That said, we need to have a faster process for adding stuff to StickyAPI and I'll have a convo with James on some ways to do that (Gradle task to create modules comes to mind, along with the IDEA stuff I'm working on)

[spazzylemons]

I agree that having an API that has everything you need in one place is nice, but I worry about organization and efficiency there. Say, for example, a feature like heads or MojangAPI in API was its own library, then it would be much easier to work on it incrementally than to submit a large PR with lots of comments and files, which as someone who is not yet experienced with that kind of thing, feels very overwhelming and maybe not necessary. That comes with the downside of having more Things to deal with, more repos to maintain, perhaps some duplication in ci/testing/etc,.. which isn't great. I agree that it would be good to discuss ways to improve this process

[aakatz3]

I agree that having an API that has everything you need in one place is nice, but I worry about organization and efficiency there. Say, for example, a feature like heads or MojangAPI in API was its own library, then it would be much easier to work on it incrementally than to submit a large PR with lots of comments and files, which as someone who is not yet experienced with that kind of thing, feels very overwhelming and maybe not necessary. That comes with the downside of having more Things to deal with, more repos to maintain, perhaps some duplication in ci/testing/etc,.. which isn't great. I agree that it would be good to discuss ways to improve this process

I understand that, the downside is that it's harder to integrate between things. Lots of commits can happen anyway (see: math), files would happen for any new git repo. One way to make improvements faster would be to edit branch protection rules and codeowners, so that people who control specific subsections don't need reviews or extra perms to modify just those

[kaylendog]

I also have a feeling that we might benefit from several smaller, more focused library projects instead of a single (albeit modular) API for all plugins

I think, given Spazzy's comment on small, more focused libraries, it will be better to keep SkGame separate from API - at least while we try it.

Scoreboard, kit, and animation seem useful for lobby and/or stickycommands; Kit would also be useful in a patch on Illegal stack/exploitfixer

We can review which plugins would actually use the SkGame modules once they're written - can always move code over then.

Do you have a proposed architecture for Minigame? And what is arena actually doing?

I've been thinking about this for a while - it's effectively a query-based way of writing minigames. You can define rules about particular events, rather than needing to implement the listeners yourself. I'm thinking this is somewhat similar to puzzlescript - this massively differs from what I want the end goal to be. I will be writing a specification for this once I'm done with exams.

Arena abstracts away all of the shared details between different implementations of arenas and their boundaries. All of MusicalSquares, Warrior, and StickySurvival define separate implementations of what an arena is, but they tend to have shared features - i.e. the name of the arena, its bounds, and what players are currently inside it.