Unity認定開発者試験を受けてきた

先日10月14日のことになるが、
Unity認定開発者試験というのを受けてきた。
発表は去年されて、海外から始まっていて受けてみたいなーとずっと思っていて
日本でも受験が開始されるということで受けてみた。

結果からいうと100問中、94問正解（2000点中1880点）という結果。
途中までは10問くらい間違えてしまったかなぁと思っていたけど（ちゃんと数えてない）
それよりかは良かった。

試験の申込みを勢いでしてしまったけど、
業務でUnityを触っているエンジニアにしてみれば簡単なものですよー、なんて情報をチラホラと見かけて、
さらにその後コースウェアなどを見ていると、
確かに広く浅くという内容ではあり、
逆にこれ、一問も間違えたら駄目では・・みたいなプレッシャーを感じた。間違えたけど。

ただ簡単とは言え、何もUnityを分かっていない状態からではパスするのは難しいのかなと思う。
ひととおりUnity触れていることを判定するのには良い試験なのでは。
また、今後別のコースの展開もあるということであるので、
よりエンジニアよりの試験なども出てくるのだろう。

コースウェア

コースウェアという試験対策のコースがあり、オンライン上で動画を見ることができた。
これで勉強すると試験の範囲が一通りカバーできる。
コースウェアに限らない話だけど、
試験対策で勉強していく過程で、
普段の使い方で見逃しているエディタの機能などに気づくことがいくつかあって、
それは今回試験を受けてみて良かったことだと思う。

例えば僕の場合、
シーンビューのxyzのAxis表示の中心のキューブ部分をクリックすると
カメラを透視/平行の切り替えができるというのは知らなかった。
それ以来よく使うようになった。

コースウェアに関して僕の場合、試験の申込みのあと別途買おうとおもって
Unity Certification - Courseware
こっちから購入した。
ちょっとこれが問題というか、試験を受けるためのアカウントとは別のアカウントで購入したことになってしまった。
動画も英語のものだったけど、字幕があったので問題はなかった。
チャプターごとのレビュー問題も英語であったけど、
これはもしかして試験と一緒だったら日本語だったのかな・・？

微妙なとことか

コースウェアだけど、動画などを組み込んだ作りのサイトになっていて少し重い。
あとモバイル(Android)でみれなかった。
これは端末依存かもしれない。
ただ、こういう勉強は移動中などに見れると嬉しかった。

試験の運営に関しては、日本で初ということもあり運営・試験官側も慣れていない様子があった。
試験のアカウントでのログインをするためのパスワードが当日教えてもらえたのだが、
最初に教えられたパスワードが間違っていた。

また自分は大丈夫だったが、なにかシステムのトラブルで時間が来ても試験が始められない人がいた。隣に。
試験時間の計算は個人個人で行われてるということではあるけど、
スタートでトラブルがあるのは辛いだろうと。
あと、隣でごちゃごちゃしてるのは、まあ若干気になった。

合格した場合は７日以内にメールで通知されるということであったのだが、
そのメールは来なくて、問い合わせをしてしまった。（まだ調査はしていただいているということ。）

Unity Educationのサイトからダウンロードが出来るようになってはいた。
が、このサイトのつくりが分かりにくい。
ダウンロードのリンクもとても分かりにくい。
証書へのリンクがトップに出てくると思っていたのだけど、
My Activity -> Course と遷移をした先の、小さいバッチのようなアイコンがダウンロードリンクになっていた。
さすがにこれはUIがひどい。

statisticsのページにhighest score 100/100
lowest score 94/2000
という表記があり、
これも分かりにくい。
lowest score は関連した数字になっているが、highestはなんだろう。

また、紙の試験と違いあとで答え合わせできないので、
あとで全問の結果を見直せると自分が何を間違えたのか分かって嬉しい。

あと証書の有効期限が・・

valid through 1970/01/01 ってこれ合ってますかね・・

【11/08/2017 追記】
ちゃんとした証明書がダウンロードできることが確認できた。

もろもろ経緯。

