なんか変な精神状態が続いててやばいですね。
そろそろ現実に戻ってこなきゃならんということで、今日のムキフェス(AoE3:TADの大会)はぶっつけになりますががんばろうと思います。・・・・・シュタゲ脳な状態でまともにゲームになるのだろうか。
さて、シュタインズゲートですが、やはり非常に評価が高いようです。
各レビューサイトの評価まとめ
・mk2 ランクS 88点
・ErogameScape-エロゲー批評空間- 平均値 92点
・Amazon(Steins;Gate(シュタインズ・ゲート)(数量限定版))
星5つ: (76)
星4つ: (3)
星3つ: (0)
星2つ: (0)
星1つ: (1)
参考・4gamer 平均98点(但し投票数は6点のみ)
参考・ファミ通XBOX 9 7 9 9の計34点
参考・ファミ通 レビューなし。
参考・Steins;Gate(シュタインズ・ゲート)(通常版)
星5つ: (29)
星4つ: (6)
星3つ: (3)
星2つ: (1)
星1つ: (1)
今後の動向にも要注目?かもですね。
2009年11月
Steins;Gateクリア
なんだかんだで、休日と今日を使ってやっとクリアしました。
厨二病(2ちゃん用語大量に含む)+SF(タイムトラベル)という、ネタの選択間違ってないか?というアドベンチャーゲームでしたか、想像以上によかったですね。
ああ、これは評価されるゲームだなーと思いました。
アドベンチャーゲームはたまに思い出したときに評判なゲームをやってますが
(Ever17、ミッシングパーツ等)、当たりのアドベンチャーゲームはなんとも言えない感がありますね。
ネタ的に激しく人を選ぶのが残念ですが、ドラマかなんかにしても面白そうな作品だと思いました。ちょうど、13話完結みたいな。あ、最終章は2時間で。
興味のある方はプレイしてみるのをオススメします。
噂では手に入れるの大変らしいですけどね・・・。
私も結局中古で買っちゃいましたし(新品は店回ってもまったくなかったので)
でも、いいゲームだと思いますよ。
・・・ところで、大学時代に習ったはずのネタ、量子力学とかの単位持ってるのにまったく理解できないのはなんでなんだぜ?
・・・ま、授業は理解できてなかったんですけどね。
PS
レビューサイトの評価見てきたけど、相当評価高いっすね。
プレイした感想からいうと納得の評価ですが
HOUKOUレポート
Simple Eloのメンテナンスを実施しました。http://aoe3.game-server.cc/rating2/
とはいえ、難しいことはしておらず、基本的に処理に問題のある機能を削除しただけとなります。
一応、効果は顕著で10秒~20秒程度のロード時間が数秒程度に抑えられたので効果はありますね。
さて、ではSimple Eloの問題点と修正した内容、今後の改善点についてメモを残しておきたいと思います。
Simple Eloの問題点と修正した内容>
一番大きいのはDB関係です。ページの表示そのものはそれほど時間が掛かっていないため、内部的な処理に問題があるというのはすぐに気づきました。
この時点で考えられる対策は大体4点ぐらいかな?
・DBサーバのスペックを強化
・プログラム上のSQL文見直し
・DBのテーブルにインデックスを適用
・DBの古いデータを削除
1番上はとりあえずすぐには無理なので、後は残りの3つ。DBを操作する権限は貰ってないし、そもそもDBの仕様、テーブル構造が一切不明なので、この時点で3番目、4番目もなしということで、残ったのは2番目のみとなります。
さて、本来であれば、DBサーバのデータをトレースし、問題のありそうなSQLクエリを探していくのですが、今回はそういった環境はないので、実際に仮環境で一つずつ切り分けしながら問題のSQL文を探すことに。
SQL文を見ていくとどうやら、非常に重い処理にランキング処理があることに気づきました。
何をやっているかというと・・・・・・
・検索したい対象のプレイヤーのレーティングを用いて、テーブル上に存在する他プレイヤーのユーザのレーティングと比較してそれをカウントして順位を出す
というもの。
@@・・・・・・つまりあれです。仮に100万件のデータがあった場合、毎回DB上で100万件の比較集計をやってるということに。更にこれを全ゲーム(3作分)×全ゲームモードの分繰り返して、集計を出しています。100万(仮)×3×・・・・これは物凄く重そうだというのはなんとなく想像できると思います。
とりあえず、順位を集計してるクエリをばっさりと削ったところ、20秒近く掛かっていたロード時間を10秒程度に抑えることができました。
ただ、クエリ自体は順位集計として用いられるものとしては非常に一般的なものでした。それなので普通に作ればこうなるだろうなぁというは想像し易いものです。ただ、一方でこのクエリはあまりに多いデータ件数では処理が重いという情報もあり、どうやらSimple eloはそれに該当してしまったようです。
また、この時点でクラン表示情報も削除しました。どうやらクラン関係はESOからの情報も直接拾っているような感じだったので、念のための削除です。
だいぶ早くなったとはいえまだまだ重いSimple Elo。
後重そうなところといえば・・・ゲーム履歴。アカウントが仮に100万とした場合、その戦跡の履歴データはほぼ100万以上。下手すると1000万件とかありそうです。
そこで機能をありなしで比較してみたところ、やはりこれも明確に差が出ました。
検証していくと、どうやら、全ゲームの履歴を一度呼び出して、それを先頭の10ゲームだけ表示させてるっぽい疑いが。そりゃ重そうだと思い、ここ2ヶ月程のゲーム履歴を呼び出す形とし、そのうち先頭50件だけ表示させる方法に変更させました。
結果として、過去の戦跡を辿れなくなってしまいましたが、処理速度は大幅な向上を見ました。戦跡データ事態は蓄積されているのでプログラム的にもう少し考慮してSQL文を考えれば、もっと効率的にできそうではありますが。
<今後の改善点>
今後の改善点ですが、可能ならばDBサーバそのもののスペックを良くするという選択肢はありだとは思います。
ただお金がかなり掛かることなので早急には無理でしょうね。ということで現実的ではありません。
となると。
・DBのテーブルにインデックスを適用
・DBの古いデータを削除
この辺りがポイントとなるでしょうか。戦跡データは例えば過去3ヶ月より古いデータは全て消すなどやれば、戦跡データ取得は著しく早くなると思います。
テーブルへのインデックスを適用に関しては、上手く調整することにより、ランキング集計も削除しなくてすむかもしれません。
他には、
・プログラムそのものの修正
が考えられますね。例えばランキング集計を別の方法で行う等するのもよいかもしれません。一時的テーブル上にランキングを書き出し集計する、テーブル上にランキングの列を追加しそこにバッチファイルなどで定期的にランキング情報を更新する等・・・・
私自身がやってもよいのですが、あまり知っている言語やDBではないし、開発環境も家ではロクにないので、とりあえずは保留としたいと思います。
もし私がやるよ!って人がいれば、まつじゅん先生に申し出てあげて頂ければと思います。
さて、Steins;Gateの続きをやるので、今日はこれぐらいでノシ