Unity初心者用サイトまとめ
はじめに
Unity始めたばかりの人たちが研究室に多かったので、参考になりそうなサイトをかき集めて見ました。
Unityはバージョンアップで色々変わるので、サイトに乗っているバージョンと自分の使うバージョンを確認してください。
チュートリアル系
Unity - はじめてのUnity
初学者はとりあえずこれやっておけば間違いないと思います。 本当に基礎的なことが詰め込まれた良いチュートリアルだと思います。
ほかにもUnity公式のチュートリアルはどれも質が高いと思います。 Unity - Learn - Modules
【Unity2D】Unityで2Dミニゲームを作るチュートリアル（第１回） - Qiita
私がUnityを初めて触ったときに、一番最初にやったチュートリアルがこれでした。 パーティクルやオブジェクトをランダムに動かすといったことをこれで学ぶことができました。
【Unity入門】60分で作るシューティングゲーム 第１回 - おもちゃラボ
私はこのチュートリアルでprefabについていろいろ学ぶことができました。 このチュートリアル以外にも様々な記事があるので目を通して見ると良いと思います。 おもちゃラボ
また、このブログを書いているひとはUnityの教科書 Unity 2017完全対応版 2D&3Dスマートフォンゲーム入門講座 (Entertainment&IDEA) | 北村 愛実 |本 | 通販 | Amazonを書いたひとです。私もUnity5時代の本を持っています。 この本はイラストでの解説が多くわかりやすいのでおすすめです。
Unity入門-openbook
openbookにあるチュートリアルです。 ブロック崩しだけ実際にやった記憶があります。 馴染みのあるゲームを自分で作るのは楽しかったです。
Unity入門 (全26回) - プログラミングならドットインストール
自分はやったことありませんが、動画で実際にやってるところを見ながらのほうがいい人はドットインストールは良いと思います。 ただ、Unityのバージョンが4.2.0なのが…
情報収集
Unity スクリプトリファレンス
Unityの公式リファレンスは結構しっかりしてるのでよく使います。
テラシュールブログ
Unityについて調べ物する際、必ず目にします。 実行時のGIFを載せてくてるし、説明もうまいのでわかりやすいです。 テラシュールブログのありがたみはUnity触り始めてすぐ痛感すると思います。
Unity(C#)初心者・入門者向けチュートリアル ひよこのたまご
テラシュールブログの次によく見ることになると思います。 バックグラウンドが黄色で目がチカチカして見にくい点以外はとても良いです。
私はやったことがないのですが、チュートリアルもたくさん載っています。 Unity5チュートリアルアプリ一覧 - Unity(C#)初心者・入門者向けチュートリアル ひよこのたまご
ブログ
【Unity】素人が7日間クソゲーを作り続けてわかったこと | uinyan．com
有名な記事なのでUnityやったことなくても知ってるひとは多いと思います。 この記事と合わせて後日談である【Unity】クソゲーを作って晒したら世界が変わった件 | uinyan．comを読むと、自分もやらないとなって気持ちになれます。
スライド
はじめてのUnity入門 // Speaker Deck
個人的にめっっっっっちゃおすすめできる資料です。 チュートリアルで実際に作るものもそうですが、序盤20ページのUnityの概念についての説明がかなりわかりやすいです。
これはUnity県人会議にあるUnity道場のハンズオン的なのに使われた資料みたいです。 これ以外にも、使われた資料は公開してくれています。Presentations by unitydojo // Speaker Deck どれも面白くてわかりやすいので読んでみると良いと思います。
Unityを使ったゲームデザイン超入門
Unityコミュニティエバンジェリストの方の発表スライド。 これ以外にも、マネタイズやゲームシナリオについてのスライドもあって、そっちも面白い。
LineRendererでGameObjectの周りを線を囲いたい
やりたいこと
① 複数のマーカー(GameObject)の間を線で囲いたい
② マーカーが増えたときも、それに合わせて線で囲ってほしい
環境
| 名前 | バージョン |
|---|---|
| macOS Sieera | 10.12.6 |
| Unity | 2017.1.0f3 Personal |
線を引く
Unityで線を引く方法はいくつかあるが*1、今回はこの中で扱いが楽そうなLineRendererを使うことにした。
LineRendererは LineRenderer.numPositions 頂点の数を設定し、LineRenderer.SetPosition(int,Vecter3) 描画したい頂点の順番と座標を引数に線を描画することができる。
動的に線を描画
コードはこんな感じ。
foreachでリストを回してるだけ。
見た目はこんな感じ(デモ用に markerList の中に3つcubeを入れてある)。
悩んだのは頂点の数を変える際、 LineRenderer.numPositions で設定する頂点の数はconstになると思ってたら、普通に変えることができた。
markerList にGameObjectを追加しても描画してくれるし、GameObjectの座標を変えても線が追従してくれる様になった。
線を囲う
とりあえずマーカー同士を線で結ぶことはできたけど、囲うことはできてない。
なので、Inspectorをいじると、
いい感じになった。
雑記
ブログを書く前は、LineRendererのinspectorにroopの設定があることを知らずに、線を囲うために下のコードで無理やりやっていた。
ブログを書くためにLineRendererについて再度調べてるうちに、roopを見つけてこれでいいじゃん…ってなった。
透過画像を使ったボタンの範囲から透過されている部分を削除する
問題
Unityのボタンに円形の画像を使った際、ボタンの選択範囲が四角になってしまうため、円形の外にも選択判定ができてしまう問題があった。 単純な円形なら後述するICanvasRaycastFilterを使えばいけるけど、半円やキャラクタの形をしたボタンなどを実装したい場合は厳しそう。
例えば、下の星の画像でボタンを作り、星の範囲だけに判定をもたせたいのに、
こんな感じに、画像がちょうど入る四角い範囲がボタンになってしまい、ピンク色のところにも判定ができてしまう。
前提
- 画像の非選択にしたい場所が透過されている
- ようは透過画像を使いたい
デモ
処理の説明の前にとりあえずデモ。 左が処理前、右が処理後です。 処理前は星の外をクリックしても反応していますが、処理後は反応しなくなりました。
解決方法
RaycastMask.csをProjectにコピペ
RaycastMask.csをProjectに置く。 また、コピペする際、25,122行目のフラグがあると動かないのでそれを除いたものをする。
Projectにある使いたい画像の設定を変える
ボタンを作る
おわり
ちょっと解説
RaycastMask.csのざっくりとした処理
- 画像の情報を取り、透過されているかを判定する(GetPixcel)
- 透過されていない範囲にレイキャストを与える(ICanvasRaycastFilter)
GetPixcel とは
座標(x, y)のピクセルのカラーを取得します。Unity - スクリプトリファレンス: Texture2D.GetPixel
これで画像の状態を取ることができる。
ICanvasRaycastFilter とは
RaycastMask.cs が継承してるクラス。
この要素はレイキャストをフィルタリングすることができます。トップレベルの要素がヒットした場合、その位置が有効であるとさらに 'チェック' することができます。 ICanvasRaycastFilter - Unity スクリプトリファレンス
これを使うことで、uGUIの選択範囲を広めたり狭めたりできる。 詳しい使い方は以下のサイトをみればわかると思います。
Read/Write Enabled とは
テクスチャデータをスクリプトからアクセスできるようにします(GetPixels、SetPixels、その他の Texture2D 関数)。注意することとして、作成されたテクスチャデータは、テクスチャアセットとして必要なメモリ量は倍となります。必ず、必要な場合のみ使用してください。これは非圧縮や DXT 圧縮のテクスチャでのみ有効であり、その他の圧縮テクスチャの種類では読みこむことができません。デフォルトでは無効となっています。 テクスチャ - Unity マニュアル
これの設定がされてないと、RaycastMaskがGetPixcelで画像情報をとれないからチェックを入れないとダメだよってことですね。
最近読んでる本
はじめに
1月に入って1回もブログ書いてないのでとりあえず書きます。 書くことも特にないので最近読んでる本について書きます
日本人のための日本語文法入門
前回ブログにも書いた本ですね。 読破しました。 読み切った感想は日本語ってめっちゃ難しいんだなってことでした。 この本では英語を例に出して説明することがよくあるので英語の勉強にも多少なったような気がします。 この本を読んで以降、英語の勉強をしてる時、日本語の文法だとこうだったと意識するようになりました。 日本語の学習以外にもこう言った効果があったのは読んでよかったと思います。
理科系の作文技術
特に語ることのないくらい有名な本ですね。 これは丁度1年くらい前に一度読んでいましたが、論文を書くにあたってまた読んでみました。 1年前は読んでいた時はへーくらいにしか思いませんでしたが、今読むとなるほどな...ってなりました。
ベタープログラマ ―優れたプログラマになるための38の考え方とテクニック
いま1/3くらい読み終わりました。 タイトルから推測できるようにいいコードを書くために意識した方がいいことが書いてあります。 38個の短いセクションに分けれれていてよみやすくていいと思います。 ただ、テストコードの話などはやったことがなくイメージができないため、読んでいて結構退屈です。 将来的にまた読めば面白そうです。
日本語がわからない
はじめに
卒論の時期ですね。
卒論とかをかいていると日本語力がないのを痛感します。 エンジニアとして生きていくなら、英語はもちろん必要ですが、そもそも日本語ができないと話にならないので辛い気持ちになります。
なんだかんだで研究者にとって国語力大事ですね。もちろん理工系の研究者でも。英語力ですら究極的には国語力。
— Jun Rekimoto : 暦本純一 (@rkmt) 2017年12月15日
暦本先生も言っている通り、国語力は大切そうなので、日本語の勉強をちゃんとしないとなと思いました。
最近読んでる本
セールでちょっと安くなってたのでこんな本をかいました。 まだ半分くらいしか読んでませんが色々おもしろいです。
この本は、授業でやるような国語は日本人のための文法である学校文法ではなく、外国人に教えるような日本語文法の説明があるそうです。
読んでる感想
読んでて思うのは日本語ってめっちゃ難しい言語なんだなってことです。 母国語でなければ絶対話せない言語だったと思います。
英語との違いとかを入れて話してくれるので、英語の学習にも役に立ちそうです。 例えば、日本語の自動詞は自然中心の仕様が多いのが特徴で、英語は人間中心であるそうです。
他にも、日本語だと開けるの自動詞は「窓が開く」、他動詞は「窓を開ける」となりますが、英語だとopenだけで自動詞と他動詞の区別がありません。 こういった、自動詞と他動詞が同一である動詞が少ないのも日本語の特徴らしいです。
読んでいくに連れて、こんな難しい日本語が読み書きできるなら英語もなんとかなるのではという謎の自信が湧いてきます。
UNIXという考え方を読んだ
はじめに
今回は「UNIXという考え方」を（半年以上前に）読んだのでその感想をかいていきます。
UNIXにおける考え方やプログラミングをする上で大切なことはもちろん，研究や普段の生活でも言えるようなこともたくさんかいてあって面白い本でした。
本の感想
UNIXの考え方 : 基本的な9つの定理と10このUNIXの文化がかいてあり、それぞれ実例などを踏まえて解説していくって感じでした。
その中でも個人的に面白かったところや絶対覚えておこうって思った以下のセクションについて、ざっと簡単にまとめて思ったことをかいていこうかなと思います。
- スモール・イズ・ビューティフル
- できるだけ早く試作する
- 1つのプログラムには1つのことをうまくやらせる
- 森林を守る
- 部分的総和は全体よりも大きい
- 90パーセントの解を目指す
スモール・イズ・ビューティフル
内容
小さいものは、大きいものにはない利点がいくつもある。小さいもの同士なら、簡単に独自の便利な方法で組み合わせることが出来るというのもその一つだからだ。
目的とそれに対するアプローチを明確にして、細分化して実装すれば、似たような場所には同じプログラムを再利用できるよね。 ほかにも、小さいと再利用できるだけじゃなくて、わかりやすいし保守もしやすい、他のツールと共存しやすいなど様々なメリットがある。
思ったこと
最近はプログラムをできるだけいい感じのまとまりを関数にするように意識してプログラムを書くようにしました。
1つのプログラムには1つのことをうまくやらせる
内容
一つのことに集中することで、プログラムに不要な部分をなくせる。不要な部分があると、実行速度が遅くなり、不必要に複雑になり、融通が効かなくなる。
一つのことをうまくできるプログラムを複数組み合わせたりカスタマイズすることで、目的に沿った処理を果たせるほうがいいよね。 じゃないと、似たような目的なのに、それぞれに対して全て新しいものを作る「車輪の再発明」をするのは無駄だよね。 さらに、一つの機能に絞ることで、プログラム自体も小さくできるよね。
思ったこと
細分化するメリットがこれだなっていうのが分かった気になった。
できるだけ早く試作する
内容
あらゆるプロジェクトにおいて、試作は重要だ。一般的に試作は設計全体のうちのほんの一部として扱われているが、UNIXにおいての試作は、効率的な設計には欠かせない重要な一部だ。
仕様書とかをかいてないでとりあえず試作を作ったほうがいいよね。 試作を作ると何がうまくいき、何がうまくいかないかがわかるようになる。 これによって、様々なリスクを減らすことができるよね。
思ったこと
キレイなプログラムを書こうと考えてる暇があったら汚いプログラムでいいからとりあえずかいて、そのあとリファクタリングするのを意識するようにした。 あとは、研究でもとりあえずプロトタイプとかをさっさと作ったほうがいいのかなって思った。
森林を守る
内容
UNIXユーザーは紙のドキュメントを嫌う。全てのテキストファイルをコンピュータに保存して、強力なツールでそれらを操作するのだが、このことには十分な理由がある。
プログラムを印刷してメモをするひとがいるけど、印刷するとそのプログラムは並び替えも移動も編集もできなくなってしまって無駄だよね。
思ったこと
昔、印刷されたプログラムとにらめっこをしてるひとをみてワオっておもったことが、言葉にされてて個人的に感動した。 他にも、メモとかも電子化したほうがメリット多いよねって思う。 りんごペンを買ってからは紙に何かをすることをほとんどしなくなった。
部分的総和は全体よりも大きい
内容
小さい部品を集めて大きなアプリケーションを作るほうが、大規模プログラムを単体で構成すっるよりも柔軟性に富、したがってより役に立つ。どちらのアプローチでも同じ機能は達成できるかもしれない。しかし、先のことを考えると、小さい部分の集合によるアプローチのほうが有利だ。
思ったこと
これは上のスモール・イズ・ビューティフルに近いきがする。 細分化してモジュール化するのが良いよね。
90パーセントの解を目指す
内容
どんなことであれ、100パーセントうまくやることは大変だ。90パーセントのことだけうまくやれるようにするほうが、はるかに効率的であり費用対効果も最も大きい。UNIX開発者は、対象ユーザーの90パーセントが満足するかいを目指す。残り10パーセントは自分でなんとかしてもらうしかない。
思ったこと
昔、ツイッターでゲームに当てはめてこれを言ってたのを見た気がする。 完璧にやりこんで上級者になるのは大変だけど、中級者ならさくっとなれるしそのゲームを楽しめるよねみたいな。 最近やってるゲームが辛いのでふわっと楽しめるゲームをやりたい。
おわりに
150ページくらいしかなくてサクッと読める本だし、書いてある事も面白いので、こんなざっとした感想じゃなくてちゃんと本を買って読んでみると良いと思います。
どのセクションにかいてあったのか忘れたのですが、個人的に気に入ってるフレーズは「ソフトウェア開発に終わりはない。あるのはリリースだけだ。」という言葉です。 言われればそのとおりだなってなるんですけど、文字として表現されているのを見ると、自分の中でもやっと思ってたことが明確化されていく感じがします。
