LobbyAPI - Open discussion

[chrobione]

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

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.

I suggest you should start a new forum post for brainstorming the ideas first: what should the plugin take care of, how will other plugins interact with it, what commands should it support, how will it be administered, what storage, what internal structures etc. Make it organized.

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 ~

[DiamondToaster]

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.

[xoft]

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.

[NiLSPACE]

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.

[xoft]

Still too low-level. First draft up what we want the plugin to solve for us, high-level.

[DiamondToaster]

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.

[DiamondToaster]

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

[NiLSPACE]

But the whole idea of this thread was to think before we start coding.

[sphinxc0re]

Welcome to the world of OpenSource xD So agile!

[NiLSPACE]

Well then where are the user stories?