Unityをいじってみた（その１〜作り始める前に〜）

はじめに

この記事から何回かに分けて、ゼロからUnityを使ってみて得た感想やノウハウをアウトプットしていきたいと思います。まだまだ浅い知識ですので、間違いなどありましたらご指摘いただければと思います。

Unityとは

Unityはゲーム開発のための統合開発環境です。元々は3Dゲームの開発のためにつくられており、3Dエディターとゲーム開発エディターが統合されたようなUIになっています。Unityを使う利点としては、Unityで作られたゲームをiOSやAndroid、Webブラウザなどマルチプラットフォームに配布できることや、AssetStoreというUnity専用のストアでコンポーネントを購入することで開発を効率良く進めることができることです。またUnity4.6からは正式に2Dゲームにも対応しました。

何をしたら良いかわからない

ゲーム開発には興味があったので、何度かUnityをインストールしてチュートリアルをやったことはありました。その時は、チュートリアルの通りにボタンをポチポチと押していって「やったー動いたー！」というところまでは行くのですが、いざ自分で何かつくろうとすると、何をしたら良いかわからない状態になっていました。（3Dで作りたいゲームのアイディアが浮かばなかったというのもありますが。）

一番の近道は、できる人に教えてもらう

そんなある日、たまたま補欠で参加した勉強会でUnityのプロに出会いました。そこで、次の勉強会までに、おそらく実現できそうな簡単なミニゲームのアイディアを考えて、その人に「これを実現するには何をしたらいいのか」をきいてみました。すると、ものの数時間で何をすべきかが見えてきて、それ以降は自分で調べながら進めるという軌道に乗ることができました。あの時の体験はほんとうに感謝です。

目標を決めることが大事

Unityはあらゆるゲームが作れるので、前述のように目標がない状態でさわってみても迷子になるだけです。目標があれば、チュートリアルや書籍でもある程度何をすべきかが見えてくると思います。Webでも日本語の情報がかなり多くなっていますので、一度走り始めることができさえすれば、調べながら進めることはそんなに難しくはないと思います。

作り始める前に知るべきこと

実際に作り始めてから知って、困ったことは次の通りです。

• ライセンスによる違い（無料版とPro版）
• プラットフォーム間の違い（iOSとAndroidなど）

まずライセンスによる機能差異については、次のページに書いてあります。

ライセンスのご案内

いきなりこれを見ても何がなんだか分からないと思います。このうち自分が困ったことは、『アセットバンドルによる本格的なストリーミング』という機能です。アセットバンドルとは、よくゲームなどでインストール後の起動時やアップデート時にデータをダウンロードする機能です。これについては後で詳しく書きます。

[本文修正] 記事を書いた翌日にUnity5がリリースされ、情報が古くなってしまいました。Unity5になり、ライセンスによる機能差異はほぼ無くなり、ProfessionalEditionの方は大規模開発や商用化に向けて必要な機能が追加されました。機能差異については次のページを参照してください。

Unity - Get Unity

またプラットフォーム間の違いについても色々ありますが、一番厄介なのは（これはUnityとは直接関係ないですが）iOSのアプリ申請の厳しさだと思います。なので、iOSをターゲットにする際はアプリ申請基準を十分に確認する必要があります。もし、初めてアプリを作ってそれを公開したいのであれば、まずはAndroidをターゲットにすることをお勧めします。

ここまではうんちくばかりでしたが、次回からは技術的な話に入りたいと思います。

第4回社内勉強会を開催しました

レポート

今回のテーマは「コードレビュー」でした。

自分もメンバーもコードレビューをそんなにしたことはないので、まずイントロとしてSonicGardenStudyさんのオンライン勉強会の内容を簡単にまとめたものを紹介しました。

KokubunjiStudy03 - Google スライド

内容としては以下の３点。

• コードレビューをしないとどうなるのか（ウンコード・マニアさんの事例とかを紹介）
• 良いコードレビュー・悪いコードレビューとは
• コードレビュー時における注意点（技術面・精神面）

そのうえで、他のメンバー二人が用意してくれたコードレビューを実施しました。一人はEnchant.js、もう一人はRPGツクールのスクリプト（Ruby）です。どちらもゲームエンジンプログラムということで、両方を見比べられたのが興味深かったです。特にツクールのスクリプトは、あらかじめ用意されたクラスモジュールやドキュメントが充実していて、Rubyを勉強するにも非常に良い題材になっているという印象でした。

レビューをガッツリやったというよりはアルゴリズムとか動きの確認が多かったですが、ソースの改善としては以下のような内容がありました。

• 定数値はそのままコードに書くのではなく変数にする。
• if文が深くなった。どうしたらいいか？→1.機能単位でまとめて関数化する。2.（クラスインスタンスのパラメータ操作が多かったので）クラスメソッド化する。

KPT

Keep

• 開始時間を1時間遅らせて、先に飯を食う。（腹ペコな若者が多いからｗ）

Problem

• 特定の技術についての集まりではないので、参加者の知識にばらつきが大きく、なかなか話に入っていけない人が多い。
• 自由すぎて目的がよく分からない。

