• Home
• About
• Contact
• Archive

今日は「Event for Diverse Game Engineers」の日です

Event for Diverse Game Engineers に参加しています。 有料イベントですが全トークソーシャルO.K.のようなので、自分用のメモを残しておきます。 ハッシュタグは #TokyoEDGE2015 です。

@4_mio_11 さん 「思い描いてるものを形にするための事前準備」

• 注意事項など
• スクエニ本社に行きたい、大きい勉強会、そこで話したい
• 東京旅行のついでに @tsuchidasama さんにあって勉強会開こうと思った
• 80人くらいかと思ったら170人超え
• 「行動あるのみ」
• @tsuchidasama さんにFBで申請した
• 自分の環境を変化させてみよう
• 本物のゲーム開発者に触れるといいでしょう

@DADA246 さん 「shared_ptrとゲームプログラミングでのメモリ管理」

• 眠くなる話で眠らせていく予定
• OSは動いていること前提。C++ネイティブ。アクションゲームなどリアルタイム性。中規模～(50人以上)
• ゲームプログラム
  • FPSが安定
  • (メモリの観点で)スワップアウトが発生しない
  • 実行時のメモリが物理メモリサイズに収まる
• メモリ固定管理: ゲーム中はOSからメモリをもらわない
  • 動的管理: 必要になったらメモリを返却する
  • 今回は後者
• 近年データ量が増えている。データドリブンである必要
• メモリを動的管理にすることで制限が減る
• 多彩なデータを扱えると、デザイナやアーティストが思いついたアイデアを試行錯誤できる
• 「一時的にメモリを使用するデータ」のtry and errorが可能に！
• ゲームシーケンス: シーンによってメモリの利用方法が変わる
• 動的管理の問題
  • リーク、断片化、処理速度
  • これらを嫌って固定管理するプログラマも多い
• std::free、deleteを忘れるとリークする
  • メモリの開放を他のプログラマに委ねる場合に起きる Register と UnRegister など
• RAII (Resource Acquisition Is Initialization)
  • オブジェクトとリソースの生存時間をそろえる
  • 実装例: shared_ptr
• new と delete を使わない
  • モジュールごとに shared_ptr で分離される
  • 生ポインタは動作速度が必要なときのみ
• コンストラクタで初期化できるようにする
  • C++ の閉じかっこの強さを利用する
• std::mallocを使う必要がある場合 => バイナリデータ読み込み
  • std::freeの書き忘れが起きる
  • リーク検出ツールで検出 → 簡単に作れるよ！
• 今時のOSはアロケータを差し替えられる
  • 例: win の _cdecl operator new
  • ここでデバグ情報を保存する
• リークしているアドレスは生存期間が長い
  • アドレスに日付を付ける
  • 常駐データなど、解放しないものもある
  • コールスタックも保存。1回のみのモノは常駐データ
  • winの場合はRtlCaptureStackBackTrace
• 「同一のコールスタックから生存時間の長いメモリを複数回確保」をメモリリークとして検出
  • ログの分析はC#など使っている(C++ではちょっと)
  • jenkinsにまとめるといいでしょう
• 断片化: 連続したメモリが確保できない状態
  • メモリは空いてるのに確保に失敗
  • MMU(memory management unit)の有無で変わる(ふつうのPCならあるけど、ないマシンも多い)
  • ハードウェア構成によって断片化のしやすさ代わる
    • ハードによって戦略が変わる
• MMU非搭載
  • 物理アドレス空間の断片化に要注意
  • 物理メモリ16MBなどの組込。固定管理の方が適してる
• MMU搭載 (幸せなプログラミングができる。運がいい)
  • 仮想メモリ空間の大きさを当てにして、何もしない
  • ゲームは、物理メモリ量に収まるサイズのアプリになるはずなので
  • 64bit Win8.1 : 128TB。ページ単位のブロックアロケータ。断片化気にしない
    • トラブったら設計がまずいはず
    • Blackhat 2010 Understanding the Low Fragmentaton Heap
• MMU搭載で仮想アドレスと実メモリに差が少ない場合
  • 例: 32bit Windows XP で 2GByteのゲーム
  • 断片化にかなり注意が必要
  • 生存時間の長いメモリを減らす
  • 生存時間の違うメモリのアドレスを、離す
• 生存時間の長いメモリを減らすには
  • 相互参照を減らして、速やかに開放できるようにする
  • 長時間駆動に耐えやすい
  • 依存関係が増えやすいときは weak_ptr
  • シーケンス切り替え時にモジュールを捨てる。状態データのみ抽出して引き継ぐ
  • シーケンスデータ移行モジュールを作ることも
