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 への知識を僕が獲得できるという利点があるので、かなりイライラしながらも、このままやってみるのも悪くないと思っています。

仕事がなかなか進まない

仕事では、かれこれ数ヶ月 Project Tango を用いたアプリの実装を行っていますが、なかなか前に進まないですね。

他の調査と実装も平行していることが大きな原因の 1 つですが、Tango を用いた開発についての情報が少ないことや (公式ドキュメントも説明が足りない)、Android での 3D グラフィックス実装に対する経験のなさから難儀しています。

Unity から Java への移行

始めは Unity で開発を進めていましたが、途中から Java での開発へ移行しました。
このまま Java で進めようかなと。

3D の経験は僕自身が趣味レベルですし、まして会社はその分野に何一つ関係していないため、OpenGL を直接使うよりも Unity をベースにした方が適切だろうと始めは考えたのですが、最終的にはやりたい事が Unity にマッチしないという判断をしました。

今はツール的な意味合いの強い AR アプリを目指している所で、Android の標準 API で提供される UI との統合がどうしても欲しくなります。
また、クラウド サービスを前提にしており、多様なデータのリアルタイムな送受信や同期なども必要です。

Java ならば Android 標準 API で簡単に出せる UI があるのに、Unity 上で同等の UI を自作するのはナンセンスですし、僕らはクロスプラットフォーム開発を必要としていないため、Unity のプラグインを作ることもナンセンスです。
また、Unity では通信関連ライブラリが充実しておらず、これにも自作やプラグインの問題がまとわりつきます。

どのようなツールもライブラリにも想定する利用方法が必ず存在し、その想定にマッチする場合は恩恵を得られ、さもなくば足枷になります。
そして、僕らのやりたい事は Unity の想定から外れているため、他の方法を選択すべきということです。

でまぁ・・・それはそれでキツイなぁ、と。

Rajawali の利用

Android の OpenGL API を直接使うのもキツイので、今は Tango の公式サンプルで利用されている Rajawali という 3D ライブラリを利用しています。

Rajawali/Rajawali | GitHub

Rajawali は、Android OpenGL API のラッパー群を用意し、更にシーンを作るためのフレームワークや各種 3D モデルのロード機能などを備えている感じです。

Rajawali のソースコードを見ていると、Android での 3D 実装未経験の僕にとって勉強になりますね。

Java には構造体がなく、プリミティブ型以外の全てがオブジェクトとなるため、GC 効率に対する考慮が随所に見られます。
Vector3 や Matrix4 では、あえてメソッド元オブジェクトの状態変更で new を避けられるようにし、オブジェクトを new したい状況のためには専用の静的メソッドが提供されていたり、clone メソッドが用意されていたりします。
あるいは、演算中に発生する短命オブジェクトを避けるために、クラス内部でキャッシュを設けて上手く処理している部分が多く見受けられます。

でもなぁ・・・と。
ラッパーを使うと、どうしてもラッパー オブジェクトの new が発生するんですよね。
Tango から得られるベクトル配列や行列配列に対してラッパー オブジェクトの new が発生しますし、ラッパー メソッド内部では Android OpenGL API からの戻りで得られる配列に対するラッパー オブジェクトの new が発生します。

まぁ、あまり拘り過ぎると物が出来なくなるので、まずはこれでやってみようという感じです。

 

Project Tango いじり開始

仕事で Project Tango 開発用タブレットを購入しました。日本では買えなかったので輸入です。

Project Tango - Google

一応、今年の夏頃には 3D センサ搭載 Android が発売されるそうです。

まだ、公式サイトを見ながら開発環境を整えたり、サンプル アプリを Google Play から DL していじたり、チュートリアルに従って少しだけ開発してみたりしている段階です。

ひとまずは Unity 版チュートリアルに従って試していますが、お世辞にもチュートリアルとは呼べない内容なので、Unity を単体で学ぶ必要と、サンプル コードから直接理解する必要があると感じてます。
過去には、そこそこ 3D グラフィックス関連の知識を得ているので、そこそこ気軽に Unity を理解できるのが救いです。でも、Script を C# で書いて、Android でどうデバッグするのかなど、開発での基礎的な部分が理解できていません。

Unity をいじるとなると、Tango とは関係しないテーマをひとまずは立てたいですね。その方が効率よく学べると思うので。過去に遊んでたプログラムを Unity でやってみる・・・とか。

DevOps 系ツールを色々いじってます

仕事で VirtualBox、Vagrant、Ansible、Docker 辺りをいじっています。
プライベートな時間でもいじっているので、仕事なのか趣味なのか分かりませんが。

事の発端は、Redis を使いたいと思った事に始まります。Redis を使うには Linux 環境が必要です (怪しい Windows ビルドは論外)。しかし、Windows 環境でやりたいので、VirtualBox と Vagrant を使うかー、となりました。で、Ansible と Docker もついでにやるかー、となった感じです。