10/28 VRアカデミーから、Unity社が証明書メールを発送したとの連絡 → 来てない

11/2
Unity のシステムから合格通知メールが届く。
Certificate no, valid through の情報など正しいもの。
→ pdfをダウンロードするとvalid through 1/1/1970のまま

11/7
pdf のvalid throughの表記が正しくなっていることを確認。

なんかね。

最近使ったシーンをロードしやすくするメニューエディタ拡張

github.com

Unityで作業しいると、場合によって
あるシーンと、あるシーンをいったりきたりして作業することがある。
Projectビューからロードすればよいのだけど、
アセットの数が増えてきたりすると、
アクセスが悪くなってきたりする。
シーンだけフィルタしてしてみたりするけど、
外部のアセット、アセットストアからのアセットのサンプルシーンなども混ざってくると
これもまた分かりにくかったりする。

なので、その面倒さを解消するエディタ拡張。
メニューの[Window]-[RecentScenesMenu]を選ぶと
ウインドウに最近開いたシーンが３つ表示されるので
ボタンを押すとそのシーンをロードする。

子供用プリントのエクセルを作った

子供の自習時間とかでドリル的なものが必要だったりするのだけども、
自分で作れるじゃんって感じのものだったので作った。

足し算・引き算のひっ算のエクセル。
VBAが書かれてて、
ボタンで問題が毎回リセットされる。

答えを表示したりする機能をつけても良いかと思ったけど、
けっきょく難しい問題ではないので保留。

引き算２桁.xlsm - Google ドライブ

足し算２桁答えが１００以下.xlsm - Google ドライブ

Excel2016 (Office365) で作成したもので、
他の環境でどれくらい動くかは未検証。
一応、シェアする形で残しておく。

ADBTools

Unity のプロジェクトフォルダ以下にあるapkをリストアップし、
インストール/アンインストールを容易にできるようにしたエディタ拡張を作った。
github.com

昔、Processを呼び出してインストールするようなものは作ったけど
AndroidでビルドはもういいRunしたいってとき - kurihara-nの日記
もう少し整えて、
apkをリストアップして、
それぞれにインストール/アンインストール操作ができるようにした。

Windowsでしか確認してないのは引き続き。

Zenjectとマルチシーン

Zenjectを採用したプロジェクトにおいて、
マルチシーンへ対応する場合にはいくつかの方法があります。

Zenjectのベーシックな使い方は、
シーンにSceneContextを配置して、
そのオブジェクトにInstallerを配置していくことで、
シーンごとの構成を用意していくというものです。

そのままだとUnityでシーンの変更をしたときに
関連性が持てず、それぞれ参照できなくなるので、
前のシーンでBindしたオブジェクトを、
次のシーンで参照するということができません。

方法としては、

1. ProjectContext　というグローバルなコンテキストを用意する
2. Sceneの親子つけを行いマルチシーン構成にする
3. DecoratorContext

Project Context

https://github.com/modesttree/Zenject#global-bindings-using-project-context

Projectビューの右クリック -> Create -> Zenject -> Project context
でプレハブを作成する。
場所はResourcesフォルダ以下である必要がある。

これをいったんHierarchyに配置し編集してApplyすることで構成していく。
インスペクタの情報としてはSceneContextと大差なく、
MonoInstallerをアタッチしたり、ScriptableObjectInstallerをアタッチしたりできる。

編集がすんだらApplyをしてシーンからは削除しておくのがポイント。
このプレハブをもとにしたオブジェクトは、シーンに配置しておいて動作するのではなく、
いずれかのSceneContextがシーンオブジェクトに配置されていると、
実行時にDontDestroyOnLoadなオブジェクトとしてシーンに生成される。

Scene Parenting

