Week 1 — Quest Board Plugin

Minecraft Plugin · Spigot / Paper API · Java

The Idea

Most Minecraft gameplay is self-directed — you decide what to do and when. But what if the server gave you goals? A quest board is a classic RPG mechanic: a place where players pick up tasks, go out and complete them, and return for a reward.

In this project you'll build a quest system for a Minecraft server. Players walk up to a board — a sign, a chest GUI, an NPC, whatever you design — browse available quests, accept one, and then go do it. Maybe they need to kill a certain number of skeletons. Maybe they need to bring back 32 iron ore. Maybe they need to reach a specific location. When they're done, they hand it in and collect their reward.

The quest types above are just a starting point. You decide what kinds of quests exist, what the rewards look like, how many quests a player can hold at once, and what the board looks like in-game. The key constraint is that all quest types work through the same system — adding a new quest type should never require you to change the code that handles checking and rewarding quests.

Think about what would make a quest feel satisfying to complete. That instinct should guide your design.

Week 1 — Build Your Quest Hierarchy

This week is about modelling what a quest is in code, before worrying about how it gets triggered or tracked in-game.

This week's topic: classes and subclasses.

You need to capture the fact that all quests share some things in common (a title, a description, a reward) but each quest type has its own logic for deciding whether it's been completed. That distinction — shared structure, different behaviour — is exactly what abstract classes and subclasses are for.

You need:

• An abstract base class Quest that holds what every quest has in common: a title, a description, a reward amount, and a unique ID. The method that checks whether a quest is complete should be declared abstract — because how you check completion is completely different for a kill quest vs a gather quest.
• At least three concrete subclasses, one per quest type you've designed. Each subclass must hold the fields specific to its own logic — a KillQuest needs to know which mob and how many, a GatherQuest needs to know which item and how much, and so on.
• A way to create a few sample quests and assign one to a player. The actual tracking of progress comes in later weeks — for now, you just need the objects to exist and be assignable.

A simple /acceptquest command that assigns a hardcoded quest to the player is enough for week 1.

What you decide:

• What quest types you want to support
• What fields each quest type needs
• What a "reward" looks like — currency, items, experience, or something else
• Whether there's a quest limit per player, and how you'll represent that

The logic inside isComplete() doesn't need to work yet — a stub that returns false is fine. That comes next week.