FF15 やりこみ中

他にやりたいゲームもないので、FF15 で未クリアのサブ クエストをこなしている所です。そして、サブ クエストをこなしていると、初見クリアまでとは別の印象を持ちました。

結構、面白いな、と。

作業感の強いモブ ハント、1 つしか受注できないモブ ハント、不便なファスト トラベルなどなど、否定的に捉えているシステムも、緩くプレイする姿勢ならば気にならなくなります。始めから緩くプレイできる人ならば、FF15 に肯定的なのでしょう。僕はせっかちなのでイライラしましたが、今はのんびり車を走らせながら BGM を聞いている状態です。

Lv 99 にし、スキルを MAX にし、殆どのクエストを終えましたが、時間の掛かりそうなクエストを残して、さてどうしたものかと考えました。ダメージ限界突破や魔法威力の底上げしないと、クエスト クリアには単純に作業的な時間が掛かりそうで、それは嫌だなぁと。

問題はアビリティの充実であり、つまりは AP 稼ぎです。調べると AP 稼ぎの方法が出てきますが、ただの作業であり、それはキツイ。という事で、2 周目に入って AP 稼ぎをすることにしました。シナリオを追いながら、知らないうちに AP が貯まっていた・・・という状態の方が健全ですから。

そこで気付いた事。

2 周目に入る前には全員の服装をカジュアル スタイルにしていたのですが、カジュアル スタイルで開始するとシナリオに違和感がありません。荒野を黒服で車を押しながら友達感を押し付ける描写も、カジュアル スタイルならマッチします。

なぜ、最初からそうしなかったの？と思います。

黒服は別に良いです。正装としての設定が世界観の一部としてあり、否定するものでもありません。しかし、黒服で旅を始める事には違和感しかありません。旅の開始は旅らしくカジュアル スタイル、締める時には正装の黒服、このような使い方をすれば良いだけです。そうしていれば、ホスト風イケメン ファンタジーとして拒絶されることは無かったのではないかと。

でまぁ、2 周目クリアをしてみても、たいして AP が貯まっていないんですよねー・・・。戦闘自体は面白いので、またサブ クエストを回しながら AP 稼ぎするか、このまま放置してスマホ ゲームでもやるか、そんな所です。

FF15 クリア

発売日に FF14 を DL してプレイしていましたが、やっとクリアしました。プレイ時間は 40 時間弱。サブクエスト無視ならば 20 時間程度でクリアできるのではないかと。

FF15 は、 よく出来ていてツマラナイ事はないけど、面白いと称賛する物ではない、という印象です。

FF15 は、著名なオープン ワールドと比べると、時間を忘れて楽しむまでの没入感がありません。僕は、オープン ワールドである前半部よりも、非オープン ワールドの後半部の方が楽しめました。

FF15 の世界観とシステムは、リニアな世界で活かされるものと感じます。例えば、シフト能力は、リニアな世界で縦横無尽な移動や演出を提供した方がしっくりくるのです。シフトはパーティ行動向きではなく、ノクトだけを操作する状況に向いています。

とまぁ、批判的ですが、壮年となったノクト達には味がありましたね。正直、こいつらカッコイイじゃんと思いました。このキャラクタ達ならば黒服も様になるな、と。やっぱつれぇわ・・・が馬鹿にされるラスト前の仲間達のキャンプも、僕は感動で涙が出ました。キャラクタ達の心を考えると、辛い気持ちが分かるなぁ、と。

ただまぁ良くないのは、そこまでのシナリオの流れが説明不足であり、演出不足なんですよね・・・。

ThreadLocal と Closeable を利用した一時変数のプール管理

Java で 3D Graphics Engine を実装するに辺り、算術演算の過程で避けられない一時変数の取り扱いに悩んでいました。

例えば、Matrix と Vector3 クラスを作り、位置とターゲット地点と up ベクトルから姿勢行列を生成する createLookAt メソッドの実装を考えます。
この処理の過程では X/Y/Z 軸の算出が不可欠であり、通常は軸を Vector3 インスタンスで表現したいと考えます。しかし、メソッド内部に閉じた一時変数であるため、GC 負荷の軽減を考慮すると単純な new による Vector3 生成は避けるべきです。

で、どうすりゃいいの？って話です。

jMonkeyEngine (JME) のコードを見ると、そのような一時変数用に TempVars クラスを定義し、そのインスタンスを TheadLocal 変数として管理しているようです。

コレだ！と。

ただまぁ、JME では、ありとあらゆる一時変数を TempVars クラスで一括定義している事に違和感があるため、自分のコードでは純粋に 1 つのクラスのインスタンスのみを管理する MatrixPool や Vector3Pool クラスを定義して利用することにしました。要するに、必要のないクラス間の依存を避けたいってことです。コード量は増えますが、僕は不要な依存を避ける方が重要だと思っています。

後は、Java 7 より try-with-resources 構文が使えるため、プールへのインスタンスの返却を簡素化するために、プールするクラスに Closeable を implements し、close メソッドでプールへ返却する仕組みとしました。
インスタンスのプール管理では、インスタンスのプールへの返却忘れというミスが十分に考えられます。このミスを減らすために try-with-resources を利用するわけです。
まぁ、可読性も向上しているんじゃないなかな・・・と、僕は感じます。

