Release Your Block Legend

01 / 14

Before starting: first recognize the running position

The first 30 lessons lay the foundation for ordinary Java programs. At this stage, the code is connected to the Paper server: the Minecraft client is responsible for entering the world, the server loads the plug-in, and the events and commands hand over player actions to your methods.

This book uses JDK 21 and Paper 1.21.11, and the client version is also consistent. The latest version on the download page may have changed, select it by version number. This book uses normal plugin.yml and the Bukkit API; no claims are made to support Folia at this stage.

The short examples in the picture frame are partial fragments. Read the location description of this section first, and do not save each as a plug-in. The file name will be clearly given for the complete file; when the same file is divided into multiple segments, they will be connected by number, and the package name, import and outer class will only appear once.

• Prediction: Write success conditions and expected messages first.
• Run: After successful construction, install and restart on the dedicated local test server.
• Verification: Ordinary players, management identities and consoles take corresponding paths respectively.

02 / 14

Choose a work that can explain clearly

A Fang threw a JAR to his deskmate: "Graduation!" The deskmate asked about the version, command, configuration and installation location, so Afang had to put away the celebratory fireworks first. A release is a complete delivery that others can use.

The release package puts the program together with instructions for use: supported versions, installation methods, command permissions, configuration, testing, and known limitations. Use a clean test server to install it according to your own instructions. You can find the steps that people who are familiar with the project are most likely to miss.

03 / 14

Separate what must be done from what must be done later

Write a range card for 1.0.0. On the card, write both "what you can do" and "what you can't do." In this way, when students ask "Where is my champion after restarting?", you can point out that only the memory data of this game is currently retained, instead of temporarily pretending that the champion was stolen by the creeper.

Must: join, score, start, stop Four subcommands
Must: Iron ore 3 points, gold mine 5 Points, diamonds 10 points, including deep slate version
Must: The world and 1 to 3600 seconds configuration, administrator starts and stops
Must: Naturally end the display of results, cancel or deactivate the cleaning task
Does not contain: History list, physical rewards, automatic mines, complete anti-cheating
Restart: Clear the results and registration of this bureau, disk config.yml Reserved

• Ordinary players can only register and inquire; administrators can start or cancel.
• In the survival mode of the designated world, registered players are allowed to destroy the target ore before scoring.
• After verification in the prepared dedicated test field, the practice version cannot be declared as the anti-cheating system of the public competitive server.

04 / 14

Put the code where you can find it

Lesson 38 only has two class, so there is no need to split it into twenty empty boxes in order to appear advanced. GameRound manages numbers and status; OreRushPlugin connects to Paper. First clarify the responsibilities, and then consider packages such as command, listener, and data when the real complexity appears.

OreRush/
  build.gradle.kts
  settings.gradle.kts
  gradlew  gradlew.bat  gradle/wrapper/
  src/main/java/de/teacherma/orerush/
    GameRound.java
    OreRushPlugin.java
  src/main/resources/
    plugin.yml
    config.yml
  checks/RoundChecks.java
  README.md
  CHANGELOG.md
  TEST-RESULTS.md

05 / 14

Give an accurate version of the release package

The file name, plugin.yml and instructions should be the same version. Use the same build script from Lesson 31 and check only the fields below. We agree that 1.0.1 represents minor fixes, and 1.1.0 represents compatible new features; the version number is an agreement, not a magic guarantee of compatibility.

Stop and think about it: After the update, the game still behaves like the old version. Should I change the code first or check the installation package first? How to prove that the test is a new build?

// settings.gradle.kts
rootProject.name = "OreRush"
// build.gradle.kts
version = "1.0.0"

version: 1.0.0

.\gradlew.bat clean build
jar tf build/libs/OreRush-1.0.0.jar

• There should be plugin.yml, config.yml and .class files of the two main program classes in the JAR.
• Use the Gradle Wrapper of the project, retaining the wrapper directory and startup script.
• A successful build only means that the build is successful, and does not mean that the plug-in permissions, world conditions or two-player gameplay have been tested.

06 / 14

Configuration is not a score archive

The configuration explains how the game is played, and the results explain what happened in the game. They are not the same account. The current plug-in saves config.yml, but registration and results are only in memory; after stopping the server, it will not automatically resurrect the previous game, and it cannot resume the countdown from a task number.

schema-version: 1
# records Game numbers, players can be saved in the future UUID and score.
# First design verification, backup and failure handling, and then write persistence code.

07 / 14

Let the instructions answer the first round of questions for you

README is an instruction manual for the work, not a password for the author himself. Ask a classmate who has not participated in the development to follow the installation; wherever he stops, that step is usually worth adding. The following is a rewriteable skeleton, and the actual test fields must be filled in by yourself.

# OreRush 1.0.0
Purpose: Classroom mining scoring competition under teacher supervision.
Environment: Java21, Normal Paper1.21.11;Not supported Folia.
Installation: Stop taking, will JAR put plugins, Check log after startup.
Configure: plugins/OreRush/config.yml;Stop and restart after modification.
Command: /orerush join, score;Administrator use start, stop.
Management permissions: blockacademy.orerush.admin, Default op.
Rules: Iron 3, Kim. 5, diamond 10 points, all containing deep slate version.
Conditions: Registered, survival mode, designated world, event not canceled.
Result: Natural end of broadcasting the score of this game;stop Cancelled, no awards will be given.
Restart: Clear registration and scores, do not restore this game; configuration retained.
Limits: No history list, no rewards, no mining areas or ore sources to prevent cheating.
Test record: Write your own date, environment, passed items and failed items.
Feedback: Submit recurrence steps and desensitized logs to the teacher.

08 / 14

Release records and write changes without writing magic

"Better, faster, stronger" sounds like an enchantment advertisement, but it doesn't tell players what has been changed. Release records list new additions, fixes, and known limitations; test records additionally hold actual evidence. Put unfinished improvements in the planning area and don't pretend to be completed.

# 1.0.0
New: Registration, score query, administrator start and stop.
New: Six kinds of ore materials are scored, including three kinds of deep slate ores.
New: Configurable world and game duration.
Limits: Matches are not saved across server restarts and do not award physical items.

Date and environment: Fill in according to this real test
Use case number | Expected results | Actual results | Through/Failure/To be tested
Failure item supplement: Reproduction steps, log position, and retest after repair
Build version: With final delivery JAR Be consistent

09 / 14

Use clean test clothes to accept the installation

Your old server may hide old configurations, other permission plug-ins and JARs left last time. Please prepare a separate local test directory and re-install it; when you need to test the protection interaction, explicitly add the protection plug-in. The test environment must also be explainable.

10 / 14

If the update fails, you need to know how to go back.

When updating a railway switch, let the train stop first. Stop the server and wait for exit, back up the current JAR and corresponding plug-in data directory, and then replace it with a new version. If the startup fails, keep the log first, and restore the matching old files after stopping the service. You cannot change them randomly during operation.

release/
  OreRush-1.0.0.jar
  README.md
  CHANGELOG.md
  TEST-RESULTS.md
  source/  # Source code, build files, wrapper, Inspection Procedure

Get-FileHash .\OreRush-1.0.0.jar -Algorithm SHA256

• SHA256 consistency can be used to check file copies and is not equivalent to plug-in security authentication.
• Backup and rollback require actual practice; if the data format is changed in the future, it is necessary to verify whether the old program can be read.
• Do not package entire servers, account information, or private logs; check sources and permissions before publicly using material.

11 / 14

five-minute demonstration, let students play first

The demonstration does not require pronouncing each line of import as a spell. Let the audience know the goal first, then show a play and an action that was correctly rejected. You can shorten the configuration before the demonstration and explain that it is a demonstration setting; showing evidence when an accident occurs is more professional than pretending that nothing happened.

• Why use UUID as key instead of just player name?
• Why enter ENDING first and then broadcast the results?
• What is retained and what is cleared on restart? How to prove that there is no second timed task?

12 / 14

The graduation score depends on the evidence and the explanation.

Scoring is not about counting lines of code: copying 10,000 lines but not being able to tell the status is not as good as making a reliable little plug-in yourself. Use the same sheet to check the work and ask trial partners to give feedback on reproducibility. It’s recommended to be specific about the action, don’t just say “it’s a little weird”.

Blurred: Why always 0 points?
Concrete: No join Just dig diamonds and query to get the unregistered prompt.
Judgment: It belongs to the rule rejection; you can remind you to register earlier in the description..
Next step: First change the prompt, then ask students to go through the process again.

13 / 14

Expansion challenges and own acceptance records

Leave the source code, actual running results and a problem record. Explain it in your own words first, and then run the verification; where the results are different from the predictions, they are often the most worthy of discussion.

• Wooden Pickaxe: Submit a minimum playable work, independent JAR, source code, instructions, real test records, and give a five-minute demonstration.
• Iron Pickaxe: Select only one improvement from configuration, permission feedback or history records, and complete normal, boundary and failed tests.
• Diamond Pickaxe: Invite three students to try it out, choose one piece of feedback to formulate the 1.1.0 plan; only after it is implemented and accepted will it be included in the published functions.
• Acceptance requirements: Complete a 5-minute demonstration and independent installation by deskmates; submit version list, tested scenarios, untested projects and executable rollback steps.

14 / 14

The next adventure of the graduation work

The end point of Lesson 40 is a work that others can install, check, and give feedback on. Pick a real problem: maybe a clearer rejection prompt, a more stable state cleanup, or a contracted data save. Write it as an acceptance condition for the next version.