Notifications
bg
Keigo Ando
Japan
5
Likes
19
Followers
0
Connections
All
Articles2
Games0
Showcases0
Column2
Jobs0
[特別企画:Unityスタッフ連載]3週目・安藤圭吾 [5/5] 来年からまたエディター拡張楽しくなってくるよ。沼にハマるならその時がチャンス。

今回は将来の話です。

2019.x からUnityのエディター拡張事情は大きく動きます。Package Manager をユーザーが気軽に使えるようになったり、Unityエディターの見た目(テーマ)が新しくなったり、GUIシステムが一新されたり...エディター拡張に関する多くの出来事が来年は起こります。それでは1つ1つ紹介していきます。

Package Manager は、今まで大きな1つとして提供してきたUnityのシステムを、細かく機能ごとに分け、それぞれパッケージ化して提供するパッケージ管理システムです。イメージとしては、Node.jsのnpm、C# のNuGet、pythonのpipなどと同じです。今は、Unityの公式パッケージのみ配信されていますが、将来的にユーザーの作成したパッケージを気軽に配信することが可能になります。Package Manager が誕生したことによりファイルの管理方法が変わります。今は、UnityPackage(実質はtarファイル)というアセットを圧縮したファイルでやり取りをしています。今後、UnityPackageで管理することが非推奨になり、Package Managerのパッケージを管理するサーバーからパッケージを入手したり、Githubからパッケージを入手することが推奨となるかもしれません。ちなみにアセットストアのアセットもPackage Managerで管理されるようになります。

2019.x からUnityエディターの見た目(テーマ)が変わります。よりフラットなデザインになり今風のアプリケーションになります。あまり大きな変更はないとされていますが、エディター拡張でGUIシステムを使った拡張をしているユーザーは対応に追われるかもしれません。

GUIシステムが一新されます。今、エディター拡張で使用しているGUIシステムは非推奨となり「UI Elements」というシステムに置き換わっていきます。将来的にはUnityエディター自身もすべて「UI Elements」のGUIへと変わっていきます。来年には、エディター拡張を行うユーザーは必死こいて勉強していることでしょう。

大きく3つのことについて紹介しました。いかがだったでしょうか。
そもそもエディター拡張の技術は大きく変化しません。3年前に書いた「Unityエディター拡張入門」の本もまだまだ通用します。1度覚えればずっと使えるであろうエディター拡張の技術(GUI変わっちゃいますけど)、この機会に覚えてみるのはいかがでしょうか。

以上で私の連載は終わりです。お付き合いありがとうございました。

tamtam
a month ago
Unity 2019はエディタ拡張もいろいろある年になりそうですね。(いい意味でも大変な意味でもw)
[特別企画:Unityスタッフ連載]3週目・安藤圭吾 [4/5] 今ってもうあまりデコンパイルしなくても良くなったんですよね

今日は、エディター拡張の学習方法について昔と今を比較します。

※ 昔はUnity 2017.xまでを指します。今は 2018.x 以降を指します。

昔は、「エディター拡張をするならUnityEditor.dllをデコンパイルしてDLLの中身を見たほうが良い」と言われるほどでした。何故かと言うと、エディター拡張に関する情報が少ないのはもちろんのこと、Unity標準の動きに似せようとすればするほどUnityがどのように実装されているかを把握していかなくてはいけません。

Unityがどのように実装されているかを、手っ取り早く知る方法は「ソースコードを見ること」です。マニュアルやスクリプトリファレンスを見る方法では情報量が足りません。マニュアルではエディター拡張に関する情報はあまり載っていませんし、スクリプトリファレンスでは一般公開されているAPIしかありません。Unity自体がエディター拡張のAPIを使って開発されていると言っても、すべての機能がAPIとしてユーザーに公開されているわけではありません。「この機能いいな、どうやって実装するんだろう?」と思っても1つのAPIで完結しない複数行のコードによって実装されていたり、一部に非公開APIを使っているということがよくあります。
普段であれば公式で公開されていない情報である以上、諦めるのが普通です。ですがエディター拡張の真骨頂は「Unityが自分に合わせる」ことなので、多くのユーザーがソースコードを解析(DLLをデコンパイル)して、該当のソースコードを見つけ・読み、どのように実装されているかを学習してきました。

