How would you like your mini-games?

Server Discussion
1

Meguy26 here (a.k.a. Socratic_Phoenix). Recently, I’ve wanted to begin more development of my plugin, StarAPI, and I want to add a rough minigame framework. I’ve got a general idea of what I want to do, but I’m missing a crucial piece of my idea: where/when/how minigames will start/be held. Should it be an arena or a whole world? I’ve created a small specification of each, listing there pros and cons (See below). If you could take 5 seconds to check on option here, or post a comment that would be very helpful! In addition, if you can think of any pros/cons I’ve missed, it would be great to hear them! Personally I’m leaning towards the slave-world option, but I want to create something that the public actually likes…

Possibilities:
- Arena Based
- Slave World Based

General Concept:
- Arena Based
    Minigames and lobbies are based on a cuboid area defined by the user.

- Slave World Based
    Minigames and lobbies are loaded as-needed from a pool of worlds.

Specifics:
- Arena Based
    The user would select one or more lobby areas, and would place signs in
    these areas to allow people to join the game. The lobby would have 
    NO CONTROL over blocks placed, weather, time, etc.

- Slave World Based
    A directory for lobbies, and for each minigame, would contain a pool of 
   arenas/worlds. When a lobby or arena is required, it would be copied out 
   of the appropriate folder, loaded, and used. When it is finished being used,
   the world could either be discarded, or reused.

Pros and Cons

- Arena Based
    - Pros
	- Easier to setup for users
	- Less laggy
	- No possible delay between request of arena and reception of arena.

    - Cons
	- Very little control over environmental factors (weather, time, etc.)
	- Very difficult to program well
	- Difficult to create advanced maps
	- Fixed number of arenas/lobbies

- Slave World Based
    - Pros
	- Extremely easy to program
	- Environmental control (weather, time, etc.)
	- Easily create complex maps
	- Theoretically infinite number of arenas/lobbies
	- More suitable for bungee networks

    - Cons
	- Laggier, due to worlds being thrown about
	- Harder to setup for users
	- Possible delay between request of arena and reception of arena
2

I’m leaning towards the slave-world option too. Just imagine 10 huge arenas being reset at the same time, this will definitely cause lag if it happens on a single world. If you’re using slave worlds, you’d just delete them and possibly just reload a pregenerated world when the next game starts. It’d basically just boil down to copying the files on the servers drive which can be done async from the mainthread.

This said, i’ll vote slave-world :slightly_smiling:

3

Consider the ability to do both at the same time. This may not be an easy task if you’re not as experienced, but they are both very beneficial in certain cases.

Arena Based can be provided for short-lived sessions that would be better running on a long-lasting server instance than a short-lived one. It is also very important if you have many of these short-lived sessions as each server instances takes up at least a good amount of memory.

“Slave World Based” on the other hand has it’s own features that you have listed. Most importantly the environmental control. This allows games that have even the slightest world modification to recover after the session is complete.

I myself am working on a project called Blur that aims to achieve both of these cases including many others by allowing you to create and define sessions and its modules. Modules are pieces of code that work together to provide a complete game or anything else. It is very much in its early stages and doesn’t actually support Sponge yet. Maybe you can pick up a few ideas from there: GitHub - BlurEngine/Blur: Minecraft 1.16 Game Engine written in Java & Kotlin

In case my answer isn’t clear enough, I vote for both at the same time. :slight_smile:

1 Like