Przejdź do głównej zawartości

Podłączanie klienta

Ta sekcja jest dla osób, które piszą własnego klienta albo konfigurują istniejący. Do samego grania nie jest potrzebna — wystarczy przeglądarka.

TransportPortDla kogo
telnet9600Mudlet, TinTin++, MUSHclient, telnet, własne klienty
WebSocket9601, ścieżka /wsprzeglądarka i wszystko, co mówi po WebSockecie

Oba prowadzą do tego samego świata i tej samej postaci. Różnią się tylko sposobem pakowania danych.

Serwer sam zaczyna negocjację i proponuje:

OpcjaNumerPo co
GMCP201strukturalne dane obok tekstu
MCCP286kompresja strumienia
SGA3tryb bez „go-ahead”, potrzebny do sensownej pracy
NAWS31serwer pyta o rozmiar twojego okna
TTYPE24serwer pyta o typ terminala

Serwer oferuje GMCP, MCCP2 i SGA (WILL), a prosi o NAWS i TTYPE (DO). Klient odpowiada DO/DONT i WILL/WONT jak w zwykłym telnecie.

Sterowanie echem (przy wpisywaniu hasła) idzie zwykłym IAC WILL/WONT ECHO.

Tu nie ma negocjacji — GMCP działa od razu. Ramki to JSON o jednym kształcie:

{ "type": "input", "text": "spójrz" }

Pole type decyduje o reszcie:

typeKierunekPozostałe pola
inputklient → serwertext — komenda gracza
textserwer → klienttext — zwykły tekst gry
gmcpobapackage i data
echoserwer → klientenabled — czy pokazywać wpisywane znaki

Pakiet GMCP wygląda więc tak:

{ "type": "gmcp", "package": "Char.State", "data": { "hp": 5 } }

Kolejność mniej więcej według opłacalności:

  1. Room.Info i Room.Players — mapa i lista obecnych bez parsowania opisów.
  2. Char.State — pasek życia. Pamiętaj, że przychodzi częściowo: scalaj, nie podmieniaj.
  3. Objects.Data — klikalne cele. Tu jest pułapka z uid, przez którą przeszedł też nasz własny klient webowy.
  4. Char.Items.List — ekwipunek na żywo.
  5. Comm.Channel.Text — osobne okno na rozmowy.

Wszystko leci w UTF-8, łącznie z komendami. Klient, który tnie do ASCII, będzie działał — gra przyjmuje spojrz tak samo jak spójrz — ale opisy świata zrobią się nieczytelne.