「第9回 Unity開発技術勉強会 〜先行事例紹介／交流会〜」でのプレゼン資料。

1. ゴルフゲームで
Unity の限界を突破する方法
KLab 株式会社
饒平名 秀成

2. 自己紹介
• 饒平名 秀成（のひな ひでなり）
– へなちょこエンジニア
– 入社４年目の新卒２年目（いわゆる新古品）
– 沖縄県宮古島出身
六本木でモバイルゲームつくったり Unity で遊んだりしてます。
絵描きになりそびれて今はエンジニアやってます。
実家のマンゴー畑の行く末が当面の悩み・・・

3. KLab 株式会社 ってどんなと
こ？
• 六本木の高い建物の中にあります。
← だいたいこの辺

4. KLab 株式会社 ってどんなと
こ？
• ほかにもいろんなところにあります。
・六本木
・大阪
・福岡
・仙台
● ● ・シンガポール
●●●
●
・サンフランシスコ
・マニラ
● ●
・上海

5. KLab 株式会社 ってどんなと
こ？
• モバイルゲームとかつくってます。
こんなのとか

6. KLab 株式会社 ってどんなと
こ？
• 中の雰囲気はこんな感じです。
こんなかんじ
※ 一部 941 ブログさんからお借りましました

7. 今回紹介するもの
• ゴルフパラダイス ( 仮 )
※ 商標の関係でタイトルは今後変更予定
– スマートフォン向け本格ゴルフゲーム
– 今冬リリース予定

8. ゴルフパラダイス ( 仮 )
• スマホで綺麗グラフィックなゴルフコー
スを体験！

9. ゴルフパラダイス ( 仮 )
• 個性的なキャラクター！

10. ゴルフパラダイス ( 仮 )
• 多彩なバリエーション！

11. ゴルフパラダイス ( 仮 )
• いっしょにコースをまわるお供！

12. ゴルフパラダイス ( 仮 )
• トリック、必殺技による派手な演出！

13. ゴルフパラダイス ( 仮 )
• ここがこだわりポイント！
– ボールを遠くへ飛ばす爽快感
– スマホでもハイエンドなグラフィック
← ちなみにこんなプレイ画面（仮）

14. DemoTime

15. ここから本題

16. 今日のおはなし
• そもそもなんで Unity だったのか
• Unity の限界突破！
• 綺麗グラフィックを追求するまでの道の
り…

17. の前に

18. ちょっと前置き

