Event for Diverse Game Engineers

Event for Diverse Game Engineers プログラムを愛するエンジニアの為の勉強会

http://peatix.com/event/100971

思い描いているものを形にするための事前準備(挨拶と会場説明込み) by ろっさむ

C++, Python 土田さん 170人超え

行動する。 小さいことをまずする。 自分の環境を変化。 本物に触れること。

shared_ptrとゲームプログラミングでのメモリ管理

シェアドポインタ SlideShareあり。 今回は、メモリの動的管理！

メモリかりて、使い終わったらOSに返却。 近年10年くらいゲームで使うデータが増えてる。

大きく3つあるメモリの固定管理するひともいるが解決できる。 - メモリリーク - 処理速度 - メモリ断片化

メモリリーク

コミュニケーション不足や、ドキュメント見落とし、そもそも知らないで 起こりうる。 RAII(Resource Acuistision Is In~~~)の一部でshared_ptr new と deleteは使わない。 生ポインタは動的に確保するとこ以外は使わない。 メモリリークは全部解決できる？ str::mallocを使うこともある。（バイナリデータとかの時） メモリリーク検出ツールは簡単に作れる。 カスタムアロケータは必須 メモリリークはゲームを終了しないと開放されない メモリの生存時間 コールスタックは大体のプラットフォームでとれる、Windowsはドライバ系の関数で取れる。 backTraceHash・・ハッシュを持たすと。これをキーに vectorのノードのタイズが2つ以上ある、1より大きいとかで取れる。 Jenkinsとかで対応しておける。

処理速度

メモリが空いてるがメモリが確保できない・・・メモリの断片化

MMU・・・Memory Managment Unit これが無いマシンもある。 MMU非搭載・・低コストマシンの時

MMU搭載

物理メモリサイズに収まるように作る。フレームレートの維持。

low fragment heap Blackhat 2010のUnderstanding the low fragment heapのYouTubeが参考になる。

32bit Windowに2GBメモリ搭載。 厳しい。 → shared_ptrで動的管理で。 生存時間の長いメモリと性x存じ感の短いメモリのアドレスを離す！

生存時間の長いメモリを減らす→安定する。長時間駆動した時のバグが減らせる。

shared_ptrを削除すると芋づる式に減らせる。 weak_ptrにして依存を減らす。

シングルトン、グローバルインスタンスは極力使わない！ 　グローバル変数も

・デバッグモジュールの時 　仮想メモリに対してグローバルインスタンスを使う。

VRAMは断片化しやすい！ 直接アドレスは使えない。半分管理されている事が多い。ゲームには渡されていない。 間にメモリコンパクションを挟むのがいい。

処理速度

1バイト確保するごとにページ確保は辞める。 処理速度に見合ったゲームにする。 Win32のHeapAllocの場合Kernel-landに潜り込んでしまう。

コンストラクタでメモリ確保できなかったらどうするの？→ メモリ量は全部把握するべき。 メモリは不足しません。（メモリが不足しないようにゲームを作るのが基本）

デザイナーさんがデータ大きい場合 →データを修正してもらう。

Q and A

weak_ptrではなくshared_ptrが主流？ 気にしなくていい、RAIIが重要。

Unreal Engine 4とUnreal C++でのプログラミング環境について by alwei （アルウェイ）

関西。一昨年独立。 @aizen76

最近2Dでも強くなった。

kickstarter 五十嵐さん ドラキュラ　UnrealEngine4

ドラクエ11 PS4がUE4

こだわりがなければブループリントを使うことをおすすめ。 ほぼゲームできる。 個人ゲームではC++は1行も書いてない。 コードでできない表現もできる！

・なんでC+＋つかう？ パフォーマンスがもっとほしい。 エンジンやエディタを拡張したい 外部ライブラリやSDKを使いたい 独自のデバイスを繋ぎたい→Kinect（ほぼ標準になってる）や C+＋の勉強に

Unreal C++ is Awesome 独自拡張 C#やJavaやJavaScriptの特徴も取り込んでいる。 初心者向けのC++になっている。