Try

• 目的について再整理。どうやったらみんなが楽しく参加できるか考える。

第3回社内勉強会を開催しました

の前に、第2回の記事を書くのを忘れてしまいました。

第2回はテーマなし（フリー）で行いました。自分はWebの通信方式（HTTPやAjax、WebSocket、WebRTCなど）の概要的な発表と、自分が過去に作ったサービスでWebSocketを使った事例を紹介しました。

KokubunjiStudy01 - Google スライド

それから後輩君が、自分が第1回に紹介したスクレイピングの技術を使ってサービスを作った話を発表してくれました。しかもこれが初めてのLTとのことで、こういう反応があると非常に嬉しいです。

そして第3回目を今日はテーマは「ゲーム開発に関する技術」でした。自分はiOS（Swift + Spritekit）でゲームを作るという発表をしました。

KokubunjiStudy02 - Google スライド

Xcodeの環境やObjective-CのサンプルをSwiftに変換することにかなり手間取り、プロトタイプにも満たないところまでしか作れませんでしたが、苦労した分、得るものも結構ありました。（ある程度の完成度まできたら、ブログにも書こうと思います）

さらに今回は初参加の方も2名来てくれました。普段会社では技術よりの話とかしない人でも、意外と興味を持っている人が多いようです。どこまで輪を広げようかは相変わらず手探り状態ですが、当面はこのくらいの規模がやりやすいかもしれません。

あとLTに関しては自分は特に下手クソなので、もっとLT力をつけて、LTって楽しい！ってことを自分が感じられて、みんなにも伝えられるようになりたいところです。

社内勉強会を主催しました

自分が今の会社でエンジニアとして幸せになるための手段の一つとして、技術に興味がある仲間を増やしたいという思いから勉強会を主催しました。勉強会を思い立ったきっかけは、KitchHikeのCEOでいつもお世話になっている@syokenzさんが、昔勤めていた会社で同じような動機から勉強会を作ったというエピソードを聞いて、自分もやってみようと思ったからです。

今回は初めてだったので今後の活動方針の話し合いと、残りの時間でLTの発表しました。自分のスライドはあんまり役に立つものではないですが貼っておきますｗ

http://slides.com/ryosukeigarashi/kokubunjistudy00#/

・The hottest device

・Scraping入門

やってみた感想としては、

・全員Mac使いだったのでMacの便利ツールとか共有できた

・それ以外にも自分が知らない情報をたくさん得ることができる

・人前でプレゼンする練習になる（社内の人だけなのでやりやすい）

・発表のネタを考えるのが楽しくて勉強のモチベーションになる

などなど、かなりいいこと尽くしでした。単純に楽しかったし。

今後しばらくはこのまま続けて、いずれはもっと輪を広げてみたいなと思ってます。

性格をコントロールする

前回の記事に引き続き、モヤモヤ系エンジニアの自己分析ｗ

前回の記事（愚直であれ - Persistence）では、とにかく愚直にやってみるということを書きましたが、そうと決めてもやはり勉強のスピードが出ないものです。

パターンとしては、①作りたいもの（目標）を考える、②それに向かって必要な知識を習得したりものづくりを始める、③作っていくうちに作りたいものがほんとうに必要なものかわからなくなってくる、④スピードダウン・停止、という流れです。愚直に突き進むことを徹底するなら③のステージになってもスピードを緩めない方がいいのですが、作りたい熱意・動機がそこまで高くないので③のステージで負けてしまうっていうパターンですね。愚直を突き通すには強い動機が必要であり目標を見失わないことが大切ってことが分かりました。

これはあくまで自分の例なので、この記事を読んでいるモヤモヤ系エンジニアの方すべてに当てはまるわけではないですが、このように自分の性格による行動パターンを認識して受け入れてあげることで自己嫌悪に陥らずストレスも少なくなるのではないでしょうか。

このことは、たまたま読んだ「つまみぐい勉強法」という本の中でも触れられていて、この本の中でも４つの性格ごとに適した勉強法が紹介されていました。（どれが一番いいとかは無しに）

IT業界を楽しく生き抜くための「つまみぐい勉強法」 (技評SE選書)

本の中の言葉をそのまま使うと自分は「坂本龍馬タイプ」になったのですが、興味がすぐに移り変わるとか、すぐ飽きるとか、興味が無いことはできないとか、まさに自分の性格そのまんまが書かれていてちょっとビックリしましたが、そういうやり方でもいいんだという安心感を得られました。

このやり方だとスペシャリストにはなれませんが、ジェネラリストにはなれます。自分は「技術力を伸ばしたい」よりも「サービスを作りたい」という欲求のほうが強いというのは分かっているので、実は自分でも気づかぬうちに自分にあった最適な方法をしていたのかもしれません。

まとめ

• 愚直にやり続けるのは自分の性格に合わないので、自分が本当にやりたいテーマが見つかるまではいろんなことをつまみ食いし続ける（つまみ食いしながらも勉強は継続する事が大事）
• 途中で飽きたりしても自分の性格はそういうものと割り切り自己嫌悪しない。