• シングルトン、グローバルインスタンスは極力使わない
  • グローバルインスタンスを先頭にとる。断片化が起きない
• 生存時間の違うアドレスを分ける
  • アロケータを複数 or Double Ended Stack allocator (上からか下からか選べるアロケータ)
• VRAM : 断片化する
  • メインメモリよりは気楽にとらえることも
  • アドレスをプログラム側に渡してない
    • いざとなったらメモリコンパクションを実装
    • メインメモリでは厳しいよね
• 動的確保に見合った処理速度にするしかない
  • 教科書通りの高速化は実施 (User-landで実施するアロケータ作るとか)
  • User-landとKernel-landの切り替えは時間がかかる
• 生産性とのバランスの問題
  • 速度か開発の柔軟性
  • 処理の高速性が求められるところのみ頑張ればO.K.では
• リークツールは3日か4日あれば組める程度でしょう
• メモリが不足したらどうする？
  • 不足しないようにゲームを作る
  • 自動テスト・エージングでメモリ使用量を必ず把握する
  • 断片化・リークを直してもダメなら、データ側を修正しなければならない
  • 開発用ROMではたくさんメモリ使えるからデザイナさんが頑張っちゃったりするけど
• 動的管理によるいいこと
  • 多彩なデータを動作させることが可能に
  • デザイナ、アーティストのクリエイティブてぃを引き出す！ 面白いゲームを！
• Q. ユニークポインタを使わずに shared_ptr がメイン？
  • A. new, delete は使わずにスマートポインタを使おう

@aizen76 さん 「UE4とUnreal C++でのプログラミング環境について」

• Unreal Engine 4
  • 2015年 無料化が発表された
  • 3Dでも2Dでも
  • ドラクエ11のPS4版
  • デスノートのリュークのCGも
  • アニメ会社とかでも注目度が高い
  • ブループリント(ビジュアルなスクリプトシステム)を使うのがオススメ
  • 「ボクが作るならはC++のコード一行もかきません」
• C++を使う理由
  • パフォーマンスの追及(速さは十分だけど、数十～数百倍の差が出ることも)
  • エンジン・エディタを拡張したい (ほとんどの部分が公開されていて拡張可能)
    • pull-reqしたりできるよ
  • 外部ライブラリやSDKの使用 (OpenCVとか)
  • 独自デバイスの利用 (KINECTとか)
  • C++の勉強！
• “Unreal C++ is Awesome!” 自画自賛
  • 初心者向けC++。独自拡張。Unreal Editorとの親和性
  • C#やJSの特徴も
• Unreal BuildTool → Mono C# → VisualStudio OR Xcode
• UnrealBuild Tool
  • C++のメタ情報
• Mono C#
  • クロスプラットフォームを意識したモジュールの管理・リンク
• Windows, Macで動く。Linuxでも実は動く
• 比較的モダンC++
  • Range based forに対応
  • ムーブセマンティクス (右辺値参照)
  • コンテナのアルゴリズムにラムダ式
  • auto, enum
  • ただし、対応してないコンパイラがある機能には慎重 (マルチプラットフォームなので)
  • テンプレートとか難解な部分はなるべく使わない
• コーディングルールが決まっている
  • C#の標準にかなり近い
  • C++の標準よりこちらを
  • 「中かっこ論争は醜い」
  • 誰が書いたかわからないくらい普通のルール
• STLは使わない。ゲーム用に特化したいいライブラリがあるので
  • boostとか無理やり使うと苦しくなる
• C++標準より圧倒的にコンテナ多い。50種類くらいある
  • TArray, TSet, TMap (std::unordered_* とか書かなくていい)
  • FString (std::stringベースだがほぼ別物), FText (言語切り替えに対応), FName (静的文字列。速い。アセットの名前などに)
    • ネットワーク周りのエンディアンとかにも対応
  • C#ライクなデリゲート。ダイナミックデリゲート(特殊。シリアライズ可能)
• Unreal Editorが自動でコード生成
  • .cppと.hも個別に作らない
  • wizardみたいな感じで
• GCあり。UnrealObject (UObject) を継承していれば
  • GC最適化可能 (呼び出し感覚、強制GC、並列化、オブジェクトプールなど)
  • メモリの可視化
