家の中・個人部屋にいて、CFから戻った時に外に出されるのは何かシステム上の事情があるのでしょうか?
特に個人部屋にいて、CFから戻った時に外に放り出されているのがかなり面倒な感じがします。
Printable View
家の中・個人部屋にいて、CFから戻った時に外に出されるのは何かシステム上の事情があるのでしょうか?
特に個人部屋にいて、CFから戻った時に外に放り出されているのがかなり面倒な感じがします。
これ、CF排出後 せつなくなりますね(´・ω・)
外 と言うか エーテライトにもどってくるんだと思いますので、設定的に自然と言えば自然なんですけども。
※あ、でもフィールドでも 入った場所にそのままもどるから、そんな設定でもないのか、、、純粋に鯖の問題ですかね、、、_(._.)_
※が訂正部分
ID等のコンテンツに入った途端に
その人を家の外に出すことで、
ハウジング用のインスタンス数が抑えられて、
より多くの家が建てられるようになったとのことです。
リソースの問題みたいです。
第16回のPLLで語られてますね↓
1:47:53
Q: 個室でログアウトすると、再ログイン時はハウスの外に出されてしまうので、宿屋のように部屋に戻ってくるようにしてほしい。
A: 河本:当初から多くのフィードバックをいただいているのは把握しているのですが、意外と根が深い問題で、現状すぐに対応することができません。宿屋はインスタンスダンジョンなどと同じように、人がいない状態であればリソースを消費しないようスタンバイ状態になるようになっています。ハウスも同様に、プログラマーの工夫によりリソースを消費しないようになっているのですが、その結果再ログイン時にはその部屋のリソースが存在していない状態になっていて、部屋に戻れるようにするにはどうするかという難しい問題があります。
リソースなんちゃらは言うけど、要は人が居ない間は部屋のインスタンスを閉じてそのリソースを他にまわすってことでしょう。
だったらログインやCF終了後は部屋のインスタンスを再ロードすればいいじゃないって思ってしまう。
ログアウトやCFいってる間でもキャラが元々いた場所や座標はどこかに保存してるんでしょうし。
インスタンス立ち上げるまでの時間がかかるだとしても、別にその間だけ通常より長めのローディングでもかまわない。
バックエンドはどう処理してるか分からないが、恐らく人がいなくても部屋のインスタンスはすぐ消えるんじゃなくてしばらく立ってから消えるんでしょう。一々データーをロードして再構築する方がコストが高いから。車で例えるなら一時期アイドルストップが流行ったが、一々エンジンを切ったり付けたりする方が燃費悪くなるしスターターの消耗になるし結局アイドルしてるままの方が長期的にエコ。部屋のインスタンスを構築したり消したりする方が鯖の負荷になるだけ。
んんんん、考えれば考えるほど理解できなくなってしまう。
部屋のインスタンスがまだ生きてるならそのまま入ればいいんだし。
もう消されてもデータ読み込んでインスタンス構築すればいいんだし。
もう次にPLLに鯖やインスタンス管理してる人達をゲストにしてほしい。
一般の人にとってはつまらない話になるだろうけど。
ハウスは流動的なものだから例外的な事象が発生した際の課題を考慮するより、
一律ハウス外って位置情報だけ保存したほうが安全だからだと思う。
アイドルストップではなくアイドリングストップ
実装当初は家の中に戻ったけども、土地追加の一環で現在の仕様になったんです・・・がぁ!
(ハウス用サーバーの追加設備投資をせずに、ハウスの設置数を増やしたり部屋を追加する為 だったと思う)
現在でも土地の数が十分とは言えないので、いますぐに とは言わないまでも
サーバー設備も土地数も整えてもらった上で、元の仕様に戻してもらいたいですね・・・w
気になったのでコメントします。
※全て僕個人による推測です
インスタンス終了時点でおそらくハウス内のキャラデータ(位置情報)を保管するDB(もしくはテーブル)が全てドロップされていると思います。ので、そもそもここでいう再ロードという作業は行えません。
基本的にMMORPGではキャラクタの座標はそのキャラクタが存在するサーバ内DB(のような感じのモノ)が保管しています。
ハウス内はインスタンスエリアなので、エリア消失にあわせてそのDBも消失する、という風にイメージするとわかりやすいかも。
アイドリングストップの例えについては、ここではサーバへのアクセス頻度によります。
さらに、DBドロップによるリソースの有効活用というメリットがあるので今回こういう実装をしたのでしょう。
ハウジングエリアのインスタンス起動はかなり早いと思いますよ。コンテンツエリアでのインスタンスへの移動にムービーをはさんでいるのはおそらくコンテンツエリアのインスタンス起動にそれなりに時間がかかるからであり、長いロード時間へのストレス対策ですね。
続きます
消されてデータ読み込んで、が今の状態ですね。
部屋内からキャラクタが消失した時点で、そのキャラクタに対する座標を保持しているDB(もしくはテーブル)が消えている(他のキャラクタがいればインスタンス自体は生きてる)ので、元の座標に戻ることはできません。ので、玄関前に強制的に戻されます(これは正直苦肉の策だと思います)。
ついでに言うとこれは技術的な問題ではなく、リソース上の制約によるものです(2.1ハウジング実装当初はハウス内へ戻ってこれた=ハウス内から居なくなってもパブリックフィールド同様に位置情報を保管していた)。
ので、今後ハウジングエリアそのものがプレイヤーに十分に行き渡った上で追加投資できる資金があれば、サーバ(ストレージ容量)増設により2.1と同様の実装に戻すことは可能だと思います(ストレージ容量ではなく、通信量の問題もあるとは思いますが)。
そのために我々プレイヤーができることは、課金アイテムを買うことですね:cool:
個人的には大賛成ですね。もっとがっつり技術寄りの話してくれると喜ぶ層もいますよ;)
それですよね。その位置情報はどこでどういうふうに保存してるのがネックです。
部屋はインスタンスだから、入る前の座標は必ずどこかに置いてあるでしょう。
ミストの家ならミスト○区と立ち位置のXY(Zも?)座標はキャラのテーブルに保存してあるでしょう。
座標データでも、ミストと家は大して変わらないはず。国に関わらず家の3種類の中身は一緒だから、座標データは「ミスト-区-座標XYZ」から「S家-部屋ID-座標XYZ」に置き換えるだけで今までと変わらないはず。
問題はbtkさんの言う通り、部屋インスタンスがまだ存続してるかどうか。
もうすでに消されたら、その場合またハウジングのテーブルからその部屋の情報を読み込んでインスタンスを構築してから、キャラをその中に放り込めばいいです。
当然、部屋インスタンス構築の時間はかかるけど、その数秒待たされてもよっぽど短気な人でなければ特に問題になる要素ではないと思います。直接部屋に戻れる喜びと比べると。
おおむねそういう事情ですよね。
ただ部屋インスタンスとIDなど諸コンテンツのインスタンスの最も違うところは、部屋の出入りが激しい点。
ダンジョンなど、人がいなくなればすぐ消してもいいが、部屋だと出てからすぐ戻ってくることは多々有ります。
私はよく部屋内で一人で生産してますから必要な設備やNPCは置いてあるが、材料切れなどがある場合は外のマケボか3都市のNPCに買いに行きます。そして買い忘れもよく有るから数分間の間に部屋を何度も出入りしてます。他に似たようなシチュエーションも有るでしょう、部屋に入る前に隣人さんに挨拶されたりしたからとりあえぜ出てってちょっとだけの世間話してから中に戻るとか。そのため部屋から出た途端にそのインスタンスを全部破棄することはしないと推測してます。
せめて私ならそうはしません。
アクティブから非アクティブはしますがセッションまるごと削除して、また構築して、んでまた削除の繰り返しはかなりの非効率だと思います。
そのため、人が居なくても数分間の間はまだ生きてるでしょう → 5〜10分間の「アイドリング」。
もし鯖がこのアイドリングすらできないほど圧迫してるなら話は別です、IDの様な「鯖待ち」は未だに合ってないし聞いた話もないからそれほどではないと思います。
なぜそうしないのかが分からないけど、おそらくスケジュール的にこういうシステムを作る時間がなくて、一般IDのシステムを流用しただけでしょう。
でも話が逸れましたね。
アイドリングとか、キャラクターの位置情報とかより、キャラクターがログインしてすぐ、部屋インスタンスを構築すれば、昔のように「そのまま部屋に入る」って形はできると思います。
ですよね、やっぱりネットゲームする人の中に同業者も多いから聞きたいです。
クライアントはLUAっぽいですが、バックエンドは何使ってるのかすごく知りたいです。
データ量はかなり多いからただのSQLでは持たないでしょうね。
座標とかの問題なら、室内の入り口に戻る様にしてくれるだけでもいいんですけどね。
その方が、帰ってきた感もありますし。
この仕様でも、インスタンスの解放って出来ないのかな・・・?
しつこいようですが、気になっちゃいますね。職業病。。w
以下、ミストヴィレッジ1区=M1、インスタンスエリア=IA、パブリックエリア=PA として略記します。
まず前提としてキャラクタの位置情報はキャラクタそのもののDBとは結びついてないと思います。
自分が書いた
>基本的にMMORPGではキャラクタの座標はそのキャラクタが存在するサーバ内DB(のような感じのモノ)が保管しています。
が、そういう意図なのですがこれをもうちょい詳しく書くとたとえばキャラクタが
「ミストヴィレッジ - 1区 - XYZ」にいた場合、その位置情報が存在するテーブルはM1のエリアサーバ(に紐付くDB)が持っている、というような実装だと思います。
(DB名がM、テーブル名が1で、主キーにキャラクタのIDみたいなもの、とXYZみたいな感じかな)
「M1」はPAなので常に存在していて、そこにAさんがログインしてきた場合に
新たにログインしたキャラクタの位置情報をもつ行が作成され、そこに時々刻々位置情報がread/write(圧倒的writeですが)されていきます。
PAであるM1から、PAである低地ラノシアに移動した場合、M1のDBにあったAさんの行はドロップされ、新たに低地ラノシアの同様のDBにAさんの行が作成されます。
PA間移動はこれを繰り返してその時の位置情報を保持しているような感じだと思います。
一方、M1(PA)からCF経由でコンテンツサーバ(IA)にログインした場合、このM1のキャラクタ位置情報DBはそのままAさんのテーブルを保持します。
そして、その保持している位置にコンテンツエリアから帰還する際に戻ってきます。
また、M1からハウス内(IA)にログインする場合、M1からハウス内への移動の時点でPA間移動同様M1のDBはキャラクタの位置情報をドロップします。
なぜかというとハウス内から出るには玄関かテレポ(orデジョン)しかないため、位置情報を保持しておく必要がないからですね。リソース節約です。
で、本題のハウス内(IA)からコンテンツサーバ(IA)からへの移動の際ですが、こちらでも現在の仕様ではPA-PA間移動同様ドロップしていると思います。
理由は簡単で、こちらもサーバのリソース節約です。
ハウス内に存在したキャラクタの位置情報をずっと保持し続けるのがつらかったかもしくは、理論上の最大値で設計しなきゃいけない
(どうもこのゲームは最大値を決めうちして堅い設計をしたがるように見受けられます。。それがいいか悪いかはともかくとして)
のがつらかったのかはわかりませんが(そしておそらく後者でしょう、、とんでもない規模のDBを用意しないといけなくなる。。)、ここがリソースの制約で不可能だったため、現在の仕様にしたのだと思います。
ハウス(IA)を増床するにあたって、用意しなきゃいけないDBサーバを削減するための仕様だと思います。
また、生成したインスタンスが削除されるまでどれくらいの時間をかけているのかはわかりませんが、おそらくここがかなり早く起動と停止を繰り返してもそれほどコスト増にならず(実装したプログラマの工夫)、QuContさんのように出入りを繰り返すことによる頻繁な出入りはぶっちゃけ上の問題に比べれば微々たるものだったのではないかなと思います。
そして2.1でそのデータおよび裏づけがとれたので、家の外に放り出す仕様にした上でハウジングエリア全体の増床が可能になったのでしょう。
以上はあくまでもすべて個人的な推測であり、実際の実装はまったく異なる可能性が多分に含まれておりますのでいち酔いどれエンジニアの戯言と思って聞き流してくださいw
直接関係は無いですが、今年のcedec2014に
FF14のローカルPCで扱うファイルシステムについて講演がありました。
ファミ通さんのサイトだったかに記事が公開されていたかと思います。
当日、私もその講演に参加させて頂きましたが、面白い内容でしたよ('∇')
私が言いたいのは、CF突入前やログアウト前の位置データは単なるアルファ数字の羅列でしょう?
それがM1でもPAでも、最後に居たフィールドのIDとXYZの座標。
ただ位置を表すだけのstringだから、それがフィールドでも住宅街でも部屋内でも変わらないと思います。部屋が使い捨てのインスタンスでも。
最後にいた位置を記録して、それを読み取って、フィールドだったらキャラクターをそのままフィールドに放り込めばいいし。
部屋っていうインスタンスでも、キャラクターがログインと同時に起動すればいいだけの話です。
今検索してみました。
確かに面白そうですね。
完全に専門外ですが。