UnrealBuild Tool ↓ Mono C# ↓　　　　　　　　↓ VisualStudio　Xcoce

最終的な情報をVisualStudioやXcodeに渡すことで実行できる。

makeで動く。Linuxでも動く。

比較的モダンC++

Range based forに対応。 コンテナの中に簡単にforを回すことができる。 値をコピーせずに値渡しできる。 ラムダ式もできる。 autoキーワードやenumなどのC++11で追加された機能も。

テンプレートメタプログラミングはしなくてもいい（できる） コーディングルール エンジンで標準で決まっている。 C#の標準に近い。 中括弧論争は醜い。カッコはつけよう。 スタンダードライブラリ使わない。std ゲームに特化している。（stlやboostも無理やり使えるけど使いにくい） ベースはC++になってる。 コンテナの数は50種類くらいある。 C++なのにGC搭載。 UObjectを継承したら勝手にGCへ登録される。 UObjectではないときはスマートポインタを使おう。 C++にはリフレクションはない。 Unreal Header Toolというものがありコンパイラ実行前にヘッダのメタ情報を解析る。 ホットリロード 完全なモジュールシステム 実行時に書き換えられる UnrealEngineがSurface3でさくさくうごく。

10/18(日) Unreal Fest 2015

Q and A ラムダ式使える →使える。delegate

コンパイルは遅いのはマシンの性能？ →マシン依存。VisualStudioに依存。

コンパイル速度 →EpiｃGamesが頑張ってるので我々はできない。 　分散ビルドも

コンパイルの種類変えられる？ →クランインテグレートした 　しかし、まだいろいろ問題がある。

コーディング規約チェックツールはまだ。

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

ちゃんばら キャバクラ 爆乳忍者

・最近のアケゲ開発 アケゲ基盤（Nu） Windows Embedded 8

stlは標準 Boost、Zlib etc.. 好きにアーケード開発

