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

[Seev]

～->どの程度まであきらめて、逆にどの程度を確保するのが望ましいでしょうか？～

大まかなイメージですが、おおよそ５分程度と想定していました。
５分以内にすぐ集まる募集ならそもそもサーバ内でも十分集まるでしょうし、
外部サーバに依頼を投げるということは数分を争う事にはならない募集だろうなと。

（略）

ありがとうございます。楽しんでいただけて救われます（ｗ

（略）

「リアルタイムではない」というキーワードについて回答を。
私の想定では「マッチング処理」そのものはCFサーバが行いますので、申請した結果弾かれるかどうかは即座に反応があります。
非リアルタイムなのはあくまで募集サーバに書かれている掲示についてですね。
　「アルバイトの掲示があったから電話をかけたけれど、実はその掲示は古くもう募集していなかった。」
って感じで、申請結果そのものは即座に返されるイメージをしていました。

が、しかし

実は昨日書き込んでから、重大なことを忘れていることに気付きまして……

　PT募集プロセス（誰がどんな募集してるとか残り時間とか）

そう。ここにPT募集のとても重要な機能。「下限IL」と「指定ジョブ」によるフィルタリングがあることを完っ全に忘れていました。

これを実現するには、当然PT募集機能の中にフィルタリング処理を埋め込まなければいけないのですが、募集要項がリアルタイムで無いとすると誰がやるんだって話ですね
これを行うにはCFの隔離空間側でフィルタリング処理を行わざるを得ず、こんなイメージに



なんと、想定していなかったIL,JobフィルタリングがCF側に実装必要に。
これではCFに対してあまり改修が要らないとは言えない……

よし、ならば！（やはり続きます）

[Seev]

厳密なフィルタリングと即時性を両立させるのは同期や即時の更新処理が必要になるので、
「募集サーバはスモールに」という当初の想定は忘却の彼方。募集サーバに機能を詰め込みます。

まず募集サーバを「募集掲示」を行う機能と「PTマッチング」を行う機能に分割。
募集要項はもちろん募集掲示サーバに載せ、PTマッチングサーバと同期を取りながら要項を記載。
（携帯から確認機能の夢はそのままに……）
応募者はWorldサーバ経由で直接申請し、マッチングサーバ上でPTを編成（IL,Jobフィルタもそこへ実装）。
PTマッチングサーバは極小規模なIDと同等であり、PTチャット等が行える仕組みとします。

・イメージ図
(*)まずはクライアント2が募集PTを作成
(a)要項の一覧確認は募集掲示サーバを閲覧
(1)要項を元にPTマッチングサーバへ申請、フィルタリング処理後PTへ加入
(2)マッチングサーバ内でPTが集まり次第CFへ。即シャキーン



CF側は全く改修が必要ありませんが、見事に募集サーバが大規模化しました。
そしてこれをご覧頂いた方のいくらかがこう思ったことでしょう。

「"それ"、ロビーサーバーじゃね？」

仰る通りでございます……。

※あえて言えば、まず全員がロビーに集まってそれから募集をかける一般的（と私が思っている）なロビーサーバーではなく、
　条件に応じた空間を作り、賛同した方がそこへと入室していく「ルーム」と言った方がイメージが近いでしょうか。


私はあまりエンドコンテンツはやらないので、どちらかと言うと過疎コンテンツに人を促す目的としてPT募集を考えていました。
なので、それに関しては募集掲示サーバにメッセージを載せて、「みんな、CF行こうぜ！」程度で良いのかもしれません。

更に続きます。（ごめんなさい。まとめだけ……）

[Seev]

ということで、私の意見だけでもがらりと変わっていきましたが、
どれかに限定するというものでもなく、それぞれ組み合わせるのもよいですかね。
どれだけかかるかわかりませんが、以下のような使い分けができれば理想的でしょうか。

１．既存のパーティ募集機能
サーバ内で完結する事項や、密なやり取りを行うための勧誘。イベント等の募集
　「Sモブハント緊急募集！」
　「零式攻略固定メンバー相談」
　「クリスマスパーティのお知らせ」

２．PTマッチングシステム
同DC内に向けた不足要因や、細かな条件を指定した幅広いPTの募集システム
　「１層攻略、ヒラ募集」
　「初見と行く。新IDゆっくり進行」

