Alegerea unui panou de joc după API-ul său

Majoritatea comparațiilor de panouri pentru servere de joc sunt scrise pentru omul care va da clicuri prin ele. Dacă urmează să vindeți servere de joc, nu sunteți acel om. Veți vedea panoul cam de două ori pe an, iar sistemul dumneavoastră de facturare îl va vedea la fiecare câteva minute, pentru totdeauna.

Așa că folositoare este altă comparație: ce vă lasă API-ul să faceți, ce refuză să vă spună și pe care dintre promisiunile din interfață le impune cu adevărat panoul când un client nu mai plătește.

Tot ce urmează a fost măsurat în timpul construirii integrărilor față de Pterodactyl 1.11, Pelican 1.0.0-beta38, WISP 3.7.5, PufferPanel 3.0.9, GameAP 4.4.2 și MCSManager 10.18.2, în august 2026.

Un panou lipsește în mod deliberat din tabel. AMP nu este aici pentru că nu l-am măsurat. Este un produs rezonabil, cu un API real, iar scrierea unui rând de comparație din documentația lui, în loc de din răspunsurile lui, ar fi exact genul de umplutură care sună sigur pe sine împotriva căreia argumentează acest text.

Intrarea: șase panouri, cinci modele de autentificare

Trei dintre ele au nevoie de un avertisment.

Pterodactyl și Pelican au nevoie de ambele chei, iar motivul este structural: nu există niciun endpoint de alimentare pe Application API. O integrare configurată doar cu o cheie de aplicație poate crea servere pe care proprietarul ei nu le poate porni.

Pelican acceptă o cheie de client pe Application API. GET /api/application/servers, /nodes și /users întorc toate 200 cu cheia greșită, iar greșeala iese la iveală abia la o scriere, ca o eroare de validare despre un câmp de utilizator lipsă. Pterodactyl răspunde 403 la aceeași cerere. Pe Pelican, verificarea prefixului cheii este singura cale de a prinde o pereche inversată înainte să devină un eșec derutant la aprovizionare. Pe WISP, care nu are deloc prefix, nu există nicio cale de a o prinde.

MCSManager vine cu API-ul dezactivat. O instalare nouă are enableApiKey pe fals și, până când cineva îl pornește, fiecare apel întoarce 403 „Insufficient Permissions”, inclusiv apelurile făcute cu o cheie validă a unui administrator valid. Acela este un tichet de asistență din prima zi pentru oricine nu știe să se uite. Cât sunteți acolo: MCSManager limitează și debitul la opt cereri pe secundă per cookie de sesiune, așa că un client care păstrează cookie-uri este încetinit, iar unul care le aruncă nu.

Întrebarea care decide: face suspendarea ceva?

Oricăruia dintre aceste panouri i se poate spune să suspende un server. Nu asta este întrebarea. Întrebarea este dacă un client care încă are date de acces în panou poate anula asta.

Cele trei panouri din familia Pterodactyl au o primitivă reală și nu este nimic de discutat.

MCSManager este surpriza. Nici el nu are un endpoint de suspendare, dar are o expirare: setați data de final a unei instanțe în trecut și daemonul refuză să o pornească. Am verificat asta față de panou, nu față de propria noastră protecție, cu o cerere brută, și am primit 500 Instance expired. Unable to start the instance. Aceea este impunere. Două rezerve: trebuie să și opriți forțat instanța, pentru că altfel un server care rulează merge mai departe până când verificarea orară de expirare îl prinde, cu până la șaizeci de minute mai târziu. Și dacă un client își setase propria dată de expirare, rămâne în sarcina dumneavoastră să o puneți la loc la reluare; a noastră nu o face, încă.

PufferPanel nu are nimic. Nu există endpoint de suspendare și nicio coloană de suspendare în modelul lui de date; vocabularul de stări este running și installing. Cea mai bună acțiune disponibilă este să opriți serverul și să îl omorâți dacă nu se oprește. Un client cu acces la panou poate apăsa start.

GameAP are un indicator care nu face nimic. Există un câmp blocked, iar setarea lui este doar administrativă. L-am setat pe un server SA-MP care rula, iar serverul a rămas online, răspunzând la interogări de joc în direct, și a putut fi pornit din nou din panou după aceea.

Acea distincție merită construită în propriul dumneavoastră model de date, nu netezită. Pe cele două panouri care nu o impun, descrierea sinceră a ce s-a întâmplat este „serverul a fost oprit și blocat în panou, dar o autentificare directă îl poate porni din nou”, iar asta aparține consemnării de audit a acțiunii. Consemnarea a șase panouri drept „suspendat” când două dintre ele doar și-ar dori să fie așa este felul în care un sistem de facturare încetează în tăcere să încaseze.

Crearea unui server: patru forme diferite

Aici nu există absolut niciun teren comun. Patru dintre aceste panouri modelează un server de joc într-un fel fundamental diferit, iar forma apelului de creare urmează.

