GMCP

GMCPはtelnetオプション201です。ネゴシエートが済むと、サーバーは構造化データを帯域外で送れる ようになります。パッケージ名とJSONのペイロードが、テキストと同じストリームで届きますが、テキストの 一部ではありません。

Char.Vitals { "hp": 412, "maxhp": 500 } が定番の例です。クライアントはこれだけで体力バーを動かせて、 文章から数値を拾い集める必要がありません。それがこのプロトコルの要点そのものです — テキストの パターンマッチで作ったステータス表示は、ゲームがプロンプトを変えた日に壊れますが、GMCPで作ったものは 壊れません。

パッケージの名前空間は標準化されたものではなく、慣習によるものです。Char、Room、Comm、Client は広く使われていますが、そこから先はゲームが必要なものを考え出すので、あるゲームが何を送ってくるかは、 たいていクライアントに教えてやる必要があります。

ATCPに取って代わった理由

GMCPはATCPの後継です。ATCPは同じ仕事を、より緩いペイロード形式で こなしていました。改良点はJSONで、移行は2010年代半ばにはおおむね完了していました。両方に対応する ゲームは珍しくありませんが、ATCPだけに対応する新しいゲームは珍しいでしょう。

当サイトが実測するもの

ここに数えられるのは、当サイトが観測したハンドシェイクで、そのゲームのサーバーがGMCPを提供した 場合です。これは、ゲームのMSSPがGMCP 1と述べていることとは別の主張です。このホビーのプロトコル表の 大半は後者を土台にしていますが、両者はしばしば食い違います。

当サイト自身の経緯から、実測についての注記が1つあります。ある時期、MCCP も併せてネゴシエートするサーバーでは、GMCPが見えていませんでした。当サイトのtelnetライブラリが圧縮を ネゴシエートしながらストリームを展開しておらず、圧縮の開始位置より後はすべて雑音になっていたためです。 調査したサーバーのうち少なくとも1つは、実は最初からGMCPを話していたことが分かりました。よく知っている 系統についてこのページの数値が低く見えるなら、まず疑うべきはこの種の欠陥です — 相手側ではなく、 当サイトの側の。