３．CF募集掲示システム
とりあえず目的のCFにほかの人を誘導するシステム
　「みんな～クリタワ行こうぜ！」
　「アティンさんがシャキりません。ヘルプミー」

といったところで以上です。

※なんか勝手に総括してるみたいになってますが、二転三転した私の提案をまとめてるだけなのであまり気にしないでください！
　今日の提案は負荷問題を完全に無視していますので、あまりスレッドの意図に沿ってないと思います。
　とりあえず思ったことをいろいろ吐き出しているところですので、まとめてくださってるbtkさんは参考程度に（汗
　みなさんの提案はゆっくり読んだ後、またいろいろ意見・質問させていただきます

長々と失礼しました m(_ _)m

[HarukaPhilantha]

CFの手動マッチング


って表現がしっくりくるのではないかと思う今日この頃

現行CFは、どのIDに行くかというIDをキーにマッチングされますが、それを募集板に応募したという情報をキーにすればよいわけで。
だとすると、板データもCFサーバーに保持されるのが自然かな。

追加仕様として、募集からのマッチングの場合は、シャキった時の時間を無制限にするか、長めにとるかというとこですかね。
45秒だとサービスレベルが低下するので。



現行募集板と変わる点は、応募してすぐにPTが組まれないってことですね。
むしろ、サーバー間募集のネックはそこにあると思ってます。
これはサーバー内募集でもそうなって差し支えないかと。

[noton-noton]

＞Seev　さんへ
レベルやフィルタリングをどうするか？　ということでサーバーの構築まで検討されているようですね。

対応策としてですが、現状の構造を変えることなく検索されるデーターの構造の追加で済むと思います。

・レベル情報はルーレット等の動作から、すでに検索項目、マッチング情報に含まれていると思います。

・エンドコンテンツ向けの追加情報に関しては、新規にテーブルを追加する（またはカラムを追加）
（DBを想定していますが、オンメモリならデーター構造体に追加する事になるでしょう）


作業の流れ

「通常のCFのマッチング処理」（拡張CF用データーは除外）
　　　　終了
「拡張CFのマッチング処理」　（拡張CF用データーのみ）
　この時に、拡張された部分を含めてマッチングする　　　＜この部分のプログラムで対応

このように処理を２回に分ければいいと思います。
CFサーバー上で処理を行うのは、既に、サーバー間ネットワークが接続されているサーバーだからです。

[noton-noton]

募集側については、今までの提案をベース（ローカルとワールドを同時に募集できる）という仕様を残しつつ、もう少し拡張を考えてみたいと思います。

CF側の登録について、既存のCFに追加情報を入れて待つ　という部分ですが、ここを以下の様に変更します。

ルイー〇ーの何とかというエリアに入る。
入る時に、対話形式で目的要件を選ぶ

この処理が終わると、「クライアント側に、検索条件が作成される」
内部の募集板を参照する、先ほどの検索条件に条件を絞られた募集が表示される・

募集を選ぶ、部屋の中で揃うまでまつ

------------------------------------------------------------------------------
メリット、
募集を参照するときに、最初から条件が絞り込まれた募集一覧を表示する事が出来る。
（参照数の減少）
わざわざメンドクサイ処理「特定の場所への移動」を挟む為に、意味もなく閲覧者が増えることを防ぐ
（参照数の減少）
一般の募集板閲覧と隔離することで、参照数を減らす事が出来る
（参照数の減少）

デメリット
募集を選ぶことができる為、募集元の都合でキャンセルされた場合などの、理不尽な事も知ってしまう事になるストレス
（不利益情報の認識によるストレス）
募集が埋まるまでは何もできない。
（クラフター作業をしたくても、マケボ・リテイナーが呼び出せない？　）

募集が見えてしまう事で、かえってストレスが貯まるのではないか？
という問題がありますね。。

[noton-noton]

追加仕様　（必須）

メンバーが揃ったら、強制的に開始処理に移行する

・理由　以下のような悪質な利用法が出来る為

固定の一人が遅刻しそうと連絡があった、取りあえずワールド募集で登録　枠が直ぐに埋まるが、時間がたっても始まらない。
そのうちに遅刻のメンバーが予定より早く到着、一旦募集をキャンセルして、再編成してスタート

遅刻メンバーの保険の為に利用されたプレイヤーは、何だこれ？　となるでしょう。

