Skip to content
Panludia
Shape new worlds

THE SYSTEM BEHIND THE SPEED

The forbidden
method™

How the Panludia team turns community decisions into maintained game integrations with powerful AI-assisted development tools.

The community decides what should exist.Panludia's harness makes it possible.
Open the machine See the projects
METHOD / LIVE PIPELINEJOB PW-BOSS-LOCATION
ACCEPTED BY COMMUNITY

A Palworld boss becomes a location.

First victory should send one Archipelago check. Exactly once.

01Decision02Compute03Real game04Verified
Visual proof + server assertionREADY FOR PREVIEW
03compute workers02isolated play workersZDRremote model accessALLsignable executables signed

01 / THE HUMAN DECISION

AI builds the implementation.
It does not design the game.

Players decide which moments belong in the multiworld. Panludia turns that decision into a contract that software can implement and tests can verify.

THE COMMUNITY

Owns the gameplay

  • Requests missing or replacement integrations
  • Chooses locations, items, goals and presets
  • Discusses progression and balance in public
  • Settles gameplay choices by majority
  • Tests previews in real playthroughs
THE PANLUDIA TEAM

Owns the delivery

  • Turns consensus into explicit test targets
  • Provides context and starts the right workers
  • Arbitrates technical constraints
  • Reviews important results and preview builds
  • Authorizes stable releases
MAJORITY ACCEPTEDPALWORLD · LOCATION PROPOSAL

A Palworld boss

Community intent becomes one observable rule, without letting the implementation redefine the idea.

When this boss is defeated for the first time, send its Archipelago location check exactly once.

Feasibility informs delivery, not design. Before implementation, agents can identify what an existing modding API exposes, what needs deeper runtime investigation or injection, and what appears unstable or disproportionate. Panludia uses that analysis to plan the work; the agents do not replace the community's gameplay decision.

02 / INSIDE THE MACHINE

Not one prompt.
A working system.

Specialized models operate inside dedicated workers with access to research, code, builds, logs and real game environments. The models can change. The harness is the method.

DEVELOPMENT SIDE

3 compute workers

Remote reasoning, research and code models. No vision.

NO LOCAL GPU
W-01researchW-02code + buildW-03runtime tests
  • Web and technical research
  • Code, packaging and logs
  • Reasoning and feasibility
  • Non-visual runtime checks
QUEUED JOBBuild + scenarioExpected behaviourAssertions
RESERVE AVAILABLE RIG
VALIDATION SIDE

2 isolated play workers

Launch the purchased game and verify the integration.

GPU
P-01RTX 5070 TiP-02RTX 5070 Ti
  • Official Steam game copy
  • Dedicated vision model
  • Separate computer-use model
  • Real internal AP server
AUTOMATIC RETURN

Logs, screenshots, runtime state and deterministic assertions go back to the compute worker that requested the test.

SCREEN CAPTUREPROCESS LOGSSERVER ASSERTIONS
CAPABILITIES, NOT CELEBRITIES

Several kinds of intelligence cooperate.

No provider or model is the method. Each capability has a narrow job and can be replaced as the stack evolves.

ReasoningInvestigate undocumented behaviourCodeImplement and repair componentsResearchFind APIs and technical contextVisionInterpret the game screenComputer useOperate the game interfaceInternal LoRAHandle specialized tasks
All remote model access is configured with zero data retention.
What the playtest harness can actually doConcrete controls available when the game and its modding surface allow them.
  • OperateControl keyboard and mouse, and act in game interfaces.
  • RunLaunch, monitor and stop the game, mod and client processes.
  • ConnectJoin a real internal Archipelago server and observe the protocol.
  • InjectReproduce events or conditions for a focused technical test.
  • ObserveCapture the screen, logs, runtime state, items and locations.
  • RegressRepeat covered scenarios and return evidence automatically.
Inspect the infrastructureHardware exists to run the process, not to be the headline.
PER COMPUTE WORKER · ×3

Development node

CPU
AMD Ryzen PRO 3600 · 6 cores / 12 threads · 3.6 GHz
Memory
32 GB
Storage
2 × 1.02 TB NVMe
GPU
None · powerful remote models
PER ISOLATED PLAY WORKER · ×2

Real-game validation rig

Compute
12 dedicated CPU threads · 64 GB memory
Graphics
GeForce RTX 5070 Ti · 16 GB GDDR7
Storage
200 GB allocated NVMe
Environment
Dedicated Steam account, purchased game, AP client and internal server
Physical playtest hostIntel Core Ultra 9 285 · 24 cores / 24 threads · 128 GB DDR5 ECC On-Die · 2 × 2 TB NVMe · 2 × RTX 5070 Ti 16 GB

03 / FOLLOW THE CHECK

One boss.
Two kinds of proof.

A compile is not evidence that a mechanic works. So the implementation leaves the development worker and travels through the real game.

01Boss victory02Game event03Game mod04AP server05Location assertion
VISUAL EVIDENCE

The game shows the victory.

The vision model observes the expected state on screen, while the harness records evidence from the running game.

Screenshot attached
DETERMINISTIC EVIDENCE

The exact check reached the server.

The internal Archipelago server confirms the correct location once, independently of what the screen appeared to show.

Assertion passed · count = 1

Vision where necessary.Determinism wherever possible.

IF IT FAILSEvidence returns to the compute workerANALYSEInspect code, state and logsREPAIRBuild the next iterationRETESTSubmit another play job

04 / TRUST THROUGH ITERATION

Machines verify the contract.
Players validate the experience.

Automation can prove a precise behaviour. It cannot prove that an entire multiworld is fun, balanced or free from every unexpected interaction.

AUTOMATION CAN CHECK

Does the mechanic work?

  • Compilation and packaging
  • Game and mod startup
  • Archipelago connection
  • Items sent and received
  • Locations triggered
  • Observable game-state changes
  • Covered regressions
PLAYERS MUST JUDGE

Does the integration feel right?

  • Fun across a complete seed
  • Progression and item pacing
  • Natural routes into each event
  • Unexpected mechanic interactions
  • Difficulty and preset balance
  • Installation in varied setups
  • Whether it is ready for normal play

An injected condition validates a technical contract, not a complete playthrough. We do not replay an entire game after every change. A regression has already reached a playtest after earlier checks passed, which is exactly why previews and human play remain part of the method.

05 / RELEASE, LEARN, REPEAT

Playable in minutes.
Trusted through iteration.

A first playable build or feedback-driven iteration can exist within minutes when the target is clear. A trustworthy integration emerges through tests, real sessions and maintained releases.

PREVIEWFast volunteer iterationPLAYTESTReal seeds, real playersFEEDBACKBug, balance, compatibilityNEW BUILDImplement and verifySTABLECommunity + Panludia approved

Stable means suitable for normal play based on the evidence available. It does not mean perfect, finished forever or exempt from future maintenance.

MAINTAINED HISTORY

AI accelerates the work.
Forgejo preserves its history.

Every published project remains versioned, documented and reviewable on Panludia's dedicated Forgejo instance.

Versioned codeRelease artifactsChangelogs + docsPreview + stable
CODE SIGNING

Generated quickly.
Released properly.

Every signable executable distributed by Panludia is protected with a code-signing certificate, so its publisher and post-signature integrity can be verified.

Signing proves identity and integrity, not perfect software.

Built to fit each game:.apworld packagesgame modsclients or connectorsautomated testsbuild toolingdocumentation

THE METHOD, IN THREE LINES

The community decides what should exist.
The harness makes it possible.
Players decide when it is good enough.

Models are replaceable. A maintained system of people, workers, real games, evidence and iteration is not.