プロキシプラグイン ジェネレーター
プロキシプラグインを生成するメリット
目的に合ったAPI
プロキシのコードはBukkitのコードとは別物です。ジェネレーターは、解決できないサーバー側の呼び出しを出力せず、プロキシ独自のイベントモデルと接続APIを使います。
ネットワーク全体を前提にした設計
すべてのバックエンドサーバーのすべてのプレイヤーを把握できる1つのプラグインです。待機列、グローバルチャット、スタッフへの通知、振り分けルールに最適な場所です。
必要なら両方を生成
ネットワークの機能の多くは、プロキシプラグインと、プラグインメッセージングでつながる小さなバックエンド側プラグインの組み合わせが必要です。全体の流れを説明すれば、Codexeが両方を生成できます。
バックエンド向けをお探しですか?
ゲームプレイ、ブロック、アイテム、ワールドのイベントはすべてバックエンドサーバー側にあるため、Spigot、Paper、Foliaのプラグインになります。Kotlinがお好みならKotlinプラグインも選べます。どの種類のコードをどこに置くかはプラグインのドキュメントで説明しています。
プロンプトの例
プロキシプラグインジェネレーターのFAQ
プロキシプラグインと普通のプラグインは何が違いますか?
+
プロキシプラグインは、バックエンドサーバーの手前に置かれるBungeeCordまたはVelocity上で動きます。ワールドもブロックもエンティティもなく、APIが扱うのはプレイヤー、接続、どのサーバーに振り分けるかです。ゲームプレイに関わる処理は、バックエンドサーバー上で動くBukkit系のプラグインにする必要があります。
BungeeCordとVelocityは同じAPIですか?
+
いいえ。解決しようとする問題は同じですが、APIもイベントモデルもプラグイン記述子もまったく異なります。プロンプトでどちらを対象にするか伝えてください。片方向けに書かれたコードは、もう片方ではコンパイルできません。
プロキシプラグインでブロックを変更したりアイテムを渡したりできますか?
+
直接はできません。プロキシはワールドの状態にアクセスできないためです。一般的には、プロキシプラグインと、各バックエンドサーバー上の小さな連携プラグインをプラグインメッセージングでつなぎます。その構成を説明すれば、Codexeが両方を生成できます。
プレイヤーを別のサーバーに送るには?
+
プロキシのconnect APIを使います。まさにこの対象のためにある機能です。生成されるコードは、サーバーの検索と、送信先がオフラインだった場合の処理まで行います。
プラグインメッセージングのチャンネルにも対応していますか?
+
はい、頼めば対応します。プロキシとバックエンドが互いに何を伝える必要があるかを説明すれば、ジェネレーターが両側のチャンネル登録とメッセージハンドラーをつなぎます。
どちらを使えばいいですか?
+
Velocityは新しい選択肢で、高速で、開発が活発で、APIもすっきりしています。BungeeCordは古いものの今も広く使われているので、ネットワークがすでにBungeeCordで動いている場合や、BungeeCord専用のプラグインに依存している場合はこちらを選んでください。
ほかのCodexeジェネレーター
Need something that runs on the backend servers instead of the proxy? Codexe also generates:
Codexeがこれらのプロジェクトをどう作って確認するか、リクエストに何を書くか、よくある問題について: BungeeCord and Velocity proxy pluginsガイド。