Far Cry4 クリア

今更感ですが、Far Cry4 をクリアしました。Easy モード。

やっぱ拠点攻略は楽しいですね～。
敵の位置、警報機の位置を確認し、ステルスでそれらを撃破・・・凄く楽しいです。
肉を投げて野生生物に敵を殺らせるのも楽しい。

Far Cry3 と比べるとストレスなくやれましたね。
糞 QTE を廃止してくれてありがとう！
この調子でゲーム業界から QTE が撲滅されることを僕は祈ります。

まぁ、シナリオが相変わらず糞でしたねぇ・・・。
良いと思わない、悪いと思わない、どうでも良い、そんな感じでした。
シナリオが糞なゲームはシーンもスキップできない仕様、それは世の理でしょう。

次は Far Cry Primal ですかね。

また 3D エンジンを自作するかもしれない

Project Tango のバグと Rajawali のバグのコンボで参ったので、ちょっと Rajawali を捨てて 3D エンジンを自作しようかなぁと思い始めています。

自分達で作るアプリは自分達で最後まで面倒を見ることになりますからね。
その観点では、Rajawali の利用には無理があんなーと。
自作した方が健全やなーと。

STEINS;GATE 0 やってました

STEINS;GATE 0 (ゼロ) の全ルートを一気にクリアしました。
って言うか、STEINS;GATE (初代) の続編が出ている事に全く気付いていませんでした。

ストアで見付けて速攻 DL して始めましたが、やっぱ面白いですねぇ。
初代やアニメ版を楽しめた人なら、ゼロも楽しめるんじゃないのかなーと。

まぁ、僕は、初代の頃から一番好きなキャラが「橋田至 (ダル)」で、相変わらず HENTAI を交えながらも、要所でイケメンなダルを見れて嬉しかったです。ダルを見たくてプレイしたと行っても過言ではありません。

でも、初代をプレイしたのが数年前という事もあり、既に初代シナリオの記憶は朧げで、世界線やアトラクタ フィールドの概念も忘れていたため、「これ何だっけ・・・」と悩んだので、クリア後には初代の真ルートを再プレイしました。

ゼロって、初代で β 世界線に戻ってからシュタインズ ゲートに入るまでの過程には、実は大変な苦労が隠されていて、それがゼロで語られている、って解釈で良いんですよね？
初代の初見プレイ時には、あまりにトントン拍子であることに違和感があったので、ゼロで補完されたのだとすると納得します。あの時のまゆりのビンタも、その性格やタイミングを考えると変でしたし。

悪い所を挙げると、初代と比べてゼロは理解に悩む演出でした。

初代では、過去改変の内容が明確に語られています。
一方、ゼロでは、過去改変を行う人が未来の存在であり、それが誰であるかは語られず、そこに至る未来も語られず、過去改変の内容も語られない。
それを想像や推測で補うのは流石に難しいですよ・・・。
ゲーム プレイ中に、いちいち事象をメモって関係性を把握するなんて事はしませんし。

で、凄く気になったので、ネットで考察を検索してなんとなく理解した、って感じです。
それでも、仮説を理解するしかなく、真相が分からんのですけどね。

まぁ、そんな事を気にするってのも遊び方の 1 つで、悪くないです。

Rajawali はオススメできない

しばらく Rajawali で実装してみましたが、これはオススメできないですねぇ・・・。

ひとえに低品質。

リポジトリに付随する example の範囲ならば概ね問題は無いのですが、その枠を超えて利用するとバグだらけ。
UV 座標が明らかに誤っている、行列クラスのメソッドが起こす副作用を無視して演算している、深度バッファの制御を必要とする所で抜けている・・・などなど。
そもそも、まともに動かない example もあり、自分でバグを見つけて修正して動かしてみたりしてます。
実際に利用すると明白であるはずの誤りがそのままってのは、テスト無しで master に入れている開発者が混じっているってことですよね。
要するに、プロジェクトを制御できていないんじゃねーかなぁ、と。

てなわけで、最近は自身のデバッグよりも、Rajawali のデバッグをしている感じでキツイ。
Fork して修正して報告して・・・とも考えましたが、クラス設計そのものに誤りがあると感じる所もあり、なんかそういうレベルじゃないんじゃねーかなぁと。

ですが、まだ Rajawali で行こうかと思っています。
動く物を作る事を優先しているので、とりあえず・・・って所で。
今の所は、Rajawali のクラスを丸ごと破棄して自作したり、回避コードで何とか出来ていますが、その枠を越えたら考えます。

代替を求めており、それを探してもみましたが、他はライブラリというよりも Unity のような統合環境化されたものであるか、あるいは、より単純な OpenGL ラッパーであり、丁度良い粒度のライブラリを見つけられません。

今は Rajawali のデバッグみたいな時間が多いですが、それを続けるうちに OpenGL への知識を僕が獲得できるという利点があるので、かなりイライラしながらも、このままやってみるのも悪くないと思っています。