同様に、人数が欠けた状態の募集も同様な問題から、不許可にしないと不味いですね。
（一人だけ募集など）

このへんは、ネットワークの制限というより、鯖を超えてPT募集をした場合に考えられる問題点として別途に考えなければならないと思います。

[MoMoN]

期待　
頑張ってください

[noton-noton]

このスレを読んで貰う為にｂ

このスレッドを前のスレから書き込んで、色々なご意見を頂いていますが、何となくですが簡単に説明しておいた方が良い内容があるのではないか？
と思う事があります。
簡単にですが、技術的な説明をしたいと思います。

「通信」「量」

ネットゲームの話をしていると、通信が重い！とか、このスレでも「通信量が増える！」等の話がでます。
通信とはなんなのか？　簡単に説明します。

大きく分けると、「サーバーとクライアント間」「DCセンター内のサーバー同士の通信」と言えます。

一般には前者が話題になるのですが、このスレでは後者が主に話題になります。
同じ通信　という言葉を使うので、混同してしてしまいます。


一般にゲームでは、WEBなどと違って、常時接続されています。
何もしてなくても、別のキャラクターが動いているのが見えます。リアルタイム処理されている通信で実現できています。


ラグが酷い！
原因の殆どがサーバーとクライアントの通信の問題です。

処理が重い
モブハントに行くと体験できますが、通信量が増えて、クライアントが描画処理が追い付かない状況です。

鯖間募集が実装されると、通信量がふえる？
サーバーとクライアント間の通信は変化しないでしょう。
この処理では、サーバーとサーバーを連絡している通信が発生し、色々な方が懸念されてる諸問題が発生する可能性があります。

パケット
一般にTCP/IPというプロトコルで通信が行われていますが、「パケット」は通信の時に、データーを細かく分けて送信する時の１データー単位です。
通信するサイズによって、パケット数が増えます。

多くのサーバーでも、この方式が取られていますが、サーバー間通信では、データーをパケットに分離して送る方法は無駄が多いので、
特に速度が求められるシステムでは、光ファイバーを使って効率の良いファイル転送を使います。

FF14のシステムがどうなっているかはわかりませんが、おそらくこれらを導入しているでしょう。
「パケット」という言葉は出てこないと思われます。

[Seev]

（略）

noton-notonさんの案では、CF内でより細かな条件付を行ったマッチングを行う。といったものになるのかと思われ、
これは「零式に行きたいけど後一人足りない。既に白がいるから学or占限定で募集したい」といった状況には有効かと思うのですが、
その募集の空き枠に入ってくるのは、あくまでCF上に登録した指定ジョブの人が自動的にマッチングされてくるのですよね。

目的を絞った募集、「初見の人のみで○○行こうよ」とか、「○○出来る人募集」といった、コメント上の条件を伴った募集には使えない点が気になっています。

あと、少し懸念するのは細かな条件を持つ以上、当然ながら不足ジョブは優先的にマッチングが行われます。
先程の例で「白が過多、学占が少ない」といった状況にあった場合、「普通のCF行くと白白ばっかり！」といったような、ジョブの偏りが発生しないでしょうか
もちろん現状でも人口の多いジョブに偏る事は十分あるので、表面上の確率はあまり変化無いように思うかもしれませんが
「特定のジョブが足りない固定PTの募集が毎日」といったケースもあり、通常のCFでマッチングされるのは過剰供給の同ジョブばかりといった傾向が出てしまうといった不安もあります。
（もちろん、より高機能な募集システムができれば人気ジョブはそれに集中してCFは余りばかり。となる可能性もありますので、どこまでいっても程度問題ではありますが）

※追記

また、現状のCFにデータ構造を追加することで簡易に実現出来るといった案ですが、
確かにCFを少し拡張するようなレベルであれば問題無いようにも思いますが、
私の提案は目的に沿った掲示に乗っかっていくスタイルなので、それに比べてデータ量は肥大化すると思います。
（募集内容やコメントを確認するための通信オーバーヘッド、一時的なPTの置き場、事前に会話するためのチャットシステムなど）

といったことをいろいろ考えていると、「データ量の追加」「ロジックの追加」が現状のCFに悪影響を与えないかの自信が無く、
そのため、可能な限りCFには影響を与えないようサーバ追加の案を提案したのですが、上記の通りあまりに巨大化しすぎました（泣