・・・と、いつものように壮大に脱線し、Redis はどこへ行った状態ですが、やっていると凄く楽しいです。

でまぁ、得た知識を情報としてブログで載せられたら良いなぁ・・・と思っています。必要な情報は Vagrantfile、Dockerfile、Playbook などのファイルに全てが記述されるので、それら一式を GitHub で共有する感じなんですかねぇ。

最近のお気に入り - Kobito

最近は、何かしらの情報を記載する時には全て Kobito を使っています。

Kobito

Electron を調べていたのと、仕事で情報共有に使うツールを探していたら Qiita: Team に辿り着き、Kobito にも辿り着いたって感じです。

Electron

Qiita: Team

殆どの情報はテキスト形式で十分であると僕は考えていますが、単なるテキスト エディタで記述する場合、自分自身でレイアウトに迷うことが多く、また、人により構成が異なる所にイライラしていました。このイライラ解消には Markdown が最適 (完全ではなくベスト) であると感じ、Kobito を愛用している所です。

Markdown - Wikipedia

特に、コードの断片を記述する時に便利ですね。様々な言語用に自動的に整形する機能が便利です。従事している仕事の性質上、コードの断片を記述することが非常に多いです。コーディング規約、コード例、導入手順・・・などなど。

作業指示なども、Kobito で Markdown で書いて、相手にも Kobito のインストールを強制し、エクスポートしたテキスト ファイルを渡し、Kobito で開いて確認してね、というノリでやってます。仮に、Kobito を使わずに、一般的なテキスト エディタで見ても問題はないでしょうし。

他にも、打ち合わせでは Kobito で書いた内容をモニタに映して説明しています。

バージョン管理システムで文書も同時に管理する事を考えると、Markdown は差分把握に良い形式です。ゆえに GitHub の README も Markdown なのでしょう。

コピペの際にも便利ですね。テキスト ベースの場合、コピー元の書式にとらわれる事が無いので。変に凝ったツールでは、コピー元の書式までコピーしてペーストしてしまうので、かなりウザいです。

・・・って言うか、書いていて楽しいです。プレビューで整形結果をリアルタイムに見ながら、テキストでサクサクと情報を記述できるので。

欲を言うならば、Qiita 同様に目次も表示してくれると良いのですが・・・。後は、Qiita とは独立して、Kobito 単体でファイルを階層化できればなぁ、と。

inFamous: Second Son やってました

inFamous: Second Son を善人プレイでクリアした所です。

inFamous シリーズは初プレイですが、以前より気になっていたシリーズで、ようやくプレイできたって感じです。過去作も DL 版があれば間違いなく購入していたでしょうに。

Xbox 360 でも Riot Act (en: Crackdown) シリーズがお気に入りだったので、類似の inFamous も楽しめました。ビルの上から一方的に攻撃したりするのは好きなんですよねぇ。

でも、マップが退屈ですねぇ・・・どこに行っても同じ印象で、米国風と謎の中国風の二択。
シアトルを舞台にしているそうですが、現実の建造物と配置は利便性や作りやすさが考慮されたものなので、箱庭系では真似過ぎると単調になるだけに思えます。
攻略エリアごとの特徴が欲しかったなぁ・・・と。

ED で Nirvana が流れたのは驚きました。一応、曲はこれ・・・のはず。




僕が学生頃はグランジ ブームで (音楽だけではなくファッションも)、Nirvana はよく聴いていたバンドの 1 つだったので懐かしいです・・・って、今でも聴きますが。
当時はシアトルがどうのと聞いた記憶があったので調べたのですが、グランジ発祥がシアトルでしたね。
inFamous 開発者としては、選曲にもこだわってみた、って所でしょうか。

Bloodborne をとりあえずクリア

Fallout 4 を目当てに PS4 を買いましたが、2h 程度で投げてしまいました。いや、☓ボタンが決定ボタンってのはイライラする。アホかと。

で、Bloodborne (ブラボ) を楽しんでいて、先程クリアした所です。
ラスト前に少し寄り道を楽しみましたが、総プレイ時間 33h、レベル 80 弱という感じでした。放置時間が結構あるので、実プレイ時間は 20h 強かなぁと。

クリアまで進めたので、面白いと思うのですが、面白くないとも思っています。もう面倒だからクリアして終わりにしよう、そんな感じでクリアしました。

今の所は 2 周目や別キャラ作成をやろうと思わないんですよね。
「このビルドで試してみたい！」と思わせる要素が皆無で、「どんなビルドでも回避とパリィと近接物理攻撃の強制なのでは？」と思ってしまうわけです。

ニコ動でブラボ動画を漁っていますが、今の所は面白いプレイ動画が無いですね。面白い動画が出てくれば、それを参考に気持ちをあらためてブラボをプレイするかもしれません。