スマホ開発でも活きたこと、まだ活かせていないこと 170325 1043

スマホ開発でも活きたこと、まだ活かせていないこと 170325 1043

1. 1. スマホ開発でも活きたこと、ま だ活かせていないこと 2017/3/25 平山尚
2. 2. 誰だおまえ ● ずいぶん昔→の本を書いた者です。 ● 元家庭用/ゲーセンでGL/DX叩きとか14年。 ● Unity歴6ヶ月 ● 面白法人カヤックの新入社員
3. 3. 何の話? ● 15年ゲーセン/家庭用にいた人間がスマホに行ってどうだったか。 ● ネタは大きく分けて4つ ○ C++とハードのSDK→C#+Unity ○ スマホ ○ 開発体制や環境 ○ 文化の違い
4. 4. 誰向け? ● スマホ行くか迷ってる家庭用(ゲーセン含む)の人 ● 家庭用の人をゲットしたいスマホ開発の人 ● 家庭用から来た人の扱いについて考えてるスマホ開発の人 ● 下層の技術って役に立つの?と思ってるスマホ開発の人 ここの皆さんの組成はどんなでしょう?家庭用/ゲーセンの人どれくらいいます?
5. 5. では、4つの違いについて 1. C#とUnity 2. スマホ 3. 開発環境や開発工程 4. 文化
6. 6. 言語が変わると大変ですか? ● C++とC#では結構違う ○ ポインタない ○ ガベコレ ○ constつけられない ○ 破棄タイミングが放っておくと不定 ○ yieldって何だ?
7. 7. でもまあ、だいたいは大丈夫 ● C++ですら結構デカい。それを使えてるなら基本はできてる。 ○ boostとかSTLとか使ってれば高水準な書き方は慣れてるはず。 ● 基本的にはプログラミング言語なんて大した問題じゃない。 ○ よほど違えば別だけど、 whileあって変数あって関数あって、みたいな所は一緒。 ● constなくてもやりようはある ○ どうしても欲しければ変更関数つぶしたインターフェイス作って渡せばいい ● structでnewのダメージを軽減できる ○ でも何回か罠にはまると思う。 ■ var item = items[4]; item.hoge = 5; とかしてひどい目に遭っておくといい
8. 8. 怖いのは言語そのものというより使い方 ● イベントドリブン設計 ○ Updateで回さずコールバックの集合としてアプリを形成している。慣れない。追えない。 ○ 破棄した後に呼ばれる危険に怯えてとにかく nullチェック。怖い! ■ C++の人には「delegate=this+関数ポインタ」と言うとわかりやすい ? ● リフレクション怖い ○ 一箇所も呼び出し箇所ないのに、関数削除したら挙動が変わる !! ● コルーチン ○ update+switchで書くより楽だが、デバグは困難。 ■ ブレークで止めてもどの状態なのかわからない。 ■ 多重起動や他のコルーチンとの相互作用へのケアが必要。漏れるとバグる。
9. 9. Unity特有の問題も ● UpdateやAwakeなどの呼出順が不定。 ○ クラスを木のように構成しようとしても、初期化順や破棄順を固定できない。 ■ あとはそもそも木にしようと思わないか ... ○ AwakeやOnDestroyでは他のMonoBehaviourに触らない、が基本ルールか ? ● Destroyで変数がnullになる ○ C++の「持ってるポインタが他で開放されて不正アクセス」が起こることに近い。 ○ nullかチェックできるだけマシだが、破棄順が不定なこともあって面倒くさい。 ○ 普通に「参照があるうちは消えない」じゃダメなの ? ● マニュアルに何も書いてない。書いてあっても変わる。 ○ 「公式文書にやって良いと書いてなければやらない」だと何もできない。 ○ 急に仕様が変わって動かなくなる覚悟をしておく。 ● ブレークポイントが使い物にならない...誰かどうにかして...
10. 10. 木? ● クラス間関係を木にしてうまくやると以下の保証ができるが... ○ 親は子よりも先に初期化されている ○ 親や子よりも先に破棄されない ○ 親子の更新順は固定 ● MonoBehaviourでやろうとすると標準から外れる。相性悪い。 ○ Initialize,Terminate,UpdatePreChild,UpdatePostChild...とか作ることになる。 ● というわけで、本格的に導入はしてない。
11. 11. C#がいい言語なのはよくわかった ● 「生きてるキャラクターの配列を返す」みたいな時にnewしなくて済む。 ○ yieldいいね。 ● delegateはC++でも同じことはできるが、楽に書ける ● enumの文字列化が標準なの楽 ● インクルード気にしなくていいの楽 ○ クラス間のやりとりの設計が雑になる副作用はあるが ...
12. 12. 描画はどう? ● 今までGLやDirectXを直接叩いていたが、違和感はないか?
13. 13. 描画部作ったことあれば中身の想像はつく ● 自分で似たようなもの作ったことあれば中身想像つくでしょ。 ○ ex.どうせ頂点詰めてるんだから動かしたら遅くなるよね Canvas。 ● 行列が見えてれば、RectTransformのパラメータ群も理解できる。 ○ →で選ばずminとmaxを直打ちできますか ? ● C#のプロパティのどれが重そうか想像つく。 ○ 元データはlocalPositionだよね。positionって計算して出してない ?
14. 14. 例:AfterEffectsからの移植 ● AfterEffectsでデータもらったのをUnityで再現したい! ○ anchor,position→pivot,localPosition,anchorMin,anchorMaxへの変換 // 左上原点に transform.anchorMax = new Vector2(0f, 1f); transform.anchorMin = new Vector2(0f, 1f); // 基準点は[0,1]なので幅と高さで割る。yは反転。 transform.pivot = new Vector2( aeAnchor.x / transform.sizeDelta.x, 1f - (aeAnchor.y / transform.sizeDelta.y); transform.anchoredPosition = new Vector2(aePos.x, -aePos.y);
15. 15. 2.スマホという機械
16. 16. 家庭用と大して違わないだろと思ってた PS VITAから6年も経ってるし、それより速いだろ?普通に考えて。 いい奴はPS3超えてもおかしくないし、悪くてもVITAの半分は出るよな? 帯域 CPU メモリ量 PS3 22GB/s + 25GB/s 3GHzが2個 256MBとか 私の404KC(安物) 4GB/sくらい? A53の1.1GHzが4つ 1GB VITA 知らない A9が4つ 512MB以上
17. 17. 誤算 ● Unity、ほぼ1コアしか使ってないよね? ○ 安物スマホのCPU(A53系)はコアあたりはだいぶ弱い。 ○ きっと物理とか使えば生きるんだろうけど、うち 2Dなのよね。 ● 電気と熱 ○ そもそも最大性能なんて出ない。 ○ 「想定する一番ショボいので想定 FPS出ればいいだろ」は不十分 ■ 高性能マシンではFPSが上がってむしろ消費電力が増える恐れすら ... ● 解像度 ○ この性能で1920x1080とかキツいわ ■ たぶん適切に削らないとダメだが、削ると文字は汚なくなるしなあ ...
18. 18. 誤算2 ● メモリ全部使えないし、使いたくもない。正味200か、せいぜい300? ○ 「収まってればいい」じゃダメ。ツイートして戻ってきたら落ちてる、とかヤでしょ。 ● 2Dだからテクスチャの容量がヤバい ○ ミップマップなしにすると低解像度端末でエイリアシング +キャッシュミス性能低下 ... ● 2DだからZテストでピクセル止められない ○ ほとんど奥から順に描くので、適当にやると塗り面積がエグいことに。 ● Canvas普通に使うと透明部分がえらい面積に。 ○ 8角形くらいになりませんか。せめて非長方形。 ● マスク気軽に使ってるけど、これヤバくね? ○ 広大な面積ステンシル塗ったりクリアしたりしてませんかこれ。 ○ というか、マスクさえなければ Zバッファ使いたくないんだけど、切れるの ?
19. 19. 誤算3 ● 描画関連CPU負荷デカくね? ○ たかだか100バッチで音を上げるってどういうこと ?Unityのせい?GLのせい? ○ 昔組み込み系でglDrawArraysで100回3角形描くだけで音を上げるのを見たことがあるが ...
20. 20. 3.開発体制と工程
21. 21. 何もかもGitHub ● gitHubにプルリク作ってレビュー必須 ○ 前はレビューもなくmasterにつっこんでたので、ほとんど操作知らなかった。 ● 大変だったけど慣れた。3ヶ月くらいかかったけど。 ○ commit, add, push, fetch, merge, checkout, branchくらい? ■ 慣れないうちはpullせずfetch+mergeしてた。その方が理解が速い。 ■ pushもブランチ名毎回指定してると理解速いしミスらない。だんだんわかってくる。 ○ resetとか、単体ファイルcheckoutとかは、まだ都度web見てる。 ○ 最近は結構VSCodeを通してやってる。楽。 ○ たまにpushしてから手元で戻して面倒なことに。 push -f覚えた。
22. 22. 実機で動かすには ● gitHubのプルリクでbuildってコメントすると、謎の社内サイトにapk/ipa。 ○ ローカルでビルドしたことない。 switch platformはインストールの時くらい。 ○ 裏にjenkinsがいてよろしくやってるらしい。 ○ mono版androidだけ、とか指定できる。ビルド速いので大抵それ。 ● 全体にサーバ屋さんの文化が強いので、そっちの環境整備は信頼できる。 ○ 会社規模の割には充実してるとのこと。 ○ サーバ側がどうなってるのかまださっぱりわからない。
23. 23. 「回して帰る」がまだできてないなあ ● 帰る時デバッガつないだ状態で朝まで回しとく、みたいなことはやれてない ○ 防犯上PC起動しっぱなしで帰れない。ノート PCだし仕方ないかー ● そもそもそういう文化がなかった。 ○ スマホだと長時間回す必要ないから ? ● 実機でエラーをサーバに送る仕組みはあるので、毎晩ありったけの実機で回して帰 ればいいんだが... ○ ビルド、インストール、起動、まで自動化したいなあ。 ○ 統計も取れるし。 ○ 充電が間に合うくらい消費電力下げないとダメだけど。
24. 24. 初めての「サーバ前提」開発 ● 通信入るのでいろんなものが非同期になる。 ○ エラー処理も複雑! ○ Updateベースでなくコールバック主体設計になるのはこのためだろうけど、追えない ... ● データのやりとり大変! ○ 独自のデータ型定義ファイルから自動でサーバ用のコードと C#のクラスができる。 ● Unityだけで済まないケース多い。イテレーション遅くなる要因になりそう ○ 開発規模が大きくなると問題になりそう。これからの課題かもしれない。 ● そのうちサーバやりたいな ○ Unityいじっててもサーバの人とやりとり多いので、自然に知識がついてくる気がする。 ○ C++で身につく「言語なんてなんでも一緒だろ」感は役に立ちそう。
25. 25. 4.文化
26. 26. マジちゃんとしてる ● 毎朝ラジオ体操、朝会。 ● 毎日slackに「やること、やったこと、問題」を報告 ● 夕会。 ● 会議予定等はgoogleカレンダーで共有 ● 5分遅れでもslackに書き込むのが普通なほどの規律 転職前はユルかったので、適応が大変だった。
27. 27. Slack!!! ● 隣の人とslackで話しとる!!! ● 慣れるのに4ヶ月くらいかかった。 ○ さすがに弊害多くね ?と思っていたが、slackはメールほど悪くない。 ○ 絵文字で反応できるの最高。 twitterにもほしい。 ● 「効率を上げるにはコミュニケーションの非同期化が重要」って言うし ○ これはこれでアリかな。慣れたし。 ● 家と会社の境はないけどな。 ○ 最初は自分のスマホに slackを入れないでがんばってたが、折れた。慣れたけど。 ○ ノートPCで、コードgitHubだから家でも変わらず仕事できて、本当境がない。 ■ 最近だと引越しで休んでる中バグ直してた。
28. 28. 広告やwebの人多数 ● 発想新鮮!! ○ 前の会社にいないタイプの人多数。たーのしー !! ● ゲームのイメージが凝り固まってたことを実感した。 ○ IPとか運営とか、以前は興味なかったので。 ○ ゲーム=商品 → ゲーム=店もしくは広告、というシフトが起きてるのかなと感じる ● ゲームっぽいゲーム部分では貢献できそうな予感 ○ あるコア要素が長時間繰り返して面白い、というのは広告や webには薄い概念かもしれない。まだ よくわかってないですが、印象として。 ○ ...もっとゲーム本体作ってれば良かったなあ。ライブラリばっかりやってたの残念。
29. 29. 元家庭用プログラマ、私だけっぽい ● 家庭用から来たプログラマの話を聞かない。まさか私初めてか? ● 先達がいないの辛い!!! ○ 違いをわかってる人に聞ければしなくて済んだ苦労はいっぱいある。 ■ C++やGL/DXに置き換えて説明してくれる人がいたら楽だったなあ ... ○ 低レベルから書いてしまう選択肢の有効性は実際見せないとダメ ■ 動的にポリゴン生成して曲線描くとか、そういう選択肢が出てきにくい ● でもそれはむしろチャンス ○ 競合がいないんだから活躍するチャンス !!...のはず。これからよ!
30. 30. 終わりに
31. 31. 今家庭用/ゲーセンにいる人へ ● 案外どうにかなります。まだ半年で完璧じゃないですが。 ● Unityは未だに好きになれませんが、まあ慣れますよ。大丈夫。 ● unityとC#とgitとslackに慣れた後は、やってきたことを活かせるでしょう。 ○ 行列とかベクトルの操作慣れてない人多い。 ○ 「これ下ステンシルだよね」みたいな勘がないと、そのへんの webサイトに書いてあることを真に受 けて試す以外の手が取れないので、下知ってると強いかも (希望的観測) ● スマホ、ネットワーク、文化、等々により誤算は多いです。 ○ ex. 「こんなん解像度落とせば速くなるだろ」 →「全くならない!100バッチでCPUかよ!」 ○ 「前はこうしていた」は慣れて力を示してから言う方がいいと思う。 ○ 「オレのスキルを教えてやろう」という気持ちでいると死にます。学びに行け。 ● サーバとかの新たなスキルをゲットするチャンスも増えます。 ○ 転職して逃げ場を断つと成長速度ハンパない !!たーのしー!!
32. 32. スマホ側から私みたいなのを見る人へ ● ベクトルと行列はUnityでも役に立ちます。勉強してみては? ○ わからないでやれる範囲で作るという選択もアリですけど。 ● 直接GLで描くような経験も役に立てられます。WebGLでもやってみては? ○ わからないでやれる範囲で作るという選択もアリですけど。 ● アルゴリズムの知識も役に立てられます。勉強してみては? ○ 何もかもDictionaryで書いてもそう悪いことになりませんけどね。 ● ...私みたいなのがいなくてもゲーム作れますね。今の時代。 ○ でもまあ、来ちゃったら有効活用するといいと思います。「こいつのスキルあったら何ができるように なるか」を考えてみると、幸せになれるかもしれません。 ○ でも、家庭用とは諸々違うんで、何かうるさく言うようなら 上手にスルーしましょう 。時代が変わって るんですから。