Minigame framework for Spigot based Minecraft servers
Motivation
Something that I love about this project is the different motivators that I have to create something like this.
The first, and most prevalent motivator comes from one of my type of hobby projects. Every now and again I like to develop plugins for a friend of mine who ran a small Minecraft server network. Some of the plugins that were requested where minigames. In order to be able to develop such plugins more efficiently I decided to make a framework which takes care of the shared logic so that I can focus solely on the logic specific to that game.
Through the process of developing the framework, as well as developing games with the framework, I am learning a lot about of cool things about what it takes to make software which enables such games to be developed in a simple, fluid, and fun manner. The cycle of implementing features, and subsequently using this features to develop a minigame brings me a lot of inspiration and ideas on how to keep improving this project. I find this very exciting!
The goal
As per the motivation to create such a project, my main goal is to create a tool which makes the development of minigames as simple as it can be. When I place myself in the shoes of a minigame developer, I would love it if I could simply just focus on developing the mechanics that are specific to the game I am trying to make. I then do not want to spend time developing the infrastructure to make minigame development possible to begin with. Neither do I want to deal with managing the complexity of those extra systems that would be a part of the game’s source code.
To achieve all this, the framework aims to cover as much generic logic that comes with developing minigames. It currently implements systems used for scheduling actions, player management, working with locations in the game map, and of course it defines the skeleton of what a game is in the context of the framework. Developers can use and extend these systems to make them fit their game idea.
The design choices through development
My initial plan was to start of by defining what a game is at its core. I created an abstract base class which handles the basic things that a game, within the context of the framework, should handle. This class could then be extended to add the actual minigame logic to it.
As this approach became actuality I quickly ran into questions which taught me that this approach on its own was not sufficient for where I wanted to take the framework.
I wanted to include various features such as a game timer in my framework, but a question arose when I had to decide whether such features belong in the base game class. Since not every game might want to use such a timer, it felt like the timer did not belong there.
Additionally this approach might be more susceptible to simply putting too much game logic in the main game class potentially leading to a more diffivult to maintain mess of a game class.
I needed a solution which promotes the development of a game’s subsystem as its own freestanding unit. And again, thinking of the developer who just wants to code their minigame features, I wanted to framework to make it possible for anybody to develop their games in such a decoupled manner out of the box.
This is where the component design pattern comes to the rescue! At the time I was enjoying a book called “Game Programming Patterns“ which featured a chapter on this design pattern. This helped solidify my knowledge on this topic and after implementing it in my framework, I was really pleased with the benefits it gave me.
I added a component container to my game class which allows any component to be easily added to the game. The game does not need to have any knowledge of what systems are contained by it. It simply tells the component container about the game’s state updates, and the container delegates this update to its contained components. This allows components to really act as a subsystem of a game. It can mimic the state changes which the game goes through, ensuring that components can execute their logic whenever it is appropriate to do so in the game loop.
The component pattern gave me answers the questions that I had before. As the developer of the framework it enables me to provide mostly common game systems which can be seamlessly integrated into minigame implementations. And as a minigame developer it allows me to easily split my features into their own independently developable and maintainable units.
Fun stuff to still figure out
Given the smaller scope of the projects that I intended to develop using this framework, Performance is a factor which I have not given much consideration. It could be interesting to figure out potential bottlenecks, benchmarks and performance improvements.
I have been thinking about a feature that allows minigame developers to build a Customizable State Machine to represent their game’s flow. Currently the game tracks some very simple states which might feel to rigid for more complex game types.
Of course, the cycle of improving the framework and then finding improvement points through developing minigames utilizing the framework will continue to result in many fun challenges to come!