UNITE Tokyo 2015 まとめ
先週のUNITEまとめ(適当)
整理終了
公式の公開資料 japan.unity3d.com
RealTimeGIはとても参考になった。 Unity5まだ触ってないけど。
驚いたのはUnityちゃんに本名があったこと。
基調講演
Republic(ゲーム)のプロジェクト本日より公開したので よければチェックしてね
Unity新機能
StateMachineBehaviour あるStaeに入った時に自分で記述した処理を実行できる サブステート的な使い方ができる
AoudioMixer 音量の調節などを簡単にできる SoundAが鳴っているときはSoundBの音量を下げるというようなことができる(ダキング) 複数のSoundの音量をいくつかあらかじめ設定しておきそれを動的に切り替えることがきる(SnapShot)
webGL対応したよ
IL2CPPで早くなったよ
Unity5.1でVRの機能追加するよ PLayerSettingでVRの設定をすると普通のシーン(VikingDemo)でもVRになるよ
VRコンテンツをやるんだったら今からやらないと間に合わない
CoudBuild ビルド時間の節約
- これまで15万時間節約どこでも絶えずビルド環境が使える 配信が楽やで
UnityAds iosのアプリTop10のうち4つがUnityAds 日本のサポートはGREEとCyberAgent CrossyRoadもこれを使用している
Unity on Windows
VisualStudio Tools for Unity
- aka.ms/vstudocj
- VS10から15まで対応
- インストール後にImportProjectでプロジェクトを取り込む
- UnityとVSはUDPで通信している
- たまに繋がらない・・・。
- 普通にBreakPoint・条件付きBreakPointが動く
- ビルドしたものでもデバッグ可
- ソース上で右クリ>ImplementMonoBehaviour
- 指定したバージョンのMonoBehaviourのoverrideしたい関数をUIから指定して自動生成できる
- ソース上で右クリ>QuickMonoBihaviour
- 検索できる
- Unityの関数をハイライトした状態でHeloを開くとそのヘルプが表示される
- VS community版でもOK
Kinect for win v2
- Unity Personal版でも使用可能になった
- Sampleに基本的なコードは大体乗っている
- ただWindows8以上が必要になる
他にもいろいろあった Slideが公開されるようなので参照
企画
- 最後まで完成させるための企画とゲームデザインとは
企画とは
- 企画 != 思いつき
- 企画 != アイディア
- 企画は出発点とゴール地点そしてその方向性
出発点
- いつどこで
- 誰が
- どんな体験で
- どんな感情を抱かせて
- どう面白がらせる？
ゴール
- ゲームのルック＆フィール
- プレイすることでぷりやーの心・生活・人生にどのような影響を与えるか？
方向性
- 大まかなゲームデザイン
- 1回のプレイ時間
- ボリュームなどなど
企画手法は時代とともに変わる 現在はターゲットもユーザも細分化されている 状況に合わせて企画の手法も違う
企画の本質的な話
- 企画を料理にたとえてみる
- 彼女ができました！料理でもてなそう！
- 勝利条件
- A：満腹にさせる
- B：料理の技術を見せつける
- C:料理を通して彼女を楽しませる←コレ
- 企画を料理にたとえてみる
- この勝利条件のためにプランニングする
- 実際のプランニング
- 大体3つ
- 相手の好きなものを出す
- 自分の嫌いなものの場合自分が好きになる努力が必要
- 自分の好きなものを相手にも好きになっておもらう
- 相手が好きとは限らない
- 未知のものを作る
- チャレンジ
- 相手の好きなものを出す
- 最悪：自分が好きなものは相手も好きに違いないという考え
- 大体3つ
- KWD：おもてなし
- 相手をイメージする
- 相手が何を求めているかリサーチが必要
- どんな時に心の距離を近づけるか
- 失敗例：同じものは飽きるよ
プレイヤーのどんな顔が見たいですか？
仕様
- ゲームデザインの問題
- 仕様とは
- XXXを実現するためにどのようなことを行えばよいか
- ゲームメカニクス
- ゲームを深くする要素
- 漠然と仕様を考えるのではなく分類してそれぞれを組み合わせる
- 新しい仕様を作る
- センス・挑戦した回数
- 似た仕様のものを作る
- 知識・まねた回数
- メカニクスの向上とは
- さらに自然に気持ちよく感じられる仕様
- 知識を増やす場合
- 著書を読めばいい
- 実装の問題
- プログラミング能力不足
- 頑張る
- メカニクスの知識不足
- 本を読むなりゲームで知るなり
- エンジンの理解不足
- !?
- プログラミング能力不足
- Unityの特性
- 頑張ればどんなゲームでも作れる
- 短時間で作りやすい
- 物理なし
- 単純なアニメーション
- 時間がかかる
- 複雑なアニメーション
- 判定や物理演算の結果が勝敗にかかわるもの
- 何故か
- PhysicsとMecanimの特性を知らない
あきらめないためには
- 企画をUnityに寄せる
- Unityを知り尽くして確実に実装して企画を実現させる
- 企画をUnityに寄せる
Animationが分岐するようなものはキツイ
- 格ゲー
- コンボのあるアクションとかとか
- CompleteProjectのテンプレートを参考にする
- 物理
- CompletePhysicsPlatformLit
- 2d
- NinjaSlasherX
- 最終手段は自分でPhysicsとかMecanimを実装
- テトリスとかならPhysicsもMecanimもいらない
- 調整
- ゲームの面白さは調整で決まる
- テストプレイヤーが重要なカギ
- 未来のプレイヤーを想像しよう
- 質問
- ゲームジャムとかで時間は文ができない
- 事前にある程度感気ておく
- 方向性を決めておきそれを押す!!
- ゲームジャムとかで時間は文ができない
使いこなしガイド
- 動画配信あり
- Lightingの機能について
- RealTimeGIの機能について
- AmbientLight
- SkyBox
- Gradient
- SolidCOlor
- の設定ができる
- LightingWindowの出し方
- Window > Lighting
- SkyBox
- Mayaと同じ漢字(ライトの角度で夕方とかになる)
- Gradient
- 空
- 赤道
- 地面
- Solid
- 単色指定
- SkyBoxの設定
- 影のオプション追加
- 投影される側はON/OFFしかなかった
- 追加
- TowSide：両面
- ShadowOnly：影のみ
- 追加
- 投影される側はON/OFFしかなかった
- リアルタイムのソフトシャドウの改善
- ジャギー改善
- パフォーマンス向上
- モバイルはまだ未対応
- ベイク
- 半かけの影において角度の設定ができる
- ShadowのBias
- Bias
- Volumeを移動する
- NormalBias
- Volumeを縮める
- 影に隙間ができた場合hNOｒまｌBiasの値が大きすぎる可能性がある
- Bias
- カスケードの設定・チェックができるようになった
RealTimeGI
- Unity5 の目玉
- 今までDirectionalLighting(直接光)
- これからIndirectionalLighting(間接光)
- LightingWindow 。 GeneralGI > Indirecting Intencity
- どのライトでもOK
- 実際の設定
- 固定物のGameObjectにはstaticにチェック
- 動き回るオブジェクトにはLightProveGroupを置く
- LightProveGroupから動くGameObjectに対して光の計算が行われる
- RealTImeGIは基本的にDiffuse要素に対しての処理になる
- Speculerが必要な場合はReflectionProveを設置する
- TypeをBakeからRealTimeにするといい
- ReflectionProveが設置されていない場合はSkyBoxのところの値がデフォルトで適用される
- 基本的にDiffのみなので法線マップとかが反映されない
- LightingWindow > DirectionalModeをDirectionalにすると反映される
- Specの法線マップを行いたい場合は
- LightingWindow > DirectionalModeをDirectionalSpeculer知ると反映される
- DirectionalModeを変更するとどんどん追加の情報がもらえる
- その分処理は重くなる
- 一つだけしたライトの位置情報を渡せない
- 複数ライトの時はSpecが出ないときがある
- その場合はSpec用のライトを追加する等(曖昧)
- 複数ライトの時はSpecが出ないときがある
- LightingWindowのBounciesで反射の反射の設定ができる
- ReflectionProveは基本的にStaticはオブジェクトのみ
- リアルタイムで反射を更新したいときにはRefreshを変更する
- リアルタイムの反射は処理の簡略化のためデフォルトではスタート時の反射画像をそのまま使用するような処理になっている
- リアルタイムで反射の反射を行っているときにSmoothを変更したりするとカクついたりする
- BoxProjectionとClassicCubeMapで反射の見た目を改善できる
- 四角い部屋の中の一つの壁一面が鏡というようなときにBoxProjectionと ClassicCubeMapで見た目が変わる
2D Animation
- 階層構造をでのAnimation
- なんか大体Maya的な考えでいけるっぽかったので割愛
ハッタリテク
- Assetのリジェクト回避テクニック
- 後一歩で李リジェクトされてしまうものを見るから
- ハッタリ != 手抜き
- 手抜き
- 品質を維持して手順を簡略化
- ハッタリ
- 未完成品にプラスしてなんやかんや
- 完成品と未完成品
- 自分ではできていても横から言われないと案外わからない
- なんか完成してるっぽく見える
- 超大事
- 板3枚で部屋の壁
- 完成品としては心もとない
- どうするか
- 床と壁の境にあるフチとか追加すればいい
- ライティング
- 逆光で影をがっつり入れるとイイ感じになる
- ハッタリには絵心不要
- 感性に頼れないなら機能に頼ればいい
- 手段が思いつかなければメニューバーを見ればいい
- 基本Cubeではなく・・・
- Roundかけてみるとか
- Specつくからいい感じになる
- Extrudeするとか
- 凹凸で影が増えるから情報量が増える
- Roundかけてみるとか
- わけのわからないものはわけのわからないものなりにそれっぽく見える
- モノがループしていると未完成感が増してしまうので注意
- 切った貼った押し出したとかで割とどうにでもなる
- ハッタリって何なの？
- 専門知識を知らないことを言い訳にしないこと
- 褒められたときにﾄﾞﾔｯってみる
- 公式丸暗記だったり
- パワポの資料みたいなテンプレだったり
- 専門知識を知らないことを言い訳にしないこと
- 用意された機能を使って自裁は未完成なんだけど完成っぽく見せる!!
- カラコレがハッタリ的には便利
プロジェクトの始め方・育て方・終わらせ方
- 開発の生産性とは
- 確実に進捗する
- バグのリスクが低い
- データの追加などが容易
- テストプレイが容易
- GameDevHerosというゲーム作った
- ゲーム開発シミュレーション
- 設定
- 2030年には暴力でPCを動かす
- 舞台に準拠したアニメーション(蹴りでPCを動かす)
- 2030年には暴力でPCを動かす
- Unityちゃんを使う理由
- Unityは・・・
- 分担が容易
- 機能追加が容易
- Unityの罠
- 何をやっているかわかりにくい
- 可視化されない
- 全体の状態管理ができない
- バグりやすいしデバッグしにくい
- ゲームデザイナーの生産性
- 新しい仕様をすぐに試せること
- プログラマの生産性
- バグが出ないこと
- デザイナー
- タスクとキャラの開発
- プログラマ
- GUIとアプリケーションシステム
- 通しプレイができる意味
- 開発の終わりが見えてくる
- 面白さ
- 面白そうに見える
- 1レベルをプレイしていて面白い
- 雰囲気づくり
- ゲーム開発シミュである説得感が足りない
- キャラクターへの思い入れrができない
- タスクを作れるようにした
- リーダー的存在追加
- レベルアップシーン追加
- キャラクターへの思い入れrができない
- 開発を支える技術
- USequencerというAssetが便利
- Qumarion便利
- とにかく通しプレイをする
- 常にエディタでテストプレイ
- エディタと外部ファイルの同期
- プログラマとデザイナーで生産性についての認識を合わせる
- 一人ができることを増やす
UIについて
- uGuiのソースはBitBucketからダウンロードできる
- Built-inShaderも公開されている
- TextやImageのAPIからできることは限られている
- BaseVertexEffect
- ShadowとかOutlineの基底
- ModifyVerticesをOverrideする
- 引数に頂点情報が来るのでそれに対して処理
- Outline.cs
- そのまま使うと問題がある
- PositionAsUV１.cs
- 複数のTextureを使用できるようにする
- Textなどで画像を抜くなど
- BaseVertexEffectの利点は汎用性が高い
- カスタムフォント
- BitmapFontImporter｡cs
- 無料
- ShoeBox：フォトショデータを使う
- BMFont
- 有料
- GlyphFont
- Shader
- カスタムシェーダ
- Cg/HLSL
- Surface
- BitmapAndFragment
- Fix
- 書き方
- Built-inShaderをダウンロードして書き換えるのがイイと思う
- プロパティが複雑になったらタブにすることもできる
- 同じように書かれたShaderでも表示領域の差で結果が変わってしまうことがある
- Unityはシステム上東名部分の余白は自動で削られる
- BillBoardはVertexShaderでもいいかも
- UnityUIにはNGUIでいうTweenがない
- LeanTweenが対応している
- uGuiについてはUnityゲームUI実践ガイドを読むとイイよ
- LayoutElementというのが重要(らしい)
- 基本機能ではあるが難しい
Unityのシーンの紐解き
- プロジェクトをさくっと読みたい
- でも難しい
- バグレポートの構造解析
- サンプルシーンの解析
- コードかっくの面倒
- 昔書いたプロジェクトが読めない
- シーンのMETADATAをごにょごにょする
- ルール確認
- プロジェクト
- シーン
- オブジェクト
- シーン
- プロジェクト
- オブジェクトのルール
- 参照の構築
- GetComponent・AddComponentでごにょごにょ
- オブジェクト生成のルール
- オブジェ宇都を生成する
- 元を取得する
- ルールをもとに情報を主おtくする
- 飛び出しの把握
- コンポーネントからの列挙
- コンポーネント参照先の確認
- コンポーネント参照元の確認
- 無理
- 参照状況をもとに被参照リストを作る
- 無理
- 参照先の座標確認
- Objだけではなく矢印でオブジェクト同士を線でつ上げるとわかりやすい
- 量が多すぎると混乱するのでストリップの仕組みは必要
- 参照リストからの削除
- コンポーネントの依存関係
- コードベースの参照関係
- コンポーネント内のコード検索
- MonoScript
- オブジェクトからソースを取得できる
- MonoScript
- グラフ化
- オブジェクトの参照関係も同じようにグラフ化できる
- 実際の開発はコンポーネントではないクラスがある場合それで管理している可能性が高い
- コンポーネントで多いのがMng系
- 大体Singleton
- コンポーネント的な参照が多い場合
- 外部からのMessageで動くことが多い
- 大体Singleton
- ギミック系オブジェクト
- Colliderで自己完結
- 他のオブジェクトに対する参照はあまりない
- Colliderで自己完結
- Updateで頑張るタイプ
- この場合は参照を多く集めている
- UpdateやCoroutineで自発的に動く
- どうやって参照されているか
- なぜそれを参照するのか
- 見られているオブジェクトのもついパラメータに注目する
- 起動後と起動前で参照関係は変わってしまう
- 参照関係を把握する
- 自分で動くか管理されるかの2択
- 被参照が1つの場合：管理されている
- 被参照が1つでない場合：自分で動く
- (↑曖昧)
- 検索パターン
- UniqueTag
- 親子関係
- 名前
- Mng：Singletonの登録方法
- Component→Mng
- Mng→Component
- なぜ参照を持つ必要があるのか
- Objをどこから持ってきたのか
- 生成コードの検索
- 最初から配置されているか
- シーンにオブジェクトを生成しているコードを検索
- 生成コードの検索
- GithubのUnite2014のReferenceViewerが便利
- シーンをYAMLに変換してGrep検索
GUI
- UnityGUI
- UIのベストプラクティス
- どうすればパフォーマンスの高いUIができるか
- バッチングの概念
- 独自カスタムの最適な方法
- バッチング技術とは
- 同一状態の描画をひとまとめにする
- Unityにおいては特定の状態にならないと描画されない
- 違う状態にならないと描画されない
- Material・TextureごとにDraw
- Materialが違うオブジェクトは遅くなる
- Materialが同じ・Textureが違うときはまだまし
- Slow
- SetPassCall
- GameViewのScatics
- SetPassCallは小さいほうが好ましい
- UIシステムのバッチング
- ON：OFFになたとき
- どうやってバッチングするの？
- FrameDebugger
- 南緯がバッチとしてまとまっているかがわかる
- Window > FrameDebugger
- Canvas単位でバッチングされる
- Canvasネストの場合は独自
- 同じMaterialTextureを共有する必要がある
- ColorはVertexShaderでかわっているためバッチングは可能
- 切れるタイミング
- マテリアルがテクスチャを変更するタイミング
- 内部のRenderingShaderを変更しなければならないため
- Elementが重複している場合
- Elementが重複しているときは切れる可能性がある
- バッチングのSorting
- UI内部
- Configに基づいている
- UIRえんでｒの指定で入力があった場合それをバッチとして正しい状態にしようとする
- FrameDebugger
- キャンパスと同一になっている
- レンダリングするときに再配置
- 5.2からドローコールが増える可能性がある
- まとめ
- UnityMaterial変更時に壊れる
- Texture変更時に壊れる
- 同一平面上にない場合はソートし直す
- もしかするとパスが増えるかもしれない
- 5.2からTextのMaterialが早くなる
- 現在は動的に生成されているためにコールが増えている
- エフェクト以外は同一平面上にする
- エフェクトの場合でもネストする
- SpriteAtrasのPackerで1つのTextureにまとめる
- CanvasRender > Rebatching
- UIのコンポーネントですべてのグラフィックが持っている
- Text・Imageなど
- 追加するとCanvasRenderも追加される
- 追加されるとバッチし直し(再計算)になる
- 再計算になるとき
- 階層の順番が変わった時
- 描画準が変わる時
- その一部としてRebatch
- 異なるWindow があり、後ろのWindowを前面にするときなど
- PixelPerfectはできるだけ控える
- ScreenSpaceCanvasにおいてのみ機能させたほうがよい
- スナップしていく→遅くなる
- 動きのないものはPixelPerfectを有効にしてもOK
- お互い動いている時だけOFFとか
- CustomUIComponent
- 自作できる
- 自身のGraphics
- 自身のレイアウトを作成
- レイヤーのロジックを作成できる
- UIElement
- CanbasElement
- ICanvasElementを継承
- Rebuildを実装する
VR
- RichoTheta
- 全天球カメラのリアルタイム合成
- りーぷモーション使って回転とかができる
- リアルタイムレンダラー
- Unityベース
- 西友の表情キャプチャとかやった
- Oculusの情報から音楽生成
- 本題
- ゲームのテクノロジーを使うと結構いろんなことができるよ
- ヴィジュアライゼーション
- 3Dで見るということ
- 3Dのほうが様々な情報が入ってきてよいのではないのか
- 外科手術ロボ
- Davinch
- VRチック(Oculus的)な感じに見える
- 奥行感があるので結構操作ができてしまう
- 奥行感の袋瀬さを実感
- Davinch
- 3Dでデータを見よう
- CTスキャン
- DICOMフォーマット
- シーケンス
- OSIRIX(オザイリックス)
- DICOMフォーマットから骨・筋肉のVolumeレンダリングとかできる
- OSIRIXからUnityへデータを持っていける
- 後はUnityでVR化できる
- マルチレイヤー化
- 皮膚
- 頭蓋骨
- 脳
- オキュラスで見ると2Dとはやはり違って見えてい良い
- CTのデータをVRでアニメーション
- 世界初
- 創薬：薬づくり(タンパク質の構造とかを調べたりする)
- タンパク質のくぼみに嵌まる薬を探すこと
- にも応用できるんじゃね？
- ちなみにタミフルはインフルのノイラミダーゼという部分に嵌まる
- タンパク質のデータは公開されている
- タミフルの化学式とかもある
- PBDはBlenderで開ける
- ComputerAidedDrugDesign
- コンピュータを使って薬を作ろう
- これからはVRAidedDrugDesign
- VRで薬作っていけるんじゃね？
- DICOMは・・・
- OSIRIX→Blender→UnityでOK
- PDBは・・・
- Blender→UnityでOK
- 逆にゲーム以外のデータをゲームに持ち込むことも可能
- ゲームフィケーション的に薬を作ったりもできそうだ
音を制する
- CRIの宣伝っぽい
- ゲームサンドに求められるもの
- サイズを小さく
- 音質が良い状態でなるべく小さく
- 再生のCPU負荷
- をペアで考える必要になる
- サイズを小さく
- メモリ使用量を小さく
- Streamingだと小さくなる
- 気持ちのいいサウンド
- 警告音など
- キャラ・世界観の表現
- ボイス・環境音とか
- ADXの機能(便利)
- 音をUnity ではなくプログラムで設定などを行ったファイルをUnityで使用する
- 極端に容量がhったりはしない
- プログラムで特に何もしなくともイントロつきループサンドが可能
- 波形に何か仕込んである
- 乖離性ミリオンアーサー
- セリフ再生時はBGMとSEを下げるとかもできる
- コレUnity5 だとAudioMixerで普通にできるんじゃね？
- 音量が下がっているかがわかるかわからないかぐらいが良い
- 極端すぎるとダメ
- 音源はストーリーごとにダウンロードするように実装した
- チュートリアル中にゲーム本体のデータをダウンロードする
- セリフ再生時はBGMとSEを下げるとかもできる
- 7つの大罪
- ボイスはストリーミング
- タイミングを合わせるのが若干面倒
- バトルのSEは同じ音がたくさん鳴るとなんかアレなのでランダムでピッチを変更するようにする
- これもチュートリアル中に本編ダウンロード
- ボイスはストリーミング
- ファントムオブキル
- なんかドカポンっぽい
- フィールドとバトルBGMの切り替え
- 音楽を切り替えるのではなく通常フィールド曲と戦闘曲を同期してストリーム再生し それぞれの音量バランスを切り替えている
- 発音数の制御
- イベントデータなどの追加BGMはパックではなく単体を追加する
- 音ゲー作成
- Androidの音声遅延時間を推測して計算する
- CRI尾人向け(無料あり)
- 音声の遅延推測は入っていない
スマホ向けアプリの開発アプローチ
- 会社
- SummerTimeStudio
- 沖縄
- 開発スタイルと特徴
- スマホ・タブレット特化
- Android・IOSのマルチプラットフォーム対応
- コンシューマ向けの3D技術を使用
- コミュニケーション駆動開発
- いつでもどこでも話して解決(共有)
- いつでも話せる空気管
- 全員がフラットな立場で話し合う
- ひとりひとりが主体性を持ったモノづくり
- メンバー全員で考えてクオリティアップを目指す
- いつでもどこでも話して解決(共有)
- 少数精鋭
- 各プロジェクト
- PG1名
- 2Dデザイナー1名
- 3Dデザイナー1名
- プロジェクトの規模やフェーズに応じて絨毯に対応
- 成果のフィードバック
- デバッグは全員で
- 各プロジェクト
- 最小限のルール
- スマホ市場の成長は早い
- 時代の流れに合わせてその時の最良を要求
- 開発環境構築
- 必要だと感じたこと
- スマホ・タブレットの効率化
- Unityの中で起きている問題は対応不可
- 実際は特に問題はなかった
- Unityの中で起きている問題は対応不可
- マルチプラットフォームの差異を吸収
- スマホ・タブレットの効率化
- STFrameworkとは
- 初期化
- STFramework.Initializeを呼び出すだけ
- 配置しておくのはUI用カメラだけ
- これがないとエディタ上でレイアウトの確認ができない
- とにかく簡単に使えるようにしたかった
- Input.GetTouchがエディタ上で動作しない
- エディタ上でも気軽に動作確認をしたかった
- マウス入力をタップと同じフォーマットにして返すだけ
- UnityRemoteは不安定
- エディタ上でも気軽に動作確認をしたかった
- SceneMng
- 大量のInstantiateは時間がかかる
- スマホで動かすとクソ重い
- ゲーム審のScene遷移や管理を自動化
- 初期化・破棄処理をコルーチンで実装
- シーンの遷移状態でのコールバック処理
- オブジェクトの初期化順も簡単に制御
- UIMng：UIComps
- 課金Interface
- XMLImporter
- その他
- 初期化
- UI系はUGUIで大丈夫そう
長い。疲れた。
