LobbyAPI - Open discussion - Printable Version +- Cuberite Forum (https://forum.cuberite.org) +-- Forum: Plugins (https://forum.cuberite.org/forum-1.html) +--- Forum: Plugin Discussion (https://forum.cuberite.org/forum-8.html) +--- Thread: LobbyAPI - Open discussion (/thread-2240.html) |
LobbyAPI - Open discussion - chrobione - 12-09-2015 I am just starting this thread to keep the conversation going on how to move forward with a LobbyAPI to host mini-games. I will post more when I have clearer ideas to explain how think it should work. c (12-08-2015, 07:52 PM)xoft Wrote: I like the idea of a "game lobby" plugin - an API that takes care of the chores of setting up a game lobby and individual arenas, providing an API for that instead, so that all games have a unified command set for joining them etc. 1. What commands should it support? 2. How will it be administered? 3. What storage? 4. What internal Structures? . . . 100. Make it organized... or is this suppose to be #1 ~ RE: LobbyAPI - Open discussion - DiamondToaster - 12-09-2015 Whoops. I put my post on the other thread. I guess I'll move it over here. EDIT: Already privately working on it a bit, I might post stuff on GitHub in a few days/a week or so. My question is, how would you want the API to be laid out? For example, I was thinking of placing everything in a single (well organized and commented this time) .lua file and have it so that the plugin developer could drop that file in with the rest of his plugin and be able to pass tables. Then I could create functions which accept a table of arguments for arena creation and stuff. The API would mostly control the state of arena objects and player modifiers by itself. NewMinigame = { -- This would contain a bunch of hooks, including normal player hooks for each person in the arena, and a tick function, I'll have to get a bit more in depth with it. -- Basically, the developer would create a minigame table specific to what they want to make and stick it here and it will run this code for each arena with this minigame. } local NewArgs = { -- Name the arena, a function could be used to grab a reference using this later Name = "NiceArenaYouGotThere", -- Define the bounding box that the arena covers MinCoord = Vector3d(-50, 50, -50), MaxCoord = Vector3d(50, 70, 50), IsSolid = true, Minigame = NewMinigame } local NewArena = LNewArena(NewArgs) Mainly just ideas and stuff for now, input for how you guys want this laid out would be nice. RE: LobbyAPI - Open discussion - xoft - 12-09-2015 The entire thing should be a separate plugin, because there will be multiple client plugins and they have to share the arena data somehow - the LobbyAPI plugin must check if two arenas (for two different plugins) overlap etc. Technically, you could make an API layer which would be that single file that is dropped into each client plugin and provides a nice clean API with tables, and internally serializes those tables somehow and sends them over to the actual plugin via CallPlugin. I think this thread should be more high-level: Define objects the API plugin will be working with - arena, lobby, player, spectator, score etc. Then define relations between the objects. From there we'll see what functions will be needed. Consider this an early prototype for the documentation, an introduction of sorts for someone who wants to write a minigame plugin but has no idea how minigames work. RE: LobbyAPI - Open discussion - NiLSPACE - 12-10-2015 Perhaps the Lobby plugin should provide an empty arena object. This defines the basic items a plugin can have, for example a list of players that are inside the arena. Then a different plugin can expand upon that by overriding the functions. I did the same for my Catastrophes plugin. There is an object that defines the most basic things like the position, speed and world, and other catastrophes expand upon that. They can override functions that the basic object provided. In this case plugin's should provide a file that the lobby plugin would load. If an arena needs specific data from the plugin it's created from it can simply use CallPlugin to call an API function there. RE: LobbyAPI - Open discussion - xoft - 12-10-2015 Still too low-level. First draft up what we want the plugin to solve for us, high-level. RE: LobbyAPI - Open discussion - DiamondToaster - 12-10-2015 It would be pretty nice to pass tables to the API plugin to simplify things a bit. Checking for overlapping arenas across plugins seems like a tricky task since the only way to communicate with another plugin is through reverse dependency or some known plugin call. RE: LobbyAPI - Open discussion - DiamondToaster - 12-10-2015 Here's a starting thing I guess. The hardest part seems to be just figuring out how to lay the whole thing out. https://github.com/DevToaster/LobbyAPI RE: LobbyAPI - Open discussion - NiLSPACE - 12-10-2015 But the whole idea of this thread was to think before we start coding. RE: LobbyAPI - Open discussion - sphinxc0re - 12-10-2015 Welcome to the world of OpenSource xD So agile! RE: LobbyAPI - Open discussion - NiLSPACE - 12-10-2015 Well then where are the user stories? |