A plain guide to my Java lab. Story papers stay short. The tooling lives here so the main read is not a method dump.
1. What “I tested” means
When a playtest says I checked something in Java, I mean the game actually ran. I start a vanilla Java dedicated server for a locked version (today that is often 1.21.8). I set the seed and rules up front. Then I force the world to build the chunks I care about.
After that, scripts I wrote read the saved world files or log what happened in the run. The answer on the page comes from those counts, not from guessing.
2. What tools did I build?
Think of a small workshop next to the game:
- World runners — shell scripts that start
server.jar, accept the EULA, set the seed, and force-load a block square so chunks exist on disk. - Scanners — Python tools (I use libraries such as amulet-core) that open region files and count ores, neighbors, or other blocks.
- Trial harnesses — for some tests, scripts that repeat the same action many times (portals, travel, and later player bots) and write each trial to a table.
- Locks — a
METHOD_LOCKED.mdandVERDICT.jsonnext to the CSV so the page numbers cannot drift from the run.
I did not hand-count a thousand chunks by eye. A computer ran Minecraft and my scanners read what the world made.
3. What stays on the story page
Playtest papers still say I tested, and what I tested, in plain words. They show one or two big results. Full tables and seed lists sit in a collapsed “numbers” box.
This page is the home for “how the lab works.” Link it from Sources when you want the workshop tour without slowing the story.
4. Examples already on the site
- Diamond chunk count — server + scanner on four seeds.
- Five ores on cave walls — same worlds, multi-ore scanner, Nether force-load.
- Brand-new Nether portals — measured first creates and landings.
Most playtests today are Java only. Bedrock worldgen is a different lab. One seed is never “all of Minecraft.” I say the sample on every playtest page.
