野生のエンジニアたちが、サーバ跨ぎのPT募集実装に向けてアレコレ議論するスレッド

[MisatoMisa]

別にええねんけど
サーバーとかの話してるんだからサーバー名に使われている用心棒という名称は使わないほうが良いのではないかな?
と用心棒で遊んでる1プレイヤーとして書いておくでござる

たぶん用心棒は正規な意味での使い方かと。

サーバー名じゃなく………。

[noton-noton]

MMO
サーバーとクライアントは何を通信しているか？

エモート：お辞儀をする　この時何が通信されるのでしょうか？　考察してみます。

「お辞儀」でどのくらいの通信量が発生するでしょうか？　キャラクター一つのデーターなので、結構なデーター量を送っています…
ということはありません。

送信されるのは、お辞儀を「誰に」した。というデーターのみ。　数バイトが送られるだけです。
お辞儀をするという命令を受け取ったAPサーバーは、共有空間のキューに「コマンドを」スタックします。
そして、そのエリアに存在する、他のプレイヤーに対して、お辞儀するという命令（キャラクター名＋対象のキャラクター名）を送信します。

お辞儀するという命令を受け取ったクライアントは、クライアント内の３D描画エンジンに「あらかじめ用意してあるお辞儀モーション」に従って
キャラクターを動かします。　それが、他のプレイヤーの映像として表示されます。

チャット部分には「キャラクター名」情報が付与され、「○○は▽へお辞儀した」と表示されます。

（※キャラクター名は別途まとめて処理している可能性もあります）

このように、１コマンドで数十バイト（キャラクター名２名の文字列とコマンドINDEX）２０文字程度送られます。

とはいっても、これが沢山になると、とても忙しい事になります
Sモブハントでは、大量の他人のコマンドを受信します。
カクカクになるのは、クライアント側の処理が間に合わない事で発生しています。

実はここでも、通信そのものには余裕があります。
一般に通信で最大の速度が出る「ファイルのダウンロード」ですが、その時の送信量と比較すると、秒あたりの転送量で考えると導き出せます。

20Mbps　＝　2.5MB/秒
1アクションで100byteで計算
2500000/100　＝ 25000
25000/60　（1/60秒あたり）416アクション


話を募集に戻すと…

募集のクライアント側表示に関して、Sモブハントより通信量が増えるといった事はないと思います。
∴この部分に対しての心配は無用です。

[Theel]

パスワードPW式が一番現実的な気がしなくもないのですが。
Notonさんは「共有部分が…」と言っていますが、意味がわかりません。

パーティチャットの部分なのですかね？
現行のIDでは、インスタンスエリアIAに入るまではチャットが有効にならない感じですが、それを超えて鯖横断でチャットができるように、となると、そもそも論として現状には無い、新しい仕組みが必要のように思えます。

PW式の場合、PTの条件、その他諸々については「チャットアプリ（仮）で既に解決済み」とすることができ、ゲーム内においては「PTを最終的に組むかどうか？」だけの判断で済むわけで、PTチャットも現行通り、IAに入ってから行う方式で問題なく（それ以前の問題はチャットAP（仮）で解決済みと見込む）、「PWでPTを作るかどうか？」の部分だけを新設すればいいように思います。

チャットAPに関しても、公式でサポートすると不適切な発言等を監視しなければならない手間もあるでしょうから、LINEでもロビでも既存のAPを利用できるようにし、公式では最低限「PWによるPT認証」の仕組みだけをサポートすればいいことになります。
そもそも鯖越えPT募集は、個々の鯖に縛られるモブハンやFATE、FC募集、CFやユーザーEV等では必要とされず、CF非対応のコンテンツに限れられるわけですから。

外部APでメンバー募集→条件その他で合意→

『募集主がPWを教える→そのPWを元に参加者が申請→合致していたらPT作成（ただしIAに突入するまではチャット不可。シャキ後のメンバー同意待ち状態）』
↑ここを新設。

→PTメンバーが全員揃ったらIAに突入→「よろおつ」

[Theel]

つづき


ゲーム内としては、PWが合致しているかどうか？　を判断すればよいと思います。
それでも極論では募集板にアクセスできる全てのプレイヤーが問い合わせをする可能性がある、と見込まざるを得ず、それを制限するためにパスワード認証は1分（3分？）のインターバルが必要ということで。
合意済みのはずの人がアクセスするだけですし、何らかの手違いがあったとしても（主の勘違い等？）、認証が1～3分間隔でも、実用上ほとんど影響は無いものと思います。

私自身は、
「なるべくコストをかけない実装」→「『零式を（既に実績のある）CF対応に！』と、どれだけ違うのか？」

痒いところに手が届くPT募集→「面倒くさい割に、事実上、零式PT募集くらいでしか使われないのに、そんなにコストをかける意味があるのか？」

というスタンスです。
その中間に鞍点があるのでしょうが、どうせ専門系のスレに移行したのなら、その辺まで考えてみましょう、と思います。

[aqua_steve]

たぶん用心棒は正規な意味での使い方かと。