・WLW(Wonderlns Wars） フレームレート30fps CRIミドルウェアのADX2 グラフィックはアクロアーツ データドリブンでこなすには社内ツールで。

C++ ツール系はC# マッチング＆ゲームサーバはC++ DBはJava&SQL STLはコンテナ操作で多様 VS2012感j強により一部C++11 オブジェクト指向MVC設計

兵士オブジェクトがいっぱい出る 挙動は基本的に

C++便利機能 ラムダ式 　STLアルゴリズムと相性良い ・今までコールバック関数定義箇所と使用箇所が離れていたのが一箇所のにまとまってすっきり ・boost::bindだらけが少しマシに。 ・std::functionを使用して、式を関数から返すことも出来る。 ・ただ式がデカいと結局見づらくなるので程々に。

・C++便利機能 　型推論auto & decltype　 　方をコンパイラにまかせて記述がすっきり ・無駄なtypedefが駆逐できて便利 ・但しauto & &(参照の参照)には注意が必要。 　→　（訂正）reference collapsing の例として「&& に対して & が優先される」とのことです。

　書き方によってはReference Collapsingが動いたり動かなかったり。 　これを知らなくて少々ハマった記憶が・・・

・range-based for 　くらい返しよう関数いらない

・std::tuple 　構造体を定義するのはめんどい 　std::tuple使えばstd::pair要らない 　但しtupleの構造が変わった時、

・std::array 　イテレータを使えるし、範囲外アクセスチェックも楽 　なにげに全要素比較が楽。

・Scoped　Enumeration 通信動機 ・std::atomic

・std::future & std::promise 　ある処理の完了を街、その結果を取得といった非同期処理するのに便利。 　ただしこれが後々問題に

・static_assert 　コンパイル時エラーチェック。バグの芽を早めに積めるのでマジでおすすめ。

・使用してみたC++便利機能 final & override 修飾子 　ついていると継承時の関係がわかりやすく、継承ミスった時にエラーを吐いてくれる。 　なんでもvirtual修飾子しなくて済む。 Boost.Property_tree 　XML形式のパラメータ解析に利用。ツリー構造の汎用プロパティ管理で使いやすい。 Boost.Preprocecor 　便利なプリプロセッサマクロ群

高速化 　扱うオブジェクト数が大量になると、コンテナへのアクセスコストがボトルネックに。 　std::listはstd::vectorに置き換え。 　上限が決まっているものはreserveまたはstd::arrayを使用するように 　push***をemplace**に置き換え。 　そもそもアルゴリズムを見直す。コンテナへのアクセス範囲雨を限定したり、処理

　メモリリーク 　　std::thread, std::future, std::promiseを使うとメモリリークする。 　どうやらVS2012のバグ 　対応作：boostが提供している同種のモニ差し替え

CI（Jenkins）や静的解析

・アケゲ開発とコンシューマと違う部分 　- テストモード（ゲームセンターサイド向け操作モード）の実装 　- 筐体が場所をとる 　- （TRC的な）作成基準は各社独自 　　→風営法には抵触しないかどうか等も含め結構自己管理が求められる

1タイトルで数年単位の長期運営を前衛とした開発 複数のバージョン開発が並列で動く

KPI関連データの集計・分析はモバイルゲームのそれに近い エラー周りの例外処理が複雑になりがち（プレイヤーデータのバックアップ＆復元など） 　直接効果を投入して遊んでいただいていることもあり、この辺はセンシティブ 初回起動時に多少時間がかかってもあまり問題視されないのはアケゲならでは？

・ハードウェア／インフラ面ではアケゲ特有の感はあるものの、ソフトウェア面ではコンシューマ開発と総大差ない（悩みの種もだいたい同じ） ・アケゲ開発ではコンテンツそのものが提供する体験以上に現場体験を重要視（ライブで盛り上げる為のゲームデザイン） ・この辺を踏まえてゲーセンに行くと、ちょっと見え方が変えあるかも？

LTタイトル

JUCEで作るオーディオアプリケーション

@hotwatermorning C++ポケットリファレンス（共著） Microsoft C++受賞

JUCEライブラリ C++で書かれたクロスプラットフォームライブラリ Win,Mac、Linux、Android、iOS GPL

・オーディオプラグイン： 　DAW上で動作する楽曲やオーディオエフェクトのアプリケーション

Codex Digitalというのがある

コマーシャルライセンス nullptr, overide, noexcept, RAII 　スマートポインタなど・・

オーディオアプリケーションむけの雷雨ラリだが、その他にも多くの機能を提供している。

JUCEはゲームエンジンではない。 　ゲームに特化しているわけではない。 　特定のモジュールだけを開発に組み込むようなのは苦手

Introjucer・・・cmakeみたいなもの。

プログラマの生存戦略 ～生き残る為に出世しろ～

生存戦略、しましょうか？

描画・AI・モーション・VFX・・

・生きるために、出世しろ 　やるだけ無駄 　x 上司に気に入られる 　　→上司は変わる 　　→上司は居なくなる（転職が激しい） 　　→上司が部下になる 　x 社内で地位を築く 　　→部署がなくなる（タイトル終わったら解散、メインプログラマになったのに雑魚になる） 　　→突然会社が合併 　　→会社がなくなる

・世にでる、という事です。 ・世間にあなたの力量が

・自分の担当箇所を商品のウリにする 　まず、どんな仕事でも喜んで受け入れよ 　自分の過去の経験・知識をフル活用 　モノづくりは一方上、一歩広い視点で

・出世のための心得（その２） 　業界で「○○といえばxｘさん」という状態にする。 　最初は狭いのいでいい。 　ブルーオーシャン、ニッチを狙え。 　なければ新聞やを作ってしまえ。 　サウンドプログラマ 　→昔はなにそれ？今は新分野

・自分の広報担当者は自分だけ。 ・できない理由をあれこれ探すよりも ・ないなら作れ

世にでるとどうなるか ・会社が潰れようと関係ない。 主従が逆転する 会社に雇われている 　↓ 俺様が会社にいてやっていい 精神衛生上によろしい

能力のインフレを目の当たりにする

出会って刺激受けまくりの楽しい人生 　オラ、ワクワクしてきたぞ