室内に居てCFから戻った時

[QuCont]

インスタンス終了時点でおそらくハウス内のキャラデータ（位置情報）を保管するDB（もしくはテーブル）が全てドロップされていると思います。ので、そもそもここでいう再ロードという作業は行えません。

それですよね。その位置情報はどこでどういうふうに保存してるのがネックです。
部屋はインスタンスだから、入る前の座標は必ずどこかに置いてあるでしょう。
ミストの家ならミスト○区と立ち位置のXY（Zも？）座標はキャラのテーブルに保存してあるでしょう。
座標データでも、ミストと家は大して変わらないはず。国に関わらず家の3種類の中身は一緒だから、座標データは「ミスト-区-座標XYZ」から「S家-部屋ID-座標XYZ」に置き換えるだけで今までと変わらないはず。

問題はbtkさんの言う通り、部屋インスタンスがまだ存続してるかどうか。
もうすでに消されたら、その場合またハウジングのテーブルからその部屋の情報を読み込んでインスタンスを構築してから、キャラをその中に放り込めばいいです。
当然、部屋インスタンス構築の時間はかかるけど、その数秒待たされてもよっぽど短気な人でなければ特に問題になる要素ではないと思います。直接部屋に戻れる喜びと比べると。

ハウス内はインスタンスエリアなので、エリア消失にあわせてそのDBも消失する、という風にイメージするとわかりやすいかも。
アイドリングストップの例えについては、ここではサーバへのアクセス頻度によります。
さらに、DBドロップによるリソースの有効活用というメリットがあるので今回こういう実装をしたのでしょう。
...
消されてデータ読み込んで、が今の状態ですね。

おおむねそういう事情ですよね。
ただ部屋インスタンスとIDなど諸コンテンツのインスタンスの最も違うところは、部屋の出入りが激しい点。
ダンジョンなど、人がいなくなればすぐ消してもいいが、部屋だと出てからすぐ戻ってくることは多々有ります。
私はよく部屋内で一人で生産してますから必要な設備やNPCは置いてあるが、材料切れなどがある場合は外のマケボか3都市のNPCに買いに行きます。そして買い忘れもよく有るから数分間の間に部屋を何度も出入りしてます。他に似たようなシチュエーションも有るでしょう、部屋に入る前に隣人さんに挨拶されたりしたからとりあえぜ出てってちょっとだけの世間話してから中に戻るとか。そのため部屋から出た途端にそのインスタンスを全部破棄することはしないと推測してます。

せめて私ならそうはしません。
アクティブから非アクティブはしますがセッションまるごと削除して、また構築して、んでまた削除の繰り返しはかなりの非効率だと思います。
そのため、人が居なくても数分間の間はまだ生きてるでしょう　→　5〜10分間の「アイドリング」。
もし鯖がこのアイドリングすらできないほど圧迫してるなら話は別です、IDの様な「鯖待ち」は未だに合ってないし聞いた話もないからそれほどではないと思います。

なぜそうしないのかが分からないけど、おそらくスケジュール的にこういうシステムを作る時間がなくて、一般IDのシステムを流用しただけでしょう。

でも話が逸れましたね。
アイドリングとか、キャラクターの位置情報とかより、キャラクターがログインしてすぐ、部屋インスタンスを構築すれば、昔のように「そのまま部屋に入る」って形はできると思います。

個人的には大賛成ですね。もっとがっつり技術寄りの話してくれると喜ぶ層もいますよ

ですよね、やっぱりネットゲームする人の中に同業者も多いから聞きたいです。
クライアントはLUAっぽいですが、バックエンドは何使ってるのかすごく知りたいです。
データ量はかなり多いからただのSQLでは持たないでしょうね。

[Faru]

座標とかの問題なら、室内の入り口に戻る様にしてくれるだけでもいいんですけどね。
その方が、帰ってきた感もありますし。

この仕様でも、インスタンスの解放って出来ないのかな・・・？

[btk]

