This project has been abandoned at an early concept stage. For historical reasons, these documentation pages remain here.
Motivation
Have you ever encountered the following situation?
You are the owner of a Minecraft minigame server. Your development team created a powerful dynamically-scaling backend with a proprietary API for all your minigame plugins. Some day, you discover a cool new open-source minigame you want to host on your server. However, there's a slight problem: The minigame is not compatible with your proprietary API and implements its own environment (e.g. arena management). In order to host the minigame, you would need to rewrite large chunks of the code to make it work with your API. And that would have to be done after every update as well. In the end, you decide that it's not worth it and move on.
Or does this situation sound familiar?
You are the developer of a cool new open-source Minecraft minigame plugin. During development, you've already wasted a lot of time by implementing your own arena management system. Although you've spent a lot of time on the system, it only works with one single server and is rather limited. After you published the plugin, everyone thinks it's cool, but nobody is playing it because not a single big server hosts your minigame.
Solution
GameSpec is an attempt at solving this problem. The first component called GameSpec API defines a very flexible and small abstraction layer. Your next cool minigame can use that abstraction layer and doesn't need to worry about the environment it will be running in. It just implements the game, and nothing else. Because the API is extremely flexible and doesn't implement anything that isn't absolutely necessary, GameSpec doesn't force you into some kind of arena system. Instead, you tell GameSpec what to do, not the other way around.
The second component consists of several GameSpec Containers. Each container is implemented for a specific environment. If your server is big enough, you might also want to implement your own container for your environment. However, the minigames do not need to worry about those different environments. All containers provide an implementation of the GameSpec API somehow. That means that every possible game which is implemented using the API is able to run in your environment.
In short, plugins are written with the GameSpec API abstraction layer. That abstraction layer is then provided by a GameSpec Container. After some time, you will be able to choose from multiple containers. If you just want to develop a minigame plugin using the API and need to test it somewhere, it is not necessary to host a large dynamically-scaling container with multiple servers and proxies. Instead, you can run an extremely simple one-server container on your testing server. When you go into production, you use a production container like the dynamically-scaling one mentioned above.
The fact that a fully-featured open-source production container, which is able to manage multiple servers, will be available also solves another problem: If you have the monetary resources, you are now able to create a new big server without the need to developing your own backend system. Instead, you can just use the open-source container.
tl;dr
GameSpec is not an API which makes creating Minecraft minigames easier by providing some fancy APIs. Instead, it functions as an abstraction layer which is implemented by different GameSpec containers. Depending on the use case, different containers (environments) implement different features. That way, a user can select the container which best fits his needs and is still able to host all minigames he wants to host.
Essentially, GameSpec is a standard for SpongeAPI minigames.
Components
- GameSpec API: The main standard which defines minigames.
- GameSpec Single: A simple container which allows to run games on one single server. Useful as a testing tool for game developers.