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

[noton-noton]

btk さんへ
まとめどうもです。

私からは２つの方法を提示しています。

●従来の募集とCFを同時に募集ができ、CF機能を使う場合は、任意選択、マッチングはCFに委任
・他鯖の募集の閲覧がそもそも無いため、当初の最大の懸念点を根本から取り払っている
・固定補充等に最適
・CF登録側にも、ある程度のマッチング条件を入れてもらう。
・こういった仕様の為、細かいマッチング条件は設定できない。

●募集側を閲覧するのではなく、応募側をPT側からスカウトするような形にする
・これもPTの参照を仕様から取り除くことで、最大の懸念点を払拭
・そのかわりに、個人を登録する募集板を作成
・登録されたデーターはキャッシュに最大限の効果があるため、通信問題の軽減が可能
・募集先・目的など、最初から分割して参照の入り口を作ることで、負荷を分散可能
・個人掲示板の作成、PTからピックアップするなどの、新規機能が必要
・使い方によっては、サーバーを跨って「固定」を組むことが可能

ご検討ください。

[noton-noton]

今回のスレッドで議論されている部分の解説

募集を開く
CFの登録

この２つを考察します。

募集を開く：
この命令をAPサーバーが受け取った後、最新募集状況を募集を管理しているサーバーに問い合わせてます。
募集を受け取ったサーバーが処理を戻すまで、APサーバーは結果を待っています。
準備が整ったらクライアントに情報を返却し、募集一覧がクライアントに表示されます。

募集データーの準備処理が集中すると、その間の通信プロセスが重なってパフォーマンスが落ちる。
今回、懸念されている内容のひとつです。
なお、この処理の間は、通信は接続したままだと思われます。

直ぐにレスポンスを返す必要があるために、このような方法がとられます。

CFの登録：
CF登録するときは、APサーバーは、募集を管理するサーバーに、キャラクターのID、ジョブ、IL、レベル、希望ID　（PTの場合はそれらをまとめて）
CFの情報が記録されている場所へ配置します。
この処理が終わった後は、通信を一旦きります。（募集が必ずしもマッチするとは限らないから）

CF側は、CF応募データーに変化があると、マッチング処理を開始します。
（大量に集中するときは、速度を調整するなどしていると考えられます）

マッチングした場合は、マッチング処理に移行します。

[noton-noton]

技術に詳しく無いヒトの感想です。

募集を仮想コンテンツとしてCFの処理フローに載せる方式だと理解しました。
その場合は、CFの作りがポイントだと思います。

もし、CFのマッチングがコンテンツを軸にする作り（コンテンツ毎にジョブ(プロセス)など）だった場合、
対応コンテンツ数を動的に変更できず、募集を仮想コンテンツとしてCFの処理フローに載せる方式は破綻する可能性があります。

だとすると、新規にサーバ跨ぎのPT募集を構築した方が、既存への影響も最小に出来るし、導入(運用)しやすいと思います。

もし、コストを重視するのであれば、零式と練習モード（実装検討中？）の各フェーズをCF対応コンテンツにしてもらえば、
サーバ跨ぎのPT募集（簡易版）と変わらない気がしました。

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

＞もし、CFのマッチングがコンテンツを軸にする作り（コンテンツ毎にジョブ(プロセス)など）だった場合、
＞対応コンテンツ数を動的に変更できず、募集を仮想コンテンツとしてCFの処理フローに載せる方式は破綻する可能性があります。

この部分を考えていたのですが、私が、想定されていることが正確に把握できていないと思う中で意見を書きます。
・マッチング処理とコンテンツは、もともと別々に独立していると考えられます。
・サーバー跨ぎの募集は、そのままだと閲覧によるアクセスの過多による問題が発生する可能性があり、なんらかの制約を設ける必要がある。
・CFだとジョブを選ぶことができないので、そのままだと使えない。
・箱問題は、マッチングする前に確認が必要

こんな感想をもちました。

[aqua_steve]