グローバルに存在するProjectContextはプロジェクト全体を範囲としてしまうので、
ときに問題となる。
指定のシーンとシーンを意図したように関連づける手段として
Contract Name を使用したScene Parentingが存在する。
https://github.com/modesttree/Zenject#scene-parenting-using-contract-names
この場合、シーン同士は並列ではなく主従・親子としての関係を持つ。
親となるシーンのScene Contextのインスペクタ、
Contract Namesというフィールドがあるので、ここに親としての名前を指定する。
（このフィールドは配列になっており複数していできる。
子からみた親はひとつだが、親シーンは全く別の子の親としても、みなされることができる）
子シーンのほうは、インスペクタのParent Contract Nameに、
親の名前を指定する。
Contract Nameはシーン名とは関係ない名前で構わない。

まず親シーンを開き、Hierarchyに子シーンをドロップして、複数のシーンがある状態にし、
Ctrl + Shift + V でValidationが通ることを確認してみるとよい。
この状態は、実際には親シーンからAdditiveで子シーンを読み込んだ状態に等しい。
ちなみに子シーンが先に読まれている状況でValidationを行うとエラーとなる。

DecoratorContext

もうひとつのマルチシーン対応としてDecoratorContextを配置したシーンを用意するというもの。
https://github.com/modesttree/Zenject#scene-decorators
まずDecoratorContextを配置するシーンを用意し、
SceneContextの代わりにDecoratorContextを配置。
Decorated ContractにContract nameとする文字列を指定。
もう一つのシーンを用意して、
こちらには通常のSceneContextを配置。
Contract Namesに先ほどのDecorated nameのと同じ文字列を指定。
２つのシーンを読み込んだ状態で、
DecoratorContextで行ったバインディングが、
あとから読み込んだシーンにもInjectできる。

個人的にはParenting での運用が多い。
エントリシーンを用意し、それを親とした状態で、
モードごとに子シーンを読みかえる構成。
親となるシーン、子になるシーンにそれぞれContractNamesを適切に設定する。
ここら辺は、普段のプロジェクト構成に合うもので良いのではないかな。

バイオハザード７ resident evil

バイオハザード7 レジデント イービル - PS4

CERO Dバージョン

プレイしていたのは先月だけども。

とても素晴らしいゲームだったが、
このゲームの感想として「面白い」が適切なのかというと、
そうではないと思う。
もっといろいろな感情を刺激してくる。

最初は恐怖であり、次に怒りへと感情が誘導される。
どちらかと言うとネガティブな感情だけど、
それによってゲーム作品に引き込まれていく。

ゲームには色々な感情を受け入れられる良さがある。

PSVRを手に入れたらVRでも試してみたい。
ただ今までのシリーズの流れをストーリー・世界観的にあまり引き継いでないので、
これまでのシリーズのファンとしては、
そっちも楽しみにしてます。
ジェイクが主人公のシリーズをまたやってみたい。

人工知能の作り方 ――「おもしろい」ゲームAIはいかにして動くのか

人工知能の作り方 ――「おもしろい」ゲームAIはいかにして動くのか

kindle版にて。

ゲームAI研究の第一人者で、CEDEC等でも多く講演をされている三宅さんの本。
現在のゲームAIの分野を広く網羅されている。
実装の細かいところをコードも含めて見たい・知りたいと思っているプログラマからすると
やや概念によっているものになるかもしれない。
ただ、資料へのリンクも多く含まれているので
もっとより知りたい人でも大丈夫。
もし、もっと実装についての興味があるのであれば
Game AI proを読んでみるといいだろう。（英語だが）

ゲームAIについて丁寧に、周辺から近づいていく構成になっている。
コアの話の箇所でも、
具体的なコードまでは出てこない。
出てこないが、
技術的な仕様はわかるような説明はされている。

ゲームAIの本というと、
基本的にはプログラマ向けという印象もあるけれども、
ゲームデザイナーや、アーティストが読んでもよいと思う。
というかプログラマ以外が読むほうが良いのかもしれない。
そこまで実際のコーディングなど出てこないので、
そういう意味でも読んでほしい。

三宅さんのCEDECの講演で聞いた話も含まれていたので、
そういった三宅さんのリサーチを集めた本ともいえるだろう。
参考資料へのリンクも充実している。
紙の本だとどうだかわからないが（読んだのはkindle版）
kindleだとリンクから直接アクセスできるので便利。
電子書籍向けに合わせて作られているのはありがたい。