おまけ

その優柔不断な性格を直した方がいいのでは？と思う人もいるかもしれません（自分もちょっと思ってるｗ）。でも自分の考えでは、性格はそう簡単に変えられるものではないし、いろいろな性格の人がいるからこそ多様性があっていいのだと思う。（ちょっと話は飛ぶけど、）一説によると、人類が他の生物よりも進化できたのは、他の生物は弱い種を淘汰しより優秀な種を残すことで生き延びる戦略をとってきたのに対して、人類は多様性を許容したからだと言われている。

それでも性格を変えたいという人には、このあいだ吉政忠志さんの転職に関する公演で教えてもらったマザーテレサの有名な言葉を紹介します。

思考に気をつけなさい、それはいつか言葉になるから。

言葉に気をつけなさい、それはいつか行動になるから。

行動に気をつけなさい、それはいつか習慣になるから。

習慣に気をつけなさい、それはいつか性格になるから。

性格に気をつけなさい、それはいつか運命になるから。

愚直であれ

技術エントリーではなく、気持ちの整理的なエントリーです。

技術力のなさを痛感

最近、転職活動をしていたり、技術力の高い人達と共同作業をさせてもらう機会があって、自分の技術力・知識量が本当に低いなということを痛感してます。特に転職活動については、自分が望むようなWeb系ベンチャー企業に対しては完全に力不足であることが分かりました。

自己分析

そんな凹むことが多いこの頃ですが、新しい気づきもあります。まず技術力については現状は現状として受け止めるしか無いとして、何が問題なのか自己分析をしてみましたところ、成長のスパイラルができていない事が分かりました。

成長のスパイラルは、以下の①〜④で回ると考えています。

①物事を始める ②壁にぶつかる ③壁を乗り越え達成感を得る ④次のステップへのモチベーションが湧く

しかし、自分の場合は②の部分で諦めてしまうことが多く成長のサイクルが回っていませんでした。②で止まった後どうなるかというと、以下のようなループになります。

①物事を始める ②壁にぶつかる ③モチベーションが下がる ④今やっていることより他の事のほうが面白そうに見える

②で止まってしまう人のパターンとして、簡単に言うと「根性なし」な性格なんですが、もっと深く行動心理について調べると、「心理的なストレスに弱い」ということらしいです。それに壁を登ることを楽しくできないようであれば、エンジニアには向いてないんじゃないかなとも思いましたが、それを決めるのはまだ早いです。

ストレスに弱いのは生まれ持った性格と育った環境によるものなので仕方ないですが、成功体験をたくさん積んで自分に自信が持てればある程度は変えられるのではないかと思います。そのためには、一度決めたことを愚直にやり続ける事が大事だと考えています。「継続は力なり」っていう言葉は知っているし重要性も理解していると思っていたけど、全然わかっていなかったことに気づけました。

それから技術的な自分のポジションもわかったことは多きな成果です。自分はやっとホイミとかギラとか覚えたくらいのレベルです。何故それがわかったかというと、相対的に自分よりがレベル高い人たちが自分の周りにたくさんいるから。だからそういうところに飛び込んでみるっていのもやって良かったと思います。

あと課題として見えてきたことは、アルゴリズム力（つまり論理的に思考を組み立てる能力）が無いということ。自分はサービス指向が強いのでWeb系のフレームワークとかライブラリばかりを使っていたけど、それって用意された道具を使っているだけで、プログラマとしての基礎体力はアルゴリズム力何じゃないかと思った。これがないとコピペはできるけど1から作ることができない人になります。

まとめ

• やると決めたことを脇目もふらず愚直にやりきる
• 困難に立ち向かうことを楽しむようにする
• アルゴリズムの勉強をする

すごいディーラーリストを作った

ドルパ（公式）のディーラーリストが見づらいって思うので、Railsの練習がてら「俺が考える最高のディーラーリスト」を作りました。

すごいディーラーリスト for ドルパ31

最高の〜〜〜と言いつつ完成度は50%です。100%を目指していましたがドルパが終わってしまいそうなので、やりたいことの半分ができたので公開に踏み切りました。残りの50%はUI部分なので使ってもらってフィードバックを得て次のドルパまでに100%にしようと思います。（なのでUIはほんとにやっつけです。すごい使いづらい。）

やりたかったこと

技術課題として主に2点がありました。

• ディーラーサイトのスクリーンショットとRSSを自動収集して表示する（できました）
• AngularJSを使ってページングや検索・フィルタリングが柔軟にできる（間に合わず）

技術的なこと

Qiitaに投稿しました。

Ruby - Rails4+MongoDB+Herokuでサイトのサムネイル画像を保存・参照する方法 - Qiita

Qiitaにも書きましたが、無料でホスティングしたかったので画像をBinaryでDBに保存したのが今回チャレンジしたことの１つです。

HerokuのMongoHQは無料で500MBまで使えるので、1つ100KBで単純計算で5,000枚まで行ける計算です。計算だったんですがそんなに詰め込めないようでした^^;