Minecraft Server Setup (Development)

To give a little bit of backstory, I work in plugins related to game state and things like that. Mainly focused on the data side of game modes, rather than the game play aspect. I would work with the other developers and ask them what data they would need and how they would like it stored and retrieved.

IDE/Ease of Use

IntelliJ IDEA was perfect for Java development especially their Minecraft plugin/mod builder. It helped you skip all of the setup, if you knew what versions you were working with and such. One of the things that is a bit annoying with using Intellij, mainly while using a build tool like maven or gradle is the pain of copying the build product to the servers plugins files, or the mod to your mods folder. I have a little fix for that though; by using a gradle script to automatically move the build to your plugins folder.

Here is a build script for gradle.

plugins {
    java
}

group = "me.yourname"
version = "1.0"

repositories {
    mavenCentral()
    maven("https://papermc.io/repo/repository/maven-public/")
}

dependencies {
    compileOnly("io.papermc.paper:paper-api:1.20.4-R0.1-SNAPSHOT") // Or your version
}

java {
    toolchain.languageVersion.set(JavaLanguageVersion.of(17)) // Make sure it's the right version
}

tasks.register<Copy>("copyToServer") {
    from(buildDir.resolve("libs/MyPlugin-1.0.jar"))
    into(file("server/plugins"))
    doLast {
        println("Copied plugin to server/plugins folder!")
    }
}

tasks.build {
    finalizedBy("copyToServer")
}

Versions

Choosing the correct version is pretty important especially when working with a client. I tend to stick to LTS or popular server versions. If a client asks for anything else I’ll try to ask them to switch to something that is well-supported by the Paper and Spifot APIs and that tend to have good plugin compatibility.

Some of the things I’d focus on when picking a version is

• What version your target server runs
• Whether the APIs or hooks you need exist in that version
• If the community is actively maintaining builds for that version
• Pro tip: I would try to not use the latest Minecrat version, the moment it comes out.

Server Settings

For local development, I create seperate folders inside of my project directory called something like test-server/. This folder might contain

• A paper jar, usually specific to a version that I’m working on
• A plugins/ folder
• A basic server.properties config with adjusted settings like turning off online mode if I’m testing with weird launcher or need weird data

Here’s a typcical folder layout

MyPluginProject/
├── build.gradle.kts
├── settings.gradle.kts
├── src/
├── server/
│   ├── paper-1.20.4.jar
│   ├── eula.txt
│   ├── server.properties
│   └── plugins/

You can also if needed, create a run configuration that points to the server jar you are using to boot your dev server.

Other Plugins for Utility

PlugManX

This lets you load/unload/reload plugins on the fly without restarting the server. Super handy duing early development when you’re tweaking commands, configs or listeners.

TestPlugin (custom ones)

These are usually some custom ones I’ve wrote myself just for dumping data, triggering events or to trace things like events firing or logic paths.

Spark

I use this to run performance tests on plugins and to better understand how to optimize the plugin that I’m currently devloping.

LuckPerms

This one is obviously for permissions.

Server Startup Scripts

To save time, I always add a script to quicly launch my dev server. Here are some examples

For Linux/MacOS we use a bash script

#!/bin/bash

cd "$(dirname "$0")"
java -Xmx2G -Xms2G -jar paper-1.20.4.jar nogui

Then you can run chmod +x {nameofscript}.sh to make that an executable

For windows we can you a bat script

@echo off
cd /d %~dp0
java -Xmx2G -Xms2G -jar paper-1.20.4.jar nogui
pause

You can place this start.sh or start.bat in your servers root directory folder and run it by executing it in terminal.