一個質問なんですがこのスレッドで話されているような
PT募集なのか特殊なCFなのかは別にして
PTを組んでコンテンツに入るまでに時間が掛かる問題を解決する仕組みを
利用したいプレイヤーのおおよその数というか割合みたいなものって限定できないですかね?
例えば零式の様な高難易度コンテンツにこそ必要だから
実装された場合その機能を使えるのは前提クエストをクリアしたプレイヤーのみとかにして
利用者数を限定することでサーバー間募集であれ特殊なCFであれ
サーバーに対する負荷が軽減されるのであれば良いかなと素人ながら思ったとです

[MisatoMisa]

サーバー跨ぎで一つ疑問。

名前どうするんだろ？
同姓同名居たらかち合いそうな気もする…………。

[noton-noton]

一個質問なんですがこのスレッドで話されているような
PT募集なのか特殊なCFなのかは別にして
PTを組んでコンテンツに入るまでに時間が掛かる問題を解決する仕組みを
利用したいプレイヤーのおおよその数というか割合みたいなものって限定できないですかね?
例えば零式の様な高難易度コンテンツにこそ必要だから
実装された場合その機能を使えるのは前提クエストをクリアしたプレイヤーのみとかにして
利用者数を限定することでサーバー間募集であれ特殊なCFであれ
サーバーに対する負荷が軽減されるのであれば良いかなと素人ながら思ったとです

＞PT募集なのか特殊なCFなのかは別にして、
＞PTを組んでコンテンツに入るまでに、時間が掛かる問題を解決する仕組みを
＞利用したいプレイヤーの、おおよその数というか割合みたいなものって限定できないですかね?
（句読点をこちらでいれました）

どの程度必用としてるのでしょうかね？
ただ、比較的アクティブ率が高いと思われるアレキ組みの利用希望者が多いのはないでしょうか？

＞例えば零式の様な高難易度コンテンツにこそ必要だから
＞実装された場合、その機能を使えるのは前提クエストをクリアしたプレイヤーのみとかにして、
＞利用者数を限定することで、サーバー間募集であれ特殊なCFであれ、
＞サーバーに対する負荷が、軽減されるのであれば良いかなと素人ながら思ったとです
（句読点をこちらでいれました）

利用者の個別情報を管理する手間が増えるので、相殺されてしまうような気がします。

[TonPoo]

補足しときます。
CFの処理は、受付は申請単位 、マッチングはコンテンツ単位と想像しました。なんとなくですがコンテンツ毎に待行列がある方が素直だと思います。

[Matthaus]

サーバー跨ぎで一つ疑問。

名前どうするんだろ？
同姓同名居たらかち合いそうな気もする…………。

確か新生前に吉田Pが、新生ではキャラ毎に固有IDで管理しているので、
システム的には、同一ワールド内での同姓同名は可能になっている、
と言ったことを言われていたと思います。

UI的にはID表示していないので、その辺りを改修しないと使えないとは思いますが...

自分に割り当てられているIDって何だろう？ちょっと気にはなりますね＾＾；

[IrisFrowers]

確か新生前に吉田Pが、新生ではキャラ毎に固有IDで管理しているので、
システム的には、同一ワールド内での同姓同名は可能になっている、
と言ったことを言われていたと思います。

UI的にはID表示していないので、その辺りを改修しないと使えないとは思いますが...

自分に割り当てられているIDって何だろう？ちょっと気にはなりますね＾＾；

素直に考えるならロドストのIDじゃないかな・・・？

[noton-noton]

サーバー跨ぎで一つ疑問。

名前どうするんだろ？
同姓同名居たらかち合いそうな気もする…………。

ソーシャルゲームを始めるとき入力する名前は、重複をチェックしておらず、キャラクターの一意のデーターはＩＤ番号を付与します。
ＦＦの場合、同サーバー内では同名チェックをしているようなので、サーバー内では大丈夫ですが、グループ内だと引っかかる可能性が…

確認してはいないのですが、同名チェックの範囲が「グループ」だと、この問題は起きませんが、ここは不明です。
尚、もっとも重要なＩＤは、名前と違ってユニーク属性（１個しかない事が保証されている）なので、システム的な問題は発生しないと思われます。

同名が出てきたときに、やや問題なのはチャットでしょうかね？
どちらの発言かわからない…
その場合、システムが名前に番号を振ってくれればいいのですが…

｛同名の人間は、ＣＦならばマッチングしないという裏プログラムで回避できますが（苦笑）｝