• UObjectじゃないものはスマートポインタ
  • TSharedPtr, TSharedRef, TWeakPtr
  • ゲームで使用する前提の設計
  • スレッドセーフじゃなく、標準スマートポインタより早い
  • TThreadSafeSharedPtr (ロックフリーアルゴリズム)
  • コピー時にメモリ割り当てしない
  • 例外使わない
• C++にメタ情報はない
  • RTTI(実行時型情報)はある
  • Unreal Header Tool にて実現
    • UCLASS, UPROPERTY, UFUNCTION, USTRICT のようなアノテーション
    • reflectionだけでなく、様々な情報を追加可能
    • ブループリントとの連携に利用 (BlueprintReadWrite, BlueprintCallable)
• ホットリロード
  • ゲーム実行中にC++コードを書き換えることができる
  • 部分的にDLLをリロードできる (Mono C# がやってる)
• ホットリロードのデモ
  • C++コード(Actor)を追加
  • ヘッダを書き換えるとビルドが遅くなるので、try and error はヘッダを書き換えない方が
  • ゲーム実行中にマネキンを設置、C++コードを書く、ビルドすると回転を始める
  • さらにC++を書いてビルド → 失敗。エラー箇所にジャンプできる
  • さらにC++を書いてビルド → 失敗。ライブデバグ
  • 「何度も成功してたのですが、やはり生は怖いですね」
  • プロパティはblue print 上から見えるようになる
  • 「ログのLがlに！」 → コンソールにライフの表示を成功
  • コンソールへクラス名を吐く (リフレクションの例)
  • 再起動。Visual Studioとの接続を切断
  • Unreal Engineでソースコードをエディットする (VCのインストールはいるけど、立ち上げなくていい)
    • VCは重いから。ただしエディタはしょぼい
  • blue printからVCで該当行にジャンプとか
• Unreal C++ は素晴らしい。ただし、ブループリントで十分にゲームを作れる
• Unreal Fest 2015 横浜というイベントがあるよ (1000人まで)
• UE4 GameJamというイベントを関西でやるよ (20人まで)
• Q. コーディング規約をサポートするツールはあるの？
  • A. ツールはなさそう。レビューで直しているようだ。ルールで書けないところもあるので難しい
• Q. Unreal C++でラムダ式は使える？
  • A. はい。VC++で使える機能なら
• Q. コンパイル速度はマシン性能による？
  • A. VCのコンパイラ速度に依存。モジュール単位でビルドしてるので普通より速いはず
  • Q. 今のはでもマシンの性能のせい？
  • A. はい。普通は5秒。ハイスペックマシンを使って
• Q. コンパイル速度を速くするツールとかノウハウを
  • A. すでにやられている。我々ができることはほとんどない
  • Q. 分散ビルドは？
  • A. 公式にサポートされてるので、使っても
• Q. C++14への対応は？
  • A. 少しずつ増えている。VC++やXCodeが対応されていれば
• Q. コンパイラの選択はできる？ clangとか
  • A. 去年の12月に出てきている。問題はまだある。そのうちはいるはず

@shw95349 さん 「元コンシューマ系PGがアケゲ開発やってみた　～アケゲ開発でのC++～」

• 男の煩悩担当みたいなコンシュマーゲーム開発
  • 4vs4オンライン協力対戦アーケードゲーム
• PS3, XBOX360, Wii, Vita, 3DSの時代のコンシュマー
• プラットフォーム複数なのでコンパイラも複数
  • C++ベースでビルドが通るように。方言は禁止
  • STL, Boostの使用制限 → レガシーなコーディング
• 最近のアーケードゲーム開発
  • PCゲームの開発のようなもの
  • 筐体の中にPCが入ってる、ようなもの
  • OS: Win, CPU: Intel Core i3, GPU: NVIDIA GeForce
  • コンパイラを選べる。外部ライブラリやミドルウェアの使用。ハードウェアの自由な設計
• アーケード、コンシューマーとモバイルの比較
  • 言語は変わらない
  • アーケードの場合、店舗(オペレータ)もお客様
  • アーケードの場合、デバイスが自由度
  • アーケードは風営法など、地域の法律への考慮が必要
• 作ったゲーム
  • 30fps, 1280x1080をアップスケーリングして1080p
  • グラフィックはオーソドックス
  • エフェクトの社内制ツールやADX2(サウンド)
  • ネットワーク周りは大変。ゲームデータ管理からパッチ、Wifi周りまで
  • C++がメイン。ツールはC#。DBサーバはJava
  • STLを多用。VS2012のためC++11機能が一部使える
  • 足りない部分は Boost
  • 典型的なOOP、MVC。(
  • クラス図は複雑: 出力しようと思ったら1日かかっても出力できなかった)
• C++11の嬉しい機能
  • ラムダ式 : STLと相性が多い。コールバック定義場所が近くに。boost::bindの緩和。式がでかいと見にくい
  • 型推論 auto と decltype
    • 無駄なtypedefの駆逐。その場でしか書かないやつとか
    • auto&& Reference Collapsing の挙動を知らないとハマる
  • range-based for
  • std::tuple 構造体定義を少なく
    • ただしtupleの構造を変えるとstd::get, std::tieの調整が大変
  • std::array : 全要素比較が楽だったり
  • Scoped Enumeration : 名前衝突の危険性を低減。ラッパーなどあった方が
  • std::atomic : 通信同期に使ったり
  • std::future, std::promise : 非同期処理に (問題になったけど)
  • static_assert : バグの芽を摘む
  • final, override : コンパイル時にエラー見つける
  • Boost.Property_tree : XML便利
  • Boost.Preprocessor : 便利マクロ群
• C++は進化してもバグは尽きない
  • オブジェクト・エフェクトを大量に出すとクラッシュ → プールしてメモリを節約
  • オブジェクト大量にあるときのコンテナへのアクセスコスト
    • std::list を std::vectorへ
    • 固定長のモノは reserve や std::array へ切り替え
    • push_*** を emplace_***
    • アルゴリズムを見直し
  • std::thread, std::future, std::promiseのリーク
    • VS2012のバグだったのでBoostへ
• CI(Jenkins)、Coverity などで問題を炙り出す → 割と平和にリリース
• アーケードゲームで違ったこと
  • テストモード
  • 筐体が場所を取る。キーチップなど
  • 作成基準が会社独自
  • KPIの分析はモバゲーに近い
  • データのバックアップ・復元処理
  • アーケードは初回起動に時間かかっても問題ない
  • ソフトウェア面ではコンシューマ開発と変わらない
  • コンテンツそのもの以外に現場体験重視
• ゲーセン来てね！

@hotwatermorning さん 「JUCEで作るオーディオアプリケーション」

• bitbucket にサンプルコード上がってるよ
• JUCEライブラリ
  • Traktionの内部用で開発
  • 商用ライセンスあり（12万円）
• DAW : オーディオ政策に使う統合制作環境
  • オーディオプラグイン。音をゆがませたりするやつ
  • デモ: 音楽を流しながら続行ｗ
  • 色んなオーディオアプリケーション開発企業で利用されている
• モダンなC++で書かれている
• オーディオ、GUI関連、Network、暗号化、スレッド
• exampleのJuceDemoを見るといいよ
• オーディオプラグインの規格
  • VST, Audio Unit, AAX, RTAS
• ゲームエンジンではない
• 信号処理に特化してない。最低限
• 特定のモジュールだけを使うのは難しい。がっつり使う
• JUCEはIntrojucerを利用して開発
  • CMake的なもの。マルチプラットフォーム
  • 簡易なコード生成機能も
  • 日本語には対応してない
• テンプレはあるので書きたいとこから書ける

@tsuchidasama さん 「プログラマの生存戦略 ～生き残る為に出世しろ～」

• 21歳で独立してバブル崩壊して死んだり
• 講演してる: CEDEC, GDC, 学会・大学
• 専門学校では「いいから量をやれ」遊びまくってるから
• 大学では「専門武器を持て」企業が見たい
• ゲーム業界の人には「生き残るために出世しろ」
• 出世とは？
  • 上司に気に入られる → 上司が変わる。消える。上司が部下に。無駄
  • 社内の役職 → 部署がなくなる。会社が合併。会社がなくなる。無駄
• 生き残るための出世とは？
  • 世に出る
  • 世間に力を認知してもらう
• 心得1. 自分の担当個所を商品の売りに
  • どんな仕事でもやる
  • 今までの経験を生かす
• 心得2. OOと言えばXXさん
  • ニッチを狙う
  • 新分野を作る
• 心得3. 対外活動に出る
  • 自分の広報担当者は自分
  • 場所がなければ自分で作る
• 世に出ると
  • 会社がつぶれても関係ない
  • 主従の逆転 「俺様が会社に居てやってる」
  • 精神衛生にいい : 給料が下がってもどうせすぐやめれるし、みたいな
  • 能力のインフレを目の当たりにする → 会社の中に居てはわからない
    • 社内政治とかどうでもよくなる
• オチ「勤続20年にして未だ平社員」