特に８章の集団の知能を表現するテクニックなどは興味のある章で、すばらしいと思う。
8章 集団の知能を表現するテクニック　～群衆AI の技術

ゲームのAIについて話す場合、
まず単体のAIに関する話題が優先されるが、
実際にある規模のゲームAIを作っていくと、
マルチエージェント間の連携や、
チームとしての制御が必要になり、
また 負荷対策が実際の問題として生じてくる。
この章はゲームの開発に基づいた資料として機能するし、参考になると思う。
ここで触れられているということにより、
さらに踏み込んだ議論や話しが、
マルチエージェント、群集の表現において
出来ていけると良いなと思う。

ゲーム分野ゆえの問題でもあり、
そのことに触れられているが、（一部引用）

このような組織のシミュレーションが通常、ゲーム産業でしか必要なく、ゲーム産業自身が先導して研究を推進する必要があるからです。アカデミックでは「 マルチエージェント」と呼ばれる分野ですが、この分野自体が広く、 必ずしもキャラクターの協調シミュレーションだけにフォーカスしているわけではないので、こういった技術を吸収しながらも今後発展が必要とされる分野です。

この章の内容だけでも、
ここをさらにもっと広げて、もっと深めていけるともっと表現の追求ができそう。
まだここはやれることがあるところ。
この章を書いていただいたことを感謝したい。

あと、GDやプログラマ以外の方も
ゲームAIへの理解深めておいたほうがよいのかについての補足をもう少し書いておく。
イマイチに観えるAIの、なんでAIがビミョウに思えるのかの原因は
実装が良くないことによるよりも、
ゲームデザインからくることがしばしばある。
開発していてというよりも、ゲームプレイをしていて感じることがある。

例えば、キャンディクラッシュゼリー、
悪い例で挙げて申し訳ないけど、
充分にヒットしている、とても魅力のあるゲームだという前提で。

このパズルゲームシリーズの中の一つの作品は、
敵のAIと対戦を行うステージが出てくる。
いくつか対戦内容はあり、例えば相手より先に自陣のゼリーの色を全体に広げよう、
などというものである。
ポイントとして、対戦以外の面と共通するルールとして、
手数の制限があり、
これはプレイヤー側にのみ課される制限となっているのである。
まず、この点でAI戦で公平ではない印象をプレイヤーに与えてしまう。
また4つ以上のピースを消したときはボーナスとしてスペシャルピースが生成されたうえ、
引き続きターンが継続するというルールになっている。
理屈でいえばAI側は、スペシャルピースを作れる盤面が続く限り、手数の制限がないため、
デメリットもなくターンを続けることができてしまう。
その対策としておそらく組み込まれている挙動なのだと思うが、
スペシャルピースを2つほど生成したあとは、
AIはなるべくただの3つピース消しを選択し、
ターンをプレイヤーに返す行動を選択するようだ。
スペシャルピースを作ってターンを継続出来る場合だったとしても、それに関わらず。

これはプレイヤーからみたら、AIが不可解な手をとったバカなAIと映るかもしれないし、
人によってはワザと手加減されたと感じるかもしれない。
またそれ以前にアンフェアなルールにモヤモヤしているだろう。
これはゲームAIとゲームデザインがうまく機能してない例だと思う。
もっとフェアなルールを設定出来さえすれば良かったと思う。

他のゲームでも、
いろいろな要素が高いレベルで実装されているにも関わらず、
AIが不可解な行動をとるゲームというのはどうしてもある。
問題の解決方法をどこに着地させて解決していくのかは、それぞれの状況による。
そのため各担当パートの垣根を越えてAIへの理解というのは持っておいて損はないはず。
ゲームの絶対的な仕様による制限でAIがおばかに見えてしまうとしたら、
AIプログラマが実装をどんなに改善しても解消は難しいということはある。
そういったさいにゲームデザイナーやほかのスタッフとの対話で
ベストな解決を見つけていくことになるので、
お互いに共有する知識があることは役に立つと思う。