しつこいようですが、気になっちゃいますね。職業病。。ｗ
以下、ミストヴィレッジ1区＝M1、インスタンスエリア＝IA、パブリックエリア＝PA　として略記します。

部屋はインスタンスだから、入る前の座標は必ずどこかに置いてあるでしょう。
ミストの家ならミスト○区と立ち位置のXY（Zも？）座標はキャラのテーブルに保存してあるでしょう。
座標データでも、ミストと家は大して変わらないはず。国に関わらず家の3種類の中身は一緒だから、座標データは「ミスト-区-座標XYZ」から「S家-部屋ID-座標XYZ」に置き換えるだけで今までと変わらないはず。

まず前提としてキャラクタの位置情報はキャラクタそのものの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さんのテーブルを保持します。
そして、その保持している位置にコンテンツエリアから帰還する際に戻ってきます。

[btk]

また、M1からハウス内（IA）にログインする場合、M1からハウス内への移動の時点でPA間移動同様M1のDBはキャラクタの位置情報をドロップします。
なぜかというとハウス内から出るには玄関かテレポ（orデジョン）しかないため、位置情報を保持しておく必要がないからですね。リソース節約です。

で、本題のハウス内（IA）からコンテンツサーバ（IA)からへの移動の際ですが、こちらでも現在の仕様ではPA-PA間移動同様ドロップしていると思います。
理由は簡単で、こちらもサーバのリソース節約です。
ハウス内に存在したキャラクタの位置情報をずっと保持し続けるのがつらかったかもしくは、理論上の最大値で設計しなきゃいけない
（どうもこのゲームは最大値を決めうちして堅い設計をしたがるように見受けられます。。それがいいか悪いかはともかくとして）
のがつらかったのかはわかりませんが（そしておそらく後者でしょう、、とんでもない規模のDBを用意しないといけなくなる。。）、ここがリソースの制約で不可能だったため、現在の仕様にしたのだと思います。
ハウス（IA）を増床するにあたって、用意しなきゃいけないDBサーバを削減するための仕様だと思います。

また、生成したインスタンスが削除されるまでどれくらいの時間をかけているのかはわかりませんが、おそらくここがかなり早く起動と停止を繰り返してもそれほどコスト増にならず（実装したプログラマの工夫）、QuContさんのように出入りを繰り返すことによる頻繁な出入りはぶっちゃけ上の問題に比べれば微々たるものだったのではないかなと思います。
そして2.1でそのデータおよび裏づけがとれたので、家の外に放り出す仕様にした上でハウジングエリア全体の増床が可能になったのでしょう。


以上はあくまでもすべて個人的な推測であり、実際の実装はまったく異なる可能性が多分に含まれておりますのでいち酔いどれエンジニアの戯言と思って聞き流してくださいｗ

[LiLiTekken]

直接関係は無いですが、今年のcedec2014に
FF14のローカルPCで扱うファイルシステムについて講演がありました。

ファミ通さんのサイトだったかに記事が公開されていたかと思います。
当日、私もその講演に参加させて頂きましたが、面白い内容でしたよ('∇')

[QuCont]

私が言いたいのは、CF突入前やログアウト前の位置データは単なるアルファ数字の羅列でしょう？
それがM1でもPAでも、最後に居たフィールドのIDとXYZの座標。
ただ位置を表すだけのstringだから、それがフィールドでも住宅街でも部屋内でも変わらないと思います。部屋が使い捨てのインスタンスでも。

最後にいた位置を記録して、それを読み取って、フィールドだったらキャラクターをそのままフィールドに放り込めばいいし。
部屋っていうインスタンスでも、キャラクターがログインと同時に起動すればいいだけの話です。

直接関係は無いですが、今年のcedec2014に
FF14のローカルPCで扱うファイルシステムについて講演がありました。

ファミ通さんのサイトだったかに記事が公開されていたかと思います。
当日、私もその講演に参加させて頂きましたが、面白い内容でしたよ('∇')

今検索してみました。
確かに面白そうですね。
完全に専門外ですが。