Totally not the official name of the plugin, or is it? I’m focused on creating a Framework for developers, beginner or old, to help create mini-games fast and easy.
What’s Planned?
I feel like I shouldn’t try to make everything. The framework could have joinGame(player, arena), or player.joinGame(arena), exc… But I don’t plan on controlling stuff like commands.
There are 3 ways I can think of within the framework to join an arena/game. Commands, A Dynamic Sign which you click to join, or join on an event. Commands and events shouldn’t be controlled through the framework but with the plugin.
Some framework ideas include
GameBuilder gb = new GameBuilder();
Game TNTRun = gb.createGame(“TNT Run”); //Initiate the game with ID and name.
TNTRun.setName(“TNT Run”);
TNTRun.setType(TYPE_ARENA); //TYPE_ARENA, TYPE_INVISIBLE_ARENA, TYPE_SANDBOX (sandbox means game starts but players can still join).
TNTRun.setMinPlayers(5);
TNTRun.setMaxPlayers(20);
TNTRun.setJoinableCountdown(30);
TNTRun.setStartCountdown(5);
Arena firstArena = TNTRun.createArena();
firstState.setState(STATE_JOINABLE) //STATE_JOINABLE, STATE_INPROGRESS, STATE_RESTARTING, START_OFFLINE (State of an arena)
Nothing is set in stone, give me ideas!
This is just the beginning of my blueprints for the game framework, give me ideas and suggestions below, thanks!
If you develop this as a base arena plugin API versus other methods I think you may be able to better illustrate the end goal. In this case what you are trying to develop is really just a series of methods that can take a base set of “game functions” and translating it into a set function that ensures that compatibility and functionality. So a method of creating an arena, defining type of arena, joining an arena. creating teams, setting goals, setting/triggering events, end game events, quitting/leaving arena, removing arena.
This is a great idea and has such a HUGE potential to do some really great things.
Agreed. Thats my goal, however at the same time I want to be able to support a range of different types of games so I can’t be too vague with the functions I create.
Love it so far! (also arena.reload() so it doesn’t have to load a specific schem every time would be good)
I’m assuming it will have scoreboard support too?
I realize that each gametype would have their own type of sub-methods but in the end semi-vagueness is precisely what you want though. As an API a clear definition of input/output for function is all that is required. So for each game type the API would be doing more to just ensure that all the proper hooks and such are done in a uniform and efficient way to ensure a successful arena. The fact that it is an API means that the details of what to do with the results of each are up to the end designer to decide.
That is true to an extent, but I am sure that the idea here would be to centralize the base, this would actually make it easier to have a larger variety of games function together with fewer problems.
Wasn’t planning on it because my personal game building framework for Bukkit did not have one because modifying scoreboards through Bukkit wasn’t fully supported at the time, but I can def see myself adding it in.
Yes,. no offence or anything. I like your idea, but I would encourage beginning developers to make their own framework step by step rather then using something that is premade
I doubt that the idea here is to discourage new developers from creating their own framework, rather I would say the idea is to create a extensible base framework that could be used to develop new ideas and combinations. The very idea that this would work to include new games and such would be a reason itself for developers to work on new ideas and methods that could in turn be incorporated into this framework. I think this is a good case of one hand washing the other as it creates a launching pad for new ideas in this area.