19. 詳細なことを説明したら・・・
• Unity というよりも個別の開発論の話に
なっちゃいました。
• かなりエンジニアよりの話をします。
ご了承を――― (^^;

20. では、気を取り直して

21. そもそもなんで Unity だったの
か

22. 入社間もない彼の頃
～大阪勤務なバイト時代 09’ ～
突然の本社からの電話。
「のひなくん、 3D って興味ない？」
え？
「 3D ゲームの企画が出てるんだけど作らない？」
え？ え？
「じゃぁ、企画書送るからあとはよろしく！」
えええええぇぇぇ！？
そのまま添付メールで企画書がやってきました。

23. 3D の知識もなかったので
いろいろとググる。まずはグーグル先生頼り。
なんか 3D のゲームエンジンがフリーで公開されたらしい
。
Unity とか言うらしい。あと Unreal っていうのもあるら
しい。
とりあえず簡単そうな Unity で触ってみるか。
日本語ドキュメントなくてよくわからないけどまぁいーや
。

24. で、つくってみた
なんか知らないけど、ソフトいじってたらゲームになって
る。
コードもあまり書く必要はない。
よく知らないけど動いた！すげー
「あ、動いたんだ。じゃぁ、経営会議でプレゼンしてき
て」
「出張申請しておいたから、あとはよろしく！」
えええええぇぇぇ！？
そのまま六本木に飛ばされました。

25. 時は流れて
正社員になって東京勤務に慣れてきた頃。
当時運用していた某ゴルフゲーム界隈にて。
「やっぱりガラケー向けはちゃっちいよね」
「もっとハイクオリティなことやりたいよね、 3D とか」
「そういやのひなくん昔 Unity とかいうのやってたよね」
え？
「じゃぁ、ゴルフで 3D で爽快感だから！あとはよろし
く！」
えええええぇぇぇ！？

26. とまぁ、
脚色は入っていますが、だいたいこんな感
じ。

27. 冗談はさておき、

28. なぜ Unity を選択したのか
• 主だった処理はエンジン側がだいたいや
てくれる。
• なので動くものを見せられるまでが早い
。
• 他社のものとくらべても比較的安価。
• コミュニティが活発で問題が起きても誰
かしらがそれを解決してくれている。

29. 楽にサクっと作れちゃいます！
• 動くものができるまでは本当に早い。
当時のプロトタイプ。
グラフィックはいまい
ちだけど、一通りゴル
フができるものがひと
月くらいでできた！

30. ちなみに、
• これが

31. ちなみに、
• こうなって

32. ちなみに、
• こうなって

33. ちなみに、
• こうなりました

34. しかし、そう上手くはいかないも
ので
• Unity はだいたいなんでもやってくる
• けれど思わぬところに落とし穴が・・・
– シンプル設計が故に意外とかゆいところに手が届か
ない
– 品質向上のためにはそれなりの努力が必要
– コアの部分に手をつけたくてもコードが公開されて
いないから無理
– 多人数で開発した際のコンフリクトの多発問題
意外と予想外な問題に突き当たる。
プロトタイプを作ったあとの開発はそんな
に楽じゃない。

35. 特に問題を抱えたのが
• 物理演算
– Unity の Rigidbody はあくまでも剛体シミュレー
タオンリー
• 速度と重力の計算しか入っていない
• 空気抵抗などの計算があまり考慮されていないので、実際
のボールの軌道とは似つかない
– ボールに回転を加えても無回転で飛んだ状態と同じものとし
て計算される
– 回転が挙動に大きく影響を与えるものには向かない
– 処理がブラックボックス化されていることによる問
題
• 厳密な計算が難しい。
「このドライバーでこれくらいの力で打ったら 230 ヤード飛ぶ」
というようなパラメータの設定や推定が難しい。

36. これは Unity の限界

37. そこで

38. Unity の限界突破！

39. 我々がやりたいこと
• 打撃に爽快感が欲しい
• 回転で浮き上がり、空気抵抗で失速しな
がら飛んでいく、現実のゴルフボールの
ような挙動を実現したい
– これは Unity の生の演算処理では不可能
← こういう軌道にしたい
http://yspz.blogspot.jp/2010/04/4.html

40. 実際にやったこと
• 物理演算部分は Unity のものを使わず
、自前で実装する
– ただし、あくまでもゲームなので、精度を
追求するわけではない
– 要件を満たす程度にある程度の物理的な挙
動を模擬する
– こだわるのは打撃時の爽快感

41. 前提
• 滞空時の動作に対する演算は、
– 速度（ Velocity ）
– 質量（ Mass ）
– 空気抵抗（ Drag ）
– 重力（ Gravity ）
くらいしか使われていない
ちなみに、 Drag や Mass の影響を出ないようにパラメータを調整し
て、 Unity の生の演算と、自前で処理をかけたものを比べるとだいたい同じ
結果になった。
rigidbody.velocity += Physics.gravity * Time.deltaTime;
• また、使われているものもそこまで
厳密ではない

42. 大まかに定義してやるもの
• ボールに対する空気抵抗
• 回転による揚力

43. 要は流体力学！

44. まずは資料の収集
• ゴルフボールの弾道シミュレーションに
利用できるデータは多くがネット上に公
開されている
– 学術論文
• 実際の演算方法
– 企業の特許情報
• 空気抵抗係数などのパラメータ

45. とにかく集める！

46. とにかく読み込む！

47. なるほどわからん (´ ・ ω ・｀ )

48. でも、

49. なんかよくわからないけど

50. 書いてるとおりに実装したら
動くのかしら・・・

51. なんかよくわからないけど・・
・

52. ということで実装

53. 実際に使った計算
• 定数定義
– Fw : 重力
– Fd : 抗力
– Fl : 揚力
– U : 対空気速度（ m/s ）
– N : 回転速度（ rps 。ゴルフ関係の資料は rpm なことが多いので注意）
– m : 質量
– g : 重加速度
– d : ボールの直径
– A : 前面投影面積
– ρ : 空気密度
– Kv : 空気動粘度
– Cd : 空気抵抗係数
– Re : レイノルド数

54. 実際に使った計算
入手した資料内の公式から
– Fw =m*g
– Fd = 1/2 * Cd * ρ * U^2 * A
– Fl = 1/8 * π^2 * ρ * d^3 * U * N
とすると、ボールにかかる力 F は
– F = Fw + Fd + Fl
各種パラメータを決めてやって、
上記の式に入れ込むとボールの移動速度が算出できる。
※ この資料で利用する公式は一部ゴルフボール
を完全に球体だった場合として簡易的に近似
していることに注意。

55. 実際に使った計算
• 定数の値の設定
– まず、簡単に決められるものから
m = 45.3 / 1000 ※1
d = 42.7 / 1000 ※1
g = -9.81 ※2
あたりの数値を入れる。
※1 これは各社のゴルフボールの規格によって変わるので適当
な ものをんでやる。
※2 g は実際には Vector3(0, -9.81f, 0)
とか Physics.gravity とか使ってや
れば良いよ。

56. 実際に使った計算
同様に、入手した資料内の公式から
– A = 1/4 * d^2 * π
より
– A = 1/4 * 42.7^2 * π

57. 実際に使った計算
気候条件を決めてやる必要のあるデータは、
標準大気圧 (0.1013MPa) で 20℃ で仮定して決める。
– ρ = 1.205
– Kv = 1.512*10^(-5)
– Re = U * d / Kv
より、
– Re = U * d / (1.512*10^(-5))
※ 厳密にやりたいならここも可変が良いが、とりあ
えずは固定して考える。
※ 実際は、ゲーム内に天候条件があるので必要に
応じて変更。

58. 実際に使った計算
• Re が決まったので、 Cd の値が算出できる。
– ただし、この Re-Cd 関係は算出する式が存在しない（実験
データとの照合の必要がある）。
– 完全な球体として扱って良い場合は、適当に以下のような近
似式を使う。
Cd = 24/Re
* (1 + 0.152 * Re^(1/2) + 0.0151 * Re)
※ Re-Cd 関係はメーカー（というよりも各ゴル
フボールの規格）によって全然違う数値に
なる。
※ 特にメーカー等の指定がなければ、学術論
文やゴルフボールの特許資料などに乗って
いる実験値などから適当な値を抽出。
※ 実際には、収集したデータをもとに、上記の
近似式をあるゴルフボール用に改良（という
よりも操作）を加えたものを利用している。

59. 実際に使った計算
ここまで決めてやれば、計算に利用
するデータはすべて揃うので、初期
値として
– Velocity : 速度
– AngularVelocity : 角速度
– WindVelocity : 風速
を決めてやって、 U と N の値を決定し、
上記の計算式にはめ込んでやると、
ボールの弾道シミュレーションができる。

60. 実際に使った計算
• 最後の３つのパラメータは実測ベース
– 基本的にはネット上に出回っている標準
データを利用する。
– ただし、特定のクラブの特定の条件での打
撃などで抜け漏れが発生する。
• なので、実際に現場に行ってデータを計測する
。
※ ちなみに、ここで計測したデータはけ
っこう重要で、なかなか出回らない
ショット失敗時のデータも取得できる。

61. 実際に使った計算
• ゴルフ場のクラブ健康診断などを利用す
ると、このようなデータが取得できる。
← 社員が実際に打ったデータ

62. 実際に利用した計算
• ここまでのデータをもとにシミュレーシ
ョンを行う。
※ 実際のソースコードは公開できませんが、
ここまでのものをそのままコードに落とせ
ば同様の計算ができます。

63. 動いた ( ｀・ ω ・ ´)

64. なんかよくわからないけど・・
・

65. できるようになったこと
• ボールの回転による空気抵抗まで加味するの
で、より自然なかたちでボールが 飛ばせるよ
うになった
• 事前にどの程度の力を加えればどの程度ボー
ルが飛ぶのか判断できるようになった
– ただし、⊿ t(deltaTime : 微小時間 ) 毎に次々の
タイムステップを計算していくような、時間領域の
差分を利用する方法では、実際に計算を回さないと
結果はわからない
– なので、飛ばしたい距離分打つにはど
の程度の力を加えれば良いのか裏で
計算 をして力の設定をしています

66. 要は飛ばして爽快！

67. DemoTime

68. Before

69. After

70. 今回お話したのは
• キャリー ( 飛来 ) 中の弾道シミュレーシ
ョン
• 実際は以下のものも自前で起こしていま
す
– バウンド時の跳ね返り方向の判定
– ラン ( 転がり ) 中の挙動シミュレーション

71. 参考にしたデータ
• テニスの力学
– http://goo.gl/m9kym
• ゴルフボールの弾道シミュレーション方法
– http://goo.gl/e8Usx
• ゴルフボールのディンプル数に対する飛翔特性と流れ
– http://goo.gl/0zPDu
• AERODYNAMICS OF A GOLF BALL WITH GROOVES
– http://goo.gl/JQGU5
• 地球の雨・タイタンの雨
– http://goo.gl/ypiYw
• 土木工学ハンドブック
– http://goo.gl/HT4KT
• 転がりの科学
– http://goo.gl/PQtLv
いろいろ資料はあるけど、だいたいこれだけ読めばお k ！

72. 限界突破したかな。

73. では、次なる限界突破

74. データのフォーマット問題
• ロードできるデータが固定されている
– Resources.Load 、 AssetBundle で使
用可能なフォーマットが固定
• パラメータ設定とかに CSV とか使いたいよね…
• なので、独自のローダを開発！
– Resources.Load で読めない例外的なデータはこち
らからローディング

75. ローカルのセーブデータ
• Unity 内臓の PlayerPrefs クラスなんかだと
、直接データを覗けば簡単に構造が読めてし
まう
– XML や JSON も同様
• C# の BinaryFormatter でシリアライズす
るパターンも、直接抜き出してデコードした
ら一発で解析可能
– ファイルの冒頭に「 Assembly-CSharp 」という
記述があるため、すぐにデコード方法は推定可能
– そもそも、 BinaryFormatter は iOS で利用でき
ない
※ 余談として、データの保管には
EZ Saver といアセットがある

76. ローカルのセーブデータ
• 解決策
– セーブデータをハッシュ化したものを文字
列変換して保存する
• こんな感じ
– EXP:100;LEVEL:3;CURRENT_STAGE:5;
– 変換した文字列を公開鍵暗号を利用してさ
らに 16 進数の文字列郡に変換
• 鍵はサーバ側で定期的に更新して
おけば安全

77. データの動的更新
• 定期的なデータの更新のたびに申請を出
すのが手間
– こちらはむしろプラットフォーム側の問題
– 一部機能を WebView で実現する
• イベント
• 告知ページ
• ランキング

78. 限界突破したかな。。

79. ここからは個別のチューニングと
Unity の仕様の話

80. 速度チューニング
• Raycast 飛ばしすぎ
– Raycast は処理が重たい
– NGUI などの GUI ツールは Raycast でタップ判定をしてい
る
• ここはなるべくひとつのカメラにまとめる
• GUI/ 演出でカメラがいっぱいある
– 実は Unity は画面に描画をかけていなくても、場にカメラが
存在するだけで計算が入る
• 利用していないカメラは小まめに deactive に
• データのロードで固まっちゃう
– エフェクトのロードなど、一度にたくさんのデータや、重た
いデータのロードをかけると一瞬固まってしまう
• 確実に利用されるとわかっているデータは事前ロード
– シーンを開始した最初のフレームで読み込んでいる
– 若干、機動が遅くなるがあとの処理落ちは回避できる

81. GUI と日本語
• DrawCall 削減のために GUI は基本的に NGUI と
iTween
– 一部例外的なアニメーションは iTween を拡張して独自実装
• 日本語化
– Unity では日本語のダイナミックフォントがサポートされて
いない
• Bitmap Font Generator ないしは Glyph Designer を利用
する
– TTF 形式のフォントをビットマップ画像に変換し、テクスチャ化し
たものを文字データと関連付ける
• これだけだと、一枚のテクスチャにすべての
文字データが入っていけないという仕様上、
利用できない文字が発生してしまうので、ユ
ーザが「日本語で」自由入力する部分は Web
View の機能を利用する
※ Unity4 では日本語が標準サポートのようです。

82. GUI と日本語
• GUI の今後
– オートデスクの Scaleform が便利そう！
• Flash （ AS2/AS3 ）で作成したコンテンツを
利用するためのソリューション
• もともと Web アプリを作っていた会社のため、
Flash の知識のある人材がデザイナに多いので
、こちらに移行する（かも）
– 試しに別案件の Flash ゲームを Unity に移植したと
ころ簡単に動作できた！
– Unity のバイナリではなく、 SWF のデータ
で扱うため、シーンの編集中に他人の書い
た GUI を壊しちゃった、みたいなことも少な
くなりそう

83. DemoTime

84. 分析ツール
• ユーザの行動分析はどうするか
– Flurry を導入予定
• こちらは未だ実装に入れていないので、あくま
で「予定」として
※ 別の勉強会で話を伺った某社は Google
Analytics を利用しているとのことでした

85. 仕様でのバグバグ
• Application.LoadLevelAdditive() につい
て
– LoadLevelAdditiveAsync にしなかった際に
「シーンを読むまで呼び出し元の処理を止める」も
のと勘違い。
• 実際には「シーンのロードが終わるまで次のフレームに行
かない」
– ちなみに、 Application.LoadLevelAdditive() も
Application.LoadLevelAdditiveAsync() も、
内部的には Application.LoadLevelAsync()
を利用してシーンを読み込んでいる模様
基本的 にシーンを読む関数はすべて
最終的にこちらを参照するようになっ
ている

86. 限界突破したかな。。。

87. と、

88. ここまでが限界突破の話

89. ここまでやったところで

90. 持ち時間使い切っちゃいましたよ
ね
• グラフィック編は、次回以降要望ないし
はプレゼン枠の空きがあればやります。
– 綺麗グラフィックを追求するまでの道のり
…
• 同様に、 Unity にこだわらず「ス
ポーツゲーム（ほとんどゴルフに
特化するでしょうけど）の作り方」のテ
ーマでも、要望等あれば
やります。

91. まとめ
• Unity はプロトタイプ開発には便利
• だけど、本当に凝ったことをしようと思
うとひと手間加える必要がある場合があ
る
• 結局のところ、コンテンツを作りこんで
いく苦労は Unity でも変わらない
• ただし、難しいことは調べれば既にあっ
たりする（特にアルゴリズムと数式系）
– 意外と学術論文とか使えるんです！

92. 最後に
• 当プロジェクトは現在誠意製作中です！
– リリースをお楽しみに

93. 以上です。
ありがとうございました。