Week 1 ¡ª RPG Class System

Minecraft Plugin ¡¤ Spigot / Paper API ¡¤ Java

The Idea

Most Minecraft servers are the same for everyone ¡ª the same tools, the same combat, the same experience. What if different players felt fundamentally different to play?

In this project you'll build a class system for a Minecraft server. When a player joins, they pick a class ¡ª and from that moment on, the game plays differently for them. A Warrior tanks through damage. A Mage bends the game's physics. A Rogue strikes fast and disappears. Each class should feel distinct in a way that actually changes how you approach the game.

The classes above are just a starting point ¡ª you decide what they're called, how many there are, and what makes each one interesting to play. You also decide what it means to prestige: maybe it's reaching a kill count, maybe it's surviving a certain number of nights, maybe it's something entirely different. The only constraint is that your system is built so that adding a new class later is easy ¡ª without having to touch any code that already works.

Think about what kind of server this would live on. That context should shape what classes even make sense.

Week 1 ¡ª Build Your Class Hierarchy

This week is about the foundation. No abilities, no game events, no Spigot listeners yet ¡ª just the class structure that everything else will build on.

This week's topic: classes and subclasses.

The goal is to model the concept of a "player class" in code. You need:

• An abstract base class PlayerClass that captures what every class has in common ¡ª a name, a description, and the behaviour that will differ between classes (declared as abstract methods).
• At least three concrete subclasses ¡ª one per class you've designed. Each subclass represents one playable class and must have its own fields where relevant (e.g. a damage multiplier, a cooldown time).
• At least one prestige subclass that extends one of your base classes. A prestige class is a more powerful or specialised version that unlocks later. It must override at least one method from its parent in a meaningful way ¡ª not just call super and add one line.

You also need a simple /setclass command so that a player can select a class in-game, and the correct subclass object gets created and associated with them.

By the end of week 1 you should be able to: join the server, run /setclass warrior (or whatever you've named yours), and have the plugin create the right object and confirm the choice in chat.

What you decide:

• What your classes are called and what distinguishes them
• What fields each subclass needs to hold its own data
• Which class gets a prestige subclass, and what makes it different
• What the abstract methods are named and what they'll eventually do

The implementation of those methods comes in later weeks ¡ª for now, stubs are fine.