IN1010 - Objektorientert programmering

Week 1 — Minigame Framework

Minecraft Plugin · Spigot / Paper API · Java

The Idea

Minigame servers are some of the most popular in Minecraft — Hypixel, Mineplex, countless others all run dozens of different games on the same server. What makes that possible is a shared framework underneath: a common structure that every game is built on, so the server doesn't have to start from scratch for each one.

In this project you'll build that kind of framework yourself. The goal isn't just to build one game — it's to build a foundation that two different games can run on, and to make sure those games are as different as possible to prove the framework is real. Spleef (break blocks under players until they fall) and a PvP Arena (fight until time runs out) are natural starting points, but you decide what your two games are and what makes each one work.

The constraint that makes this interesting: the code that manages the game — starting it, stopping it, handling players joining and leaving — should not need to know which game it's running. It just calls the same methods, and the game takes care of the rest.

Week 1 — Build Your Framework Skeleton

This week is about the structure, not the games. You're building the scaffold that both of your games will hang from — before either of them does anything interesting.

This week's topic: classes and subclasses.

There are two hierarchies to design this week.

The first is Minigame — the abstract base that both of your games will extend. It should hold what every game has in common: a list of players, and the lifecycle methods that the server will call (onStart, onEnd, onPlayerJoin, onPlayerLeave). Those lifecycle methods should be abstract — every game handles them differently. You can also put shared concrete logic here if it applies to all games, like broadcasting a message to all participants.

The second is GameState — a way of representing what phase a game is in. A game sitting in the lobby waiting for players is different from a game actively running, which is different from a game that's just ended and is showing results. Model those phases as concrete subclasses of an abstract GameState. Each state should know what happens when it's entered and when it's exited.

You also need a simple game manager that can hold a reference to the current game and call its lifecycle methods.

By the end of week 1 you should be able to run a command that creates a game instance, starts it, and confirms it started — even if nothing actually happens in-game yet.

What you decide: