The Server Emergency Room

01 / 12

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 / 12

The red stack is a positioning map

The server throws out a long list of red letters, and Fang guesses from the bottom. The detective handed over a magnifying glass: first identify the type and cause of the anomaly, then find the first location of your project, and follow the call path to avoid getting lost in the log.

Debug first reproduce, then narrow down the conditions, and finally fix one point and retest. There are two levels of testing: pure Java checking rules, and real server checking whether events, commands and scheduling are connected correctly. Compilation approval cannot replace in-game acceptance.

java.lang.NullPointerException: ...
    at de.teacherma.orerush.OreRushPlugin.onCommand(OreRushPlugin.java:58)
    at org.bukkit.command.PluginCommand.execute(PluginCommand.java:...)

Steps: Enter/orerush score
Expected: Not registered yet
Actual: Red letter abnormality
Environment: Java21 Paper1.21.11 Plug-in version and complete exception are attached separately

03 / 12

If the player cannot be found, stop first.

Querying online players may result in null, and offline does not mean "finding an invisible Player". Check results immediately before reading names or sending messages. Not all nulls should be forced to the default object, sometimes it is more appropriate to explicitly tell the operator to fail.

Player target = getServer().getPlayerExact(name);
if (target == null) {
    sender.sendMessage("Player is not online, please check name");
    return true;
}
target.sendMessage("The teacher invites you to take the test");

catch (IOException ex) {
    getLogger().log(Level.WARNING, "Read failed", ex);
}

04 / 12

Boundary Repair 1: Bonus points after the end

The bad version only checks whether the player has signed up. When the list is still there after the game, if you continue to mine, your points will increase. Add "in game" to the condition of the extra point method, and even if the caller forgets to check, the core rules can still block extra points outside the game.

Stop and think about it: If the repeated start test of the rule class passes, can it prove that the server only creates one scheduled task? What else to observe?

if (scores.containsKey(id)) scores.merge(id, points, Integer::sum);

if (state == State.RUNNING && scores.containsKey(id) && points > 0)
    scores.computeIfPresent(id, (key, old) -> old + points);

r.add(alex, 10); // In WAITING Status
check(r.snapshot().get(alex) == 0, "waiting cannot score");

05 / 12

Boundary Repair 2 The game of surviving for one more second

If it is judged that remaining is equal to 0 first and then subtracted, the 2-second game will not end until the third callback. Let's use an example that's short enough to count: start with 2, change to 1 for the first time, change to 0 for the second time and settle. Don't really have to wait a minute.

if (remaining == 0) return true;
remaining--;
return false;

if (--remaining > 0) return false;
state = State.ENDING;
return true;

06 / 12

Boundary Repair Three Two referees count seconds at the same time

The bad version creates a task every time it receives a start. Press it twice and the seconds will drop as if you have taken a potion of urgency. First let GameRound.start verify the status, and only enter the scheduler if successful; when stopping, both cancel and clear the task field.

if (!round.start(duration)) {
    sender.sendMessage("Unable to start");
    return true;
}
// Create the task below

if (task != null) task.cancel();
task = null;
round.reset();
names.clear();

07 / 12

The first half of the automatic inspection program

Create new checks/RoundChecks.java in the OreRush project. This page continues from the next page which is a complete file and does not include the plug-in JAR. When the check fails, an AssertionError is thrown and the operation fails immediately; it will not be skipped silently like Java assert, which is turned off by default.

import de.teacherma.orerush.GameRound;
import java.util.UUID;

public class RoundChecks {
    private static int checks;
    private static void check(boolean condition, String name) {
        checks++;
        if (!condition) throw new AssertionError(name);
    }
    public static void main(String[] args) {
        UUID alex = new UUID(0, 1), steve = new UUID(0, 2);
        GameRound r = new GameRound();
        check(!r.start(60), "empty cannot start");
        check(r.join(alex), "first join");
        check(!r.join(alex), "duplicate join");
        r.add(alex, 10);
        check(r.snapshot().get(alex) == 0, "waiting cannot score");
        check(!r.start(0), "zero duration rejected");
        check(!r.start(3601), "too long rejected");
        check(r.start(2), "start two seconds");
        check(!r.start(2), "duplicate start rejected");
        check(!r.join(steve), "late join rejected");
        r.add(alex, 10); r.add(steve, 10); r.add(alex, -5);
        check(r.snapshot().get(alex) == 10, "valid points only");
        check(!r.snapshot().containsKey(steve), "outsider cannot score");

08 / 12

The lower part of the automatic inspection program

Continue to the previous page. After returning to zero, try adding points again, reset again, and check whether the old score snapshot still exists. Finally overrides deep slate ore, normal stone and null input. Outputs PASS 24 checks on success.

        check(!r.tick() && r.remaining() == 1, "first tick");
        check(r.tick(), "second tick ends");
        check(r.state() == GameRound.State.ENDING, "closed before result");
        r.add(alex, 10);
        check(r.snapshot().get(alex) == 10, "ending cannot score");
        check(!r.tick(), "cannot end twice");
        var result = r.snapshot();
        r.reset();
        check(r.state() == GameRound.State.WAITING, "reset state");
        check(r.snapshot().isEmpty(), "reset enrollment");
        check(result.get(alex) == 10, "snapshot survives reset");
        check(GameRound.points("DEEPSLATE_DIAMOND_ORE") == 10, "deep diamond");
        check(GameRound.points("GOLD_ORE") == 5, "gold");
        check(GameRound.points("DEEPSLATE_IRON_ORE") == 3, "deep iron");
        check(GameRound.points("STONE") == 0, "ordinary block");
        check(GameRound.points(null) == 0, "missing material");
        System.out.println("PASS " + checks + " checks");
    }
}

First create a new checks/sources.txt, and write the following two source file paths relative to the project root directory, one per line. Then run the short command from the project root directory; you can also run RoundChecks.main directly from the IDE.

src/main/java/de/teacherma/orerush/GameRound.java
checks/RoundChecks.java

javac -encoding UTF-8 -d checks/out @checks/sources.txt
java -cp checks/out RoundChecks

PASS 24 checks

09 / 12

Test the game in ten scenarios

What is automatically checked is digital rules, and there are more command permissions, modes, worlds and other plug-ins in the game. Operate according to the table and record the "actual results" and log location; when you find a problem, only change one condition and try again, so that the evidence will not teleport like the Ender Man.

10 / 12

Find the real time-consuming before optimizing

When players say "stuck", it may be caused by network, world generation, or plug-ins. Record the time, number of people, operations and reproduction steps first, and then measure. Don't declare a for loop guilty just when you see it: looping ten points is not the same thing as writing a file for every piece of ore.

long started = System.nanoTime();
var result = round.snapshot();
long elapsedNs = System.nanoTime() - started;
// Single result is subject to JVM Influences such as preheating are not formal performance conclusions..

getLogger().info("OreRush started, players=" + round.snapshot().size());

• Do not download web pages, traverse all blocks, or save entire files every time you mine.
• In the test server, you can use the performance analyzer according to Paper's official Profiling guide, first check the time-consuming calls and then optimize.
• Check the player name, address and path before sharing logs or analysis reports; underage students should not upload complete server information by themselves.

11 / 12

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: Explain a stack of one's own project, pointing out exceptions, methods and source file locations.
• Iron Pickaxe: Reproduce and fix three bugs in this lesson in the practice copy, and submit the test results before and after the repairs.
• Diamond Pickaxe: Make a read-only self-test command to display the version, current status and number of applicants; do not output private information.
• Acceptance requirements: Keep the pre-repair recurrence steps, positioning basis and post-repair results; switch to a deskmate and record the operation, and you should still get a consistent conclusion.

12 / 12

Leave the evidence for the next adventure

Divide "can compile", "number rules pass" and "actual performance of the game is correct" into three columns. Scenarios that are not running are written to be tested; when bugs are discovered, trigger conditions, expected, actual, minimum repairs, and retest results are recorded.

• Explain why each arrow in this lesson points from here to there; the parallel cards have no sequential meaning.
• First change a rule, then modify the description and expectations at the same time, and retest with the same input.