あまりにも多くのユーザーがデコンパイルしてしまうので、Githubにデコンパイルされたソースコードがユーザーによって公開されてしまうほどです(https://github.com/MattRix/UnityDecompiled)。そして多くの人がこのデコンパイルされたソースコードを読んで勉強をするようになります。

最終的にはデコンパイルするのが当たり前になろうとしたとき、ついに公式としてUnityがソースコードを公開するようになりました(https://github.com/Unity-Technologies/UnityCsReference)。

これで(堂々と)Unityについて学ぶことが可能になったわけですね。ソースコードを読んで把握していくことはとても難しいことですが、無いよりはマシです。

ここまでは昔の話でした。次からは今、そしてこれからの話です。

これからもソースコードを読んでいくことは変わりありません。ですが、積極的にオープンソースとして機能の開発が行われるようになってきています。PostProcessing(https://github.com/Unity-Technologies/PostProcessing)やml-agents(https://github.com/Unity-Technologies/ml-agents)が良い例です。
詳細は次回説明しますが、さらにPackage Managerという仕組みが実装され、より一層その流れは加速します。

↓文字数制限のため続きはコメントで。

Keigo Ando
a month ago
これはどういう意味かというと、今まではUnityのコア部分に強く依存していた機能の開発から、(できるだけ)コア部分に依存しない開発へと移行しています。 つまり、よりユーザーと同じ立場で開発をしています。PostProcessingのエディター拡張部分のソースコードを見てみてください。まさに「エディター拡張のコードはこう書くんだぞ」というようにお手本となるような書き方をしています。 今はもう、エディター拡張の勉強でデコンパイルする必要性もなくなってきました。 Unityのコア部分のソースコードはGithubに上がっているし、これから開発される機能のソースコードもGithubなどに上がっています。 「ソースコードを読む」というのは昔と今では変わりませんが、よりオープンで学びやすい環境になったことは間違いないでしょう。
[特別企画:Unityスタッフ連載]3週目・安藤圭吾 [3/5] 初心者がエディター拡張について勉強するのは損?得?

Unity初心者がエディター拡張について学ぶのにメリットはあるのでしょうか?

私はメリットがあると思っていて、エディター拡張を学ぶタイミングとしては「自作ゲーム2〜4作目から挑戦してみるといい」と思っています。

Unityを使用する目的、それはもちろんゲームなどのインタラクティブなアプリケーションを作成することです。このグループにいるみなさんは、今はUnityの操作を覚えたり、チュートリアルをこなしていたり、はじめての自作ゲームを作成していることでしょう。

エディター拡張は「ゲーム開発を自分にとって楽にする技術」です。まだ操作を覚えることが多い初心者の方にとっては、いきなり自分の思想を入れると「Unityを覚える」という作業の効率は落ちてしまいます。なぜなら「標準機能として提供されているのに、機能が無いと思ってエディター拡張で自作してしまう」ということが起こりがちです。余計な道草を食ってしまうということですね(もちろんその過程で学んだことは無駄ではありません)。まずは、公式のチュートリアルや入門書通りにゲームを作成しUnityの操作を覚えてみましょう。

おそらく、入門書を終え自作ゲームのアイデアがある人はすでにガツガツとゲームを作成していることでしょう。そして、入門書で学んだとおりではなく、徐々に自分流でUnityを使い始めているでしょう。ここです。自分流にUnityを使い始めたときがエディター拡張を学ぶタイミングです。

エディター拡張のスクリプト(API)は公式でも使用してUnityエディターを作り上げています。極端を言えばスクリプトの動きを覚えればUnityの動きを覚えられることになります。自分でUnityをカスタマイズすることが理解できるようになれば、「自分がUnityに合わせる」のではなく「Unityが自分に合わせる」ということ(発想)ができるようになります。「インスペクターが見づらいから自分が見やすいように変えたい」というように。

自分はプログラマーじゃないから無理そうだと思ってる方も「Unityエディター拡張入門」の本を軽く流し見をしてみてください。自分で作れなくても「何が作れるのか」がわかるようになるだけでもだいぶ違います。自分で作れないならプログラマーに頼んだりアセットストアで探せばいいわけです。

エディター拡張も難しさの段階があります。まずは、スクリプトを1行追加するだけでカスタマイズできるエディター拡張をしてみてはいかがでしょうか。次のURLを参考にしてみてください。 http://anchan828.github.io/editor-manual/web/part2-standardextension.html

「Unityが自分に合わせる」という事ができるので人によっては「ゲームを作成していたと思ったらエディター拡張に没頭していた」ということが起こります。ようこそエディター拡張の沼へ。

次回は「今ってもうあまりデコンパイルしなくても良くなったんですよね」についてです。

[特別企画:Unityスタッフ連載]3週目・安藤圭吾 [2/5] 私はこうやってエディター拡張を学んでいった
本日は私の過去話です。

私がエディター拡張の勉強を始めた当初(2011年くらい)、エディター拡張に関する情報はほとんどありませんでした。現在のようにGoogleで検索したらQiitaの記事がヒットするというような日本語情報はもちろんのこと英語の情報もあまりなく、公式のスクリプトリファレンスがヒットするだけというのが日常でした。
それに加え、Unityユーザー助け合い所(コミュニティ自体は2011年にすでにあったけど、質問しても誰も答えられそうになかった)やteratailなど日本語で質問できる場所もありません。

参考になる情報が公式のスクリプトリファレンスのみというような環境で、それに加え、スクリプトリファレンスではとても簡易に説明されているため、仕様について学ぶことも困難でした。実際に自分でエディター拡張の動作を確認し、学んでいかなくてはいけない状況です。

さて、このような条件下で私がどうやってエディター拡張について学んでいったかの具体的な話をしていきます。

前述したように、情報はスクリプトリファレンスしかありません。わたしは、実際に1つ1つのAPIを実行し、その動作を確認しながら仕様を学んでいきました。そして、動作結果を文字に落とし込んで自分だけのドキュメントを作成していきます(自分で書いた説明文が、公式ドキュメントとだいたい同じ文章になってしまって笑ったのを覚えています)。

1つ1つエディター拡張のAPIを実行し確認していく作業は、とても手間がかかり多くの時間を要するものでしたがとても楽しいものでした。これらのAPIは、公式でも使われているAPIです。同じAPIを使うことで標準の機能と同じものを開発することもできます。なのでUnityエディターを開発している気分になり苦になることがありませんでした。今思えば、私はこのようなツールを作ることが大好きである確認できた出来事でもあります。(ここで得た多くの知見は技術書として「Unity 4ライブラリ辞典 エディタ編」「UNIBOOK」「Unity エディター拡張入門」で公開しています。特に、Unity エディター拡張入門を公開した2015年から、劇的にエディター拡張について学ぶ環境が整いました。この入門書はWebで無償公開しているので、2018年現在でも日本だけではなく翻訳(英語・中国語・韓国語...)されて様々な国で引用され、読まれています。)

「この標準機能、どうやって動いているんだろう?」「同じものを実装したいんだけど、どうすれば?」というときには、まずUnityのソースコードを解析(デコンパイル)して実際のコードを読みながら理解をしてきました。この解析する作業は今現在でも、より最新の技術を知ろうとする際に通用します。

本日は私の過去話でした。「1つ1つAPIを試して動作を確認した」という途方も無いことをしてました。当時は学生だったので時間もあってできることだと思います。社会人の今じゃ無理なことですね。

次回は「初心者がエディター拡張について勉強するのは損?得?」についてです。

[特別企画:Unityスタッフ連載]3週目・安藤圭吾 [1/5] なぜエディター拡張をするの?

この連載では、エディター拡張の技術について話すのではなく、「昔の状況はこうだったけど、今の状況はこうなってるんだよ」というような私の経験をもとに歴史の話や今後の付き合い方の話をします。


さて、みなさんはUnityのエディターを触っている中で「Unityのこの部分(機能)、もっと使いやすくなればいいのに」と思ったことはありますか。

私がUnityエディターについて説明するとき、いつも「Unityのエディターはいつも8割程度の完成度でリリースされています」と言っています。これはUnityのクオリティが8割というわけではありません。そのようにしているのは「これ以上の完成度を持った機能はユーザーの手で実装して欲しい」という狙いがあるからです。もし、FPSに特化したUnityであればRPGが作りにくくなるかもしれません。3Dゲームに特化すれば2Dゲームが作りにくくなるかもしれません。このように、これ以上の完成度を持つとユーザーが好きなゲームを作るのが難しくなる可能性があります。そこでUnityは、Unityでできる(想定している)ことの10割のうち、2割をユーザーが自由にカスタマイズできるようにしました。

ユーザーはこの2割を使って「ゲーム開発を楽にするために」カスタマイズしていきます。プロジェクトに合ったカスタマイズをすることで、Unityの性能を10割、もしかすると10割以上引き出すことができるかもしれません。

どのようにして2割を補っていくかですが、そのアイデアはアセットストアにあふれています。パラメーターを編集している時のインスペクターが使いにくいですか?では、インスペクターを拡張しているアセットを見てみましょう。ノベルゲームの作り方&管理の方法がわかりませんか?では、フレームワークを提供しているアセットを見てみましょう。
このように、みなさんが「不便だな、もうちょっとこの部分が良くならないかな?」と思っていたり「みんなはどうやってるんだろう?」と思うことは、アセットストアで公開済みかもしれません。または、特殊なプロジェクト事情を解決するヒントになるかもしれません。皆さん通る道は同じということですね。

アセットストアにあるエディター拡張系のアセットを使うと、すぐに便利なUnityエディターになります。ですが「(チーム・会社の都合上で)ここの機能はもうちょっとこうしたい!」となることが多くなるのも事実です。アセットストアのものは汎用的なものになりがちで、少し特殊な環境に置かれているプロジェクトになると、途端に使いづらくなってしまいます。

その解決としてソースに手を加えたい場合、もちろんエディター拡張の知識が必要です。知識さえあれば、他人のソースでも自ずと修正すべき箇所が見えてくるはずです。

アセットストアでアセットを購入してもいいし、そのアイデアを元に自分用に自作して、残りの2割をこのようにして補うことで、ユーザーやプロジェクトごとに最適化されたUnityエディターが完成します。

エディター拡張によって機能を追加していくのは、自分でツールを作成していると言ってもいいでしょう。ゲーム開発そっちのけでエディター拡張をしていくことを「Unityエディター拡張の沼(にハマる)」といいます。GoogleやTwitterなどで検索してみてください。多くの人が沼にハマっています。

次回は、「私はこうやってエディター拡張を学んでいった」についてです

Keigo Ando
updated the article
Apr 29, 2018 2:32 PM
GameViewSizeHelperを2017.4に対応させた話
GameViewSizeHelperは、スクリプトからGameViewSizeを作成、また設定するヘルパークラスです
GameViewSizeHelperを2017.4に対応させた話
Article
tamtam
8 months ago
メンテ作業 乙でした!
About Me
No description
See more
Skills
No skills added yet
Certifications (0)
Import
See all
Keigo Ando's liked project (1)
Following (3)
Followers (19)
Following Companies (0)
Not following anyone yet