サーバー名じゃなく………。

?
だからややこしいから使わないほうがいいんじゃないかな?っていう話ですよ

[MisatoMisa]

?
だからややこしいから使わないほうがいいんじゃないかな?っていう話ですよ

まぁお手伝いとかそういう例えだと良かったですね。

自分は用心棒と言えば時代劇連想ですが…………。

[noton-noton]

>Theel さんへ
＞共有部分
APサーバーは、負荷を減らすために複数台から構成されますが、ワールドサーバー（エリアサーバー）は、それらのAPサーバーから見て１つの情報を共有します。

チャットですが、おそらくこのワールド毎にメッセージキューを持っています。

例えば、リムサにアクセスしているユーザは、リムサメッセージキューからメッセージを受け取ります。
IDの場合は、IDにあるメッセージキューからチャットメッセージを受け取ります。

IDサーバーはグループ共通でアクセスできるようになっていと思われます。（CFやFLで他サーバーの方と同居できる）
メッセージキューはそこにあるため、異なるサーバー間でチャットが届くようになります。

IDと同じ仕組みで小さなエリアを作成。
PT予定者の位置情報を切り替えることで、PTのメンバーはメッセージをそのエリアのキューから受け取るような動きにできるでしょう。
他の仕組みと差異はありません。

尚、PTはPTでメッセージキューを持っていると思います。


＞私自身は、「なるべくコストをかけない実装」→「『零式を（既に実績のある）CF対応に！』と、どれだけ違うのか？」

私も同じような形を最小の拡張で済むような方法を、最初に提唱したのですが、いまひとつの反応だったので、もう少し色々と考えて方法を提案している所です。


＞用心棒
そこに指摘が及ぶとは思いませんでした。
ここでは仮の名称なのでご了承ください。

[HarukaPhilantha]

要件定義では認識の齟齬がないように言葉とかをしっかり確認するのは必要なことですね。


それはさておき、要件定義まだなのに、設計フェーズに移ってる気がしてモヤモヤするのは私だけでしょうか。

サーバー跨ぎの募集板に関連する
・チャットができる必要性はあるか
・（事前に）PT組む必要があるか
等々の検討がおいてけぼりになってるような。

[noton-noton]

F-DUCT　さんへ
ご意見ありがとうございます。

私は現在、２つの方法を提唱させてもらっていますので、CF拡張の方法の説明をします。

募集側　
・UIは募集板を拡張したものを利用する
・ローカルの募集と並行して募集ができる
・FULLパーティのみ利用できる

応募側
・CFに登録する時に、追加の条件をセットする

マッチング
・全員が揃ったら、即開始される。


メリット
・１～２名足りない時など、補充用途に使いやすい
・応募側もローカルで募集が無い時でも、呼ばれる可能性がある
・応募側は募集を待つ間の拘束が比較的軽い
・ハードウェアの追加もおそらく最小で済む

デメリット
・事前に打ち合わせができない（CFと同じ問題）
・プリセット以外の細かい条件を設定でいない。
・時期（混雑時）には利用できない場合もある（アクセス調整）

HarukaPhilanthaさんへ
ご意見ありががとうございます。

＞サーバー跨ぎの募集板に関連する
・チャットができる必要性はあるか
・（事前に）PT組む必要があるか

まずはDCセンターを跨ぐのか？
グループをまたぐのか？

レンジを決めることが必要でしょうね。
個人的見解ですが…

まずDCを跨いでの募集機能は、技術的な話は別にして不要だと思います。
折角、言語が違うプレイヤーを隔離しているのに、
エンドコンテンツという、コミュニケーションが必要な環境に於いて、PTが組めるメリットがない。と思います。

GPサーバーを超える接続は、現状物理的なネットワークも遮断されているのではないかと推測します。
（正しくはゲームに必要な高速回線での接続）

よって、レンジ（募集の範囲）はグループサーバー内のみ　と限定しても良いと思います。


事前のチャット、事前のPTについて

・完全に開始できる状況になってから、突入前に時間を区切ってPTを組む事は可能。というのを提案します。

理由は、少し前にコメントしましたが、「固定の遅刻のキープの為に使う」といった、募集側に不利な用途で使われる可能性がある為です。
完全に揃わない状況でのPTの仮組をしないというのは、応募側（傭兵側）からすると、理不尽な内容でPTが一方的にキャンセルされたりするのを出来るだけ避ける為です。

私が提唱した、２案目では、直前でのPTの会話を実現した形で提案していますので、ご検討ください。

[HarukaPhilantha]

引用割愛させていただきました

ご提示ありがとうございます。

サーバーレンジについては、運用メリット・コストメリットがはっきりしてますので、GP内でという方向性で問題ないと思います。

PTおよびチャット機能については、技術的に可能であることはわかりましたが、その機能がないことによるデメリットと開発コストとのバランス関係がいまいちわからないため、判断がつきかねます。




ってココまで書いて思ったのは、クライアント（発注）側の立場がいないとやりづらいんだってことですね。
↑のは思わずクライアント側に立ってしまいましたが。