Pterodactyl și Pelican vor totul dintr-o dată. Nume, proprietar, egg, imagine docker, comandă de pornire, setul complet de variabile de mediu, inclusiv cele pe care clientul nu le vede niciodată, limits, feature_limits și o alocare. Nu există creare parțială; un câmp lipsă este un refuz pe câmp. O valoare care merită știută: limits.io este validat between:10,1000, așa că trimiterea lui 0 pentru „nelimitat” este un 422 pe un câmp despre care niciun client nu va auzi vreodată. Pelican a inversat acea regulă: acolo 0 este în regulă, iar omiterea câmpului este eroarea.

PufferPanel este pe dos. Generați singur identificatorul serverului, opt caractere, apoi trimiteți prin PUT întreaga definiție a șablonului inline, pentru că lista de șabloane nu poartă variabile. Crearea nu instalează: acela este un al doilea apel. Iar ștergerea cere oprirea în prealabil, altfel primiți un 500.

GameAP creează un rând în baza de date și nimic altceva. POST /api/servers vă dă un server cu installed: 0; instalarea este un al doilea apel al cărui rezultat aterizează într-o sarcină a daemonului și nu în răspunsul HTTP, așa că interogați. Nu există ID extern și nici cheie de idempotență, iar numele nu sunt unice, ceea ce împreună înseamnă că o creare reîncercată produce în tăcere un duplicat. ID-ul întors este singura identitate pe care o primiți, așa că stocați-l înainte să poată merge altceva prost.

MCSManager nu are deloc conceptul de șablon. O instanță este o comandă de pornire, iar aceasta este toată abstracția. Există o listă de preseturi de instalare rapidă, șaizeci și trei la număr, dar niciunul nu poartă un ID: panoul potrivește pe titlu plus descriere, cincizeci dintre cele șaizeci și trei de titluri nu sunt unice, iar valorile depind de limbă. Orice se sprijină pe ele se strică atunci când clientul schimbă limba panoului.

Ce puteți vedea după aceea

Două intrări de acolo sunt mai rele decât par. GameAP întoarce 403 pe /api/nodes pentru un jeton API, așa că un motor de plasare nu poate vedea deloc capacitatea și trebuie să i se spună unde să pună lucrurile. Iar cifra de disc a MCSManager nu este doar nesigură: câmpul este declarat zero în daemon și nu i se atribuie nimic niciodată, așa că este mereu zero, pe orice instanță, pentru totdeauna.

Endpointul /resources al Pterodactyl păstrează răspunsul în cache douăzeci de secunde, ceea ce contează mai mult decât sună: interogați mai des de atât și primiți înapoi aceiași octeți, iar un calcul naiv al ratei de rețea transformă contoare identice într-o scădere care nu s-a întâmplat niciodată. Pelican a moștenit același comportament. WISP nu îl pune în cache, dar WISP nu are câmp de uptime, care este exact câmpul pe care l-ați folosi ca să deosebiți o citire proaspătă de una repetată.

Cum să alegeți, de fapt

• Aveți nevoie de suspendare care se impune și de un API real. Pterodactyl sau Pelican, dacă vreți fork-ul dezvoltat activ. Acesta este răspunsul plictisitor și corect pentru majoritatea celor care vând găzduire de joc.
• Vreți găzduire fără Docker pe mașini mici. MCSManager, și se potrivește mai bine decât sugerează reputația lui, pentru că expirarea vă dă impunere reală. Acceptați că veți primi două metrici de utilizare și nicio integrare de consolă.
• Rulați deja PufferPanel sau GameAP. În regulă, dar construiți-vă suspendarea deasupra: platforma trebuie să blocheze accesul la panou, pentru că panoul nu o va face.
• Alegeți astăzi, fără moștenire. API-ul panoului va fi constrângerea automatizării dumneavoastră ani la rând, iar două dintre aceste șase nu pot impune singura operație de care depinde cel mai mult sistemul dumneavoastră de facturare.

Ce nu este măsurat aici

AMP, cum s-a spus mai sus. Versiuni de Pterodactyl sub 1.11, pe un panou unde exact acest gen de comportament se schimbă în versiuni minore. Limitele de debit pe Pterodactyl și Pelican, care ar cere sute de cereri față de un panou viu ca să fie stabilite cinstit. MCSManager cu Docker activat, unde ar trebui să existe mai multe metrici, dar unde nu am văzut niciodată un câmp populat. Și GameAP clasic în PHP, de vreme ce panoul pe care l-am măsurat este rescrierea în Go, care diferă cel puțin la nivelul de autentificare.

Provibr integrează toate aceste șase panouri printr-un agent care rulează în propria dumneavoastră rețea; notele de configurare sunt sub Pterodactyl, Pelican, PufferPanel, GameAP și MCSManager.