CEDEC 一日目 ８月３１日メモ
とりあえず、CEDECのおさらい。人に見せる様なもんじゃないけど、メモを先にうp。意味不明だろうけど。そんでもって、これを自分で読みながら適宜整えて行きます。多分しない。
CEDEC挨拶 和田 洋一 社団法人コンピュータエンターテインメント協会（CESA） 会長
おおっ、意外としっかりとわかりやすく話している。どこぞのアカデミックとは大違い。自分が日頃心がけてることが、CEDECの開催意義と直結してる。というわけで、活かすためにメモを復習がてら羅列。
要約
情報共有しようよ！情報共有大切だよ！
メモ
日本はそんなに遅れてないし進んでもいない。
世界中で同じ悩みをみんなが抱えている。（技術やクオリティについても）
ディスカッションして物事を組み立てて行くことが日本人はへた。（海外の人と比べて。）
これから、日本の文化として、このような情報提供が意味をなしていくと良いなぁ。
情報は出す人に集まってくる。情報や知恵は金に依存せず、対等な立場でギブアンドテイクできる。
「この人に何か言えば有用な情報がかえってくる。」そう思わせれば、情報がかえってくる。発明はひらめきではなく、少しずつの工夫。
思いつきを盗まれるかもしれない？
情報共有で得られる物はHOWでしかない。
HOW=どう実現するか。
WHAT=なにを実現するか？
WHATはその人のマインドにしかない。
つまり、その部分を盗む事はできない。
だから、情報共有しようよ！！
CEDECとは？ −そのもたらす価値の追求− | CEDEC 2010 | CESA Developers Conference
こちらも、丁寧で聞き取りやすくわかりやすいプレゼンとスライド。落ち着いた喋りだが明確で、とても大人すね。内容は２点。自分の経験に基づいた（エンジニアとしての）情報共有の大切さ、そんでCEDECの意味。まんま前の挨拶とかぶってる！
要約
情報共有大切だお。CEDEC盛り上げて行こうぜ。ちゃんと宣伝してねw
メモ
テーマ！「CEDECを身近に感じてほしい。」(元）エンジニアとして伝えます。
日本のゲーム業界は厳しい？
市場 海外延びて国内のびず。
プラットフォーム 据え置き、携帯多様化
ソーシャル ブラウザ 市場規模はどこまでか？
ゲームの遊べる環境がとても増えて来た。その中で市場をどれだけうまく使えていますか？
まだ誰もわかりません！w
日本は欧米のゲーム開発に遅れている。
規模の拡大 開発・プロモーション ハリウッドスタイル 数百億円
顧客志向のゲームデザイン・先端技術 ターゲット志向。
開発手法 統合環境 スキル蓄積
開発を如何に効率をあげるか？
今はそういう傾向にある。正直遅れている。
だからって全てだめということはない。
でも、気づく事は、
「進化への対応が遅い」
この理由を考えておこう。メイン。
欧米と差がついた時代
1980-1990年代のIT(情報産業)
専門家の計算機→オフィススタッフへが使う。
（ゲーム業界に照らし合わせると。専門家（コア）からオフィススタッフ（カジュアル）へ。）
sumio)例えとしてはうまいけど、これは違うでしょうw 技術が一般に普及したんじゃなくて、コンテンツが一般層に広がったのだと思うんですが。
日本はそこでメインプレイヤーになり損ねた。元々メインプレイヤーではなかった）
その理由。
危機感の欠如
戦略の欠如
トップよりも下の戦略：一番のマネをすればよい。
しかし、マネは一番にはなれない。
課題共有の欠如
「課題共有」は個々の企業だけでなく 企業を超え、広く関わる開発者。
顕在化が叡智を呼び起こす。
課題共有を進めていたのは、海外企業。
日本企業の島国根性。クローズドすぎる。閉じすぎている。
開発者が開発者として情報共有し、話し合う場がない。
海外は色々なイベントが盛りだくさんw
ex) HotChipsという開発者イベント。
取引先のHPから周りの人に沢山の紹介をしてもらった。すげえ！
情報提供 vs ノウハウ保持。
開発者が切磋琢磨する場。
原体験。
sumio）情報を提供できないのは自信がないから？
ゲーム開発を続けるために
よいものを作ろう!
銀の弾はないよ。可能性はあげられるでしょ？
sumio）あくまでエンジニアとしてかな。
謙虚さのある危機感もとう！
日本がゲームのトップランナーだと自負しましょう。傲慢は馬鹿。
閉塞感・停滞感×
（続き）ゲーム開発者は何をすればよいのか？
進化の認識
危機感の共有
進むべきベクトルの確認
→自己の研鑽へ。
ゲーム業界も開発としては変わらない。
自分を育てるのは自分。
・CEDECとは
ゲーム業界に関わるあらゆる人材を対象
ゲーム開発能力の向上を目指す！
プログラマーのイベントという捉え方をされている。
デザイナもサウンドもプロデュースもみんなで。
いいものなのに売れなかった＝言い訳。
CEDECこようよ！！
開発者のイベントあるんだよ！って言いたい。
CEDECのもたらすもの
ゲーム開発の抱える課題を顕在化
情報・知識の共有
開発者同士の研鑽・交流
特別招待セッション【南場智子】ゲームプラットフォームの未来 | CEDEC 2010 | CESA Developers Conference
とっても騒がれたセッション。南場登場だよぅw
どんな罵声を浴びせるかと思ったら、意外にも丁寧な口調。かなりのイケイケ感は出ているけどね。「アザース」って言ったときには萌えたよ。俺は。
しかし意外と人が少なかった。
- 概要
コンテンツ制作とユーザにとって共通のプラットフォームを提供すべーき。
- メモ
南場に萌えた。
あざーす。
プラットフォームウォーズ、mixiとモバゲーとGREEが社員を奪いあう。三日間でこういうゲームつくります。
アジェンダ
Whyガラパゴス？ モバイルサービス事業者の視点から。
ゲームプラットフォームのこれから。
DeNAの事業ビジョン。
Whyガラパゴス？
2008年：携帯でのウェブページサービス、ゲームサービス
他国にくらべて、日本ではみんながやっている。（マーケット増大）
携帯でのページビューがPCのページビューを上回っていった。(07~08)にかけて。
740 : 485
モバイルのモバゲータウン : yahooサービスの全体。
モバイルへの没入ぶり、日本は海外とは別の価値観でモバイルマーケットを・・・
だけど海外には行けない。→マーケットの限界。なんで？
本当の理由は小ささ。
国別仕様 x キャリア仕様 x メーカ仕様 x 世代間の差
格仕様に適応させるために、すべてに適応させるのは大規模すぎる。
市場がなかったわけじゃないが、旨味を感じない市場構造だった。
（これって市場がないってことじゃないん？）
2009年 モバイルトラフィックが爆発的成長
at&t ５倍
facebook １３倍
twitter ２９倍
何が起きたか？
答え：iPhone。
これはある種クローズな環境。だが同じ土俵でひとつのサービスで対応できる「モバイルのプラットフォームの誕生」
しかも「ユニバーサル」なニーズ!!!!!!
iPhone以後、色んな会社がOSだしたお！
ゲームプラットフォームのこれから・・・外部の目
PF:これまで、他PFとの差別化Maxを志向
サードパーティ:できるだけ効率的にマルチPF対応。
利益と方向性の相反
ゲーム業界の市場規模
ソーシャルゲームビジネスの拡大。(携帯電話)
PF: docomo Au softbank 通信事業
間に モバゲー！ インターフェース！
サードパーティ： マルチプラットフォームをモバゲー上で展開。
７ヶ月間で189社が441タイトルが公開。
スマートフォン時代のソーシャルゲームPF論
x-deviceのプラットフォーム
androidのユーザがgoogle、 windows mobileと一緒に遊ぶ。
そういうプラットフォームを誰がいったいどう提供できるのか？
（デバイス／OS フリーの世界へ。）
細分化されていたグローバル市場から、
スマートフォンによる4~5の巨大市場の出現。
世界市場への挑戦の大きなチャンス。
異なる単圧を意識せずに誰とでもつながり、
誰とでも遊べるプラットフォームこそが求められる。
上位のX-deviceのPFへのパワーシフトが発生。
8％: 4％
Global市場への挑戦。
新のNintendo
過去３０年、日本から発した世界への企業がない。
国籍よりも個人差がおっき。
アメリカ企業はアメリカ人でやってるわけじゃない。
全世界からやってくる。
sumio）思ったのは人の少なさ。興味ない？南場きらい？w
プロトタイピングがもたらす大きな効果とは？ コンセプトからパブリッシュまでを“超光速”（LightSpeed）で | CEDEC 2010 | CESA Developers Conference
ラピッドプロトタイプの重要性は本当に意識しないといけないと感じています。どのソフトが良いのかよくわからんけど、とりあえずということでそういったウェアの知識の一環として見に行く。プレゼンわかりにくかったけど、なるほどと思いました。しかし、アイディア先攻、独創型の日本の制作システムの中で、３D内でのフレームワークを決めうちしてしまってよいのか？これはフレームワークで当たり前に出くわす問題なんだけど・・・やっぱりプログラマは必要なんだよね。そういう意味で。魔法使いは現実に要るのです。
要約
プロトタイプがもたらす生産性とゲーム性の向上。
LightSpeed使ってね！
メモ
海外のスタジオが多く閉じて、しまっている。
ハイクオリティゲームをより少ないリスクで、より少ないスタッフ数で、より低いオーバーヘッドと予算でゲームをつくりたい。
アジェンダ
なぜプロトタイプをつくるのか？
プロトタイプベースの開発手法を使った４つのインターフェース
ツールと正しいチームの姿勢がゲームアイデアのプロットにいかされるか。
なぜプロトタイプをつくるのか？
ゲームは視覚的。
プロトタイピングは、ゲームのパーティカルスライスを提供します。
実際に見せて、プレイしてみないと面白いかどうかはわからない！
ゲームでエンジンについて知ることができる。
ゲームの面白さを知る事ができる。
自分のチームを知る事ができる。他に証明することができる。
ゲーム開発パラダイム
データドリブンを使ったラピッドイテレーション、ラピッドプロトタイプ開発アプローチ。
モデリングシステム、スクリプト、アニメーションツール。
スクラム／アジャイル開発
強健な自動化されたビルドシステム。
ワークフローはパラレル。
プログラマ
デザイナ
アーティスト
できるだけ速くゲームを動かす。
今ある技術を利用する。
ゲームアセットをできるだけ早くみたい。
sumio）早口すぎ。
早くプロトタイプをはじめるために。
既存の物を使う！！！
サポート、ローカライズは結局必要。
自社技術を統合できる機能。
他の技術を統合できる機能。
クロスプラットフォーム対応（特に開始時）：プロとの始めはターゲットを特定できていないことが多い。（！！！！そんな開発もあるのか！）
プロトタイプは大切だよ！！という事。
やりなおしがきく。
大切な部分がわかる。
予算を立てやすい。
これらを早い段階からできる。
デザイナやアーティストを待たずにレベルデザインができる。
■LightSpeed活用例。
■Kung Fu Liveのプロモ。
プロトタイプのためには、時間のほとんどをお客様のための勝ちを着くのに費やし、できるだけ構造的でスアートで拡張性が高くオールマイティなコードを作成するのに莫大な時間を費やしてはだめ。
フィーチャープロトタイプ：
特徴を抽出し、何が良いか悪いかを見極める。
ゲームによって目的が違う。何が良くて、何が大事かを見極める必要がある。
アドバイス
アートは相手に伝わる程度のものを作ろう。
簡単に拡張できる既存のコードベースを使う。
あなたのテストは不十分。
Media Wikiゲームのデザインドキュメント
バグトラッキング Mantis
リソース管理に トータスSVN
いつでもどこでもデータドリプン開発。
■Wiiの開発事例。
BroadWayのPV。
早い段階で成功していても楽に構えては行けない。
ターゲットプラットフォームで試す必要がある。
簡単なゲームのでもを非常に早くつくるためにToolbentchをつかった。
必要な機能
ラピッドイテレーションをサポートしたレベルエディタ
LUAによるスクリプト機能。
LightSpeedのお話
ゲームのエンティティを用意にうんたら
プログラムの必要なし！！！！
WhiteBox
コリジョンなどのボックスをおける。
レベルエディタで使える。シーンを作ってセーブ。
一瞬でゲーム内容に反映される。
アーティストがゲームを作るまでゲームのレベルをデザインできないのはおかしい。
LightSpeedできる。
スクリプトで人が死ねなどのダメージ設定もできる。
ブレークポイントをおけるので、デバッグして変数の値なども逐次みることができる。
すごい！！！！
ここでエラーw
音機能を追加できる。
ゲームエンジンの調査が必要。
sumio）3Dシーン内でのイベントや独自性がだせないかも・・・・そこはスクリプトで独自に面白いことをやればよい？フレームワークとして３D空間でのイベントは必須。かも。逆にデザインの自由度を与えればよいのか・・・・試してみる必要性あり！！
アニメーションのツールもありまっせ！！
sumo）ゲームエンジンについて幅広く知っておかなければいけない！！！
LostPlanet2 DirectX11 Features | CEDEC 2010 | CESA Developers Conference
ロスプラ２PC版にDirectX11のテッセレータとDirectComputeをやりましたぜ。って話。うん。まあそうだろうって感じ。でも、一番の問題は「見た目にわからない」こと。そう、エンジニアのやれる事がビジュアルに対して細部かしすぎているのは事実。でも、まあ、これしかないでしょうにw テッセレータでより良いLODができれば、かなり目に優しい絵作りが可能になると思うんだが。そうでもないのかな。
概要
DirectX11のテッセレータでサブディビジョンサーフェイスを。
DCでソフトボディったよ。
でも、見栄えあんまかわんないよorz
メモ
スライドクズ。
MT-Framework 2.0採用
アジェンダ
テッセレーションの活用
コンピュートシェーダの活用。
テッセレーション
今まで効率的な活用がされてない。
ハルシェーダドメインシェーダによって、柔軟にてっせれーしょンが活用できるようになった。
サブディビジョンサーフェース
曲面をなめらかにする良く知られたアルゴリズム。
PNTriangles ：Curved PN Triangles I3D 2001(論文)
Phong Tesseration SIGGRAPH2008 paper
Approximation Catmull-Clark charles loop and scott schaefer
かなり有名。
いくつかのアプローチ
法線をすべて連続ととらえる。
同一座標で法線が連続出る事を保証・・・意味不明
ジオメトリ法線の問題：丸くなりすぎる。
解決方法：エッジ単位で制御する。
各頂点に３びっと情報をのせて、ハルシェーダで制御。
それでPhongTesselationに対してもエッジ制御のアプローチを適用。
ジオメトリ法線
利点
ポリゴン数の増加がない。
典型的なエッジではうまく動作。
欠点
シェーダの命令が多い。
その他のクラッキング
Tジャンクション
重なったところにマスクを作成。
問題点：調整パラメータを導入。（あたりまえ）
エッジの長さと丸さに基づいた係数。
長くて丸いエッジほど緩やかにする。
マテリアル単位でアーティストにつくってもらう。
の）マテリアル単位？うまく使える？
デザイン的な問題の対応。
確かに調整はできてる。
ディスプレースメントマップへの作成。
ハイトマップと法線マップを作成→なんで？ハイトだけでええやん。
LostPlanet2のモデル。
正確なハイポリゴンモデルが存在しない。
Z-Brushでハイモデルを作成しなおしに。
ディスプレイスメントマッピング
クラッキング
同一座標のエッジが参照するテクスチャ座標が異なる。
クラッキング対策
ディスプレイス
違いがわかりにくい。
ディスプレイ素面とを前提としたモデリングが必要。
テッセレーションの最適化。
アダプティブテッセレーション
最適な分割数の決定
不要なバッチの排除。
シェーダユニットの負荷バランス
最適な分割数の決定
エッジ単位、曲率などなど。
不要なパッチはカリング。
などなど
実際のハイエンドノートでのデモ。
・テッセレーション
テッセレーションを起こしても
オンでもオフでも差がない。
・ディスプレイスメント
重たいわりに効果なくね？w
■■コンピュートシェーダー
■Wave particles！
全体的な波：ディスプレースを多重合成して表現。
キャラクタ野動きにも対応。
DirectX9 DirectX11の波。
SIGGRAPH 2007の論文。
波を直進する粒子として表現。
粒子感相互作用sなし。
粒子を分割。
粒子をポイントレンダリングして、フィルタイリングして、ハイトフィールドの水面を作成。
・簡易版Wave Particles。 実際の成分。
粒子の分割を行わない。
波の発生は指定した点から放射状にのみ。
Append Structured Buffer ASB
Unordered Access Viewをもってる。ランダムR/W可能。バッファ。
要素として構造体が使える。
バッファの最後に指定した要素を追加できる。
粒子の増減管理に対しては、二枚のアSBをピンポン式に。普通。
スタックレスのAABB-Treeにして衝突判定。
・CS実装
粒子数が増減するのでスレッド数が不定。
DispatchIndirectがあるので、それを仕様して、更新CSを軌道。
ポイントレンダリングのため粒子バッファ（ASB)を頂点バッファ化
ByteAddressBuffer(BAB)
コンピューとシェーダを使って粒子バッファから頂点バッファへコピー
不定な物はIndirect命令を使って描画する点数をCPUリードバックなしに取得。
フィルタをかけたハイトマップ。
■Soft Bodyによる巨大ボスの表現
巨大ボスの表皮をよりリアルな動きをもたせる。
アーティストが表面を塗ぬるだけで、固さを調整できる。
質点バネモデルmass Spring Model
三種類のバネ。
表皮面を肩膣グル
骨と表皮をつなぐ、
質点とスキニング頂点をつなぐ。
Connected Surface Structures。という論文。
Surface Spring
Verlet物理：SHAKE法
質点の運動
Verlet積分：位置を直接動かしても安定。
ゲーム分野でも広く使われている。
D９では
Surface Spring と 〜〜スプリングのみで ８。
ソルバ：Gauss-Seidel(GS)
前計算を活用するので、早く収束するが、逆に前に依存するので並列に処理できない。
D１１では
ソルバ：Jacobi
計算依存なし→並列処理むき。
Dispatchが一回
・副息メッシュや接続数が多いとき有効。
前処理（バッチング）が不要。
収束はGSより多遅い。でもGoalSpringwotukaeba あまり変わらないのでオK。
CS：
スキニング
Verlet積分
Jacobiソルバ
頂点バッファ更新
CSおわり。
→
VertexShadr
Hul
Domain
Pixel
の流れ。
■デモ
GPUで処理を簡潔。CPUリードバックなし。
実装しやすい！実装が従来のGPGUよりも扱いやすい！
GPGPU的発想をしらないといけない。
10ヵ月でHDゲームを開発する方法 ～龍が如くを支えたテクノロジ～ | CEDEC 2010 | CESA Developers Conference
ミドルウェアをがんばって制作効率をあげましたよ！という話。実情本当にどうかはわからないけど、こういう縁の下の力持ちを讃えるセッションは、自分が慰められてる気がして好き。
概要
生産効率をあげるためのツール制作で、短期間でハイクオリティなゲムが作れる。竜が如くの方法とは！
メモ
竜がごとくの説明。
ほぼ一年毎にシリーズ続編をだしています。
今回はPS３での開発に特化している。
竜が如くシリーズは一年間ごとに出す使命。
開発期間は１０ヶ月間
クオリティは維持：むしろ向上。
※すべての企画とリソースがそろっていることを前提。
■環境開発編
時間をいかにけずることができるか？
リソース管理
HDゲームではLANを通じてすう百GBのコピーが発生。
ビルド時間の短縮
（ソースコードは普通にSVNで管理）
高性能なサーバネットワークの導入。
ハードの限界→内生ツールで対処。
社内P2Pツール
職種によって必要ファイルの選択
バージョン管理機能は必要最低限。
ビルド時間の短縮。
竜４ C＋＋ １２０万行
分散ビルドで解決。 Xoreax IncredBuild
リンク時間の短縮=PCの高性能化。
PCでの代替開発。
実機よりもPCで処理したほうがわかりやすいに決まってるよねw
コーディングしやすい環境づくり。
緩いコーディングルール（モチベーションの維持）
内製ライブラリ。 PCとPS3で同じ動作を実現。
チームのコミュニケーションと育成：ベテランから若手まで３５名！
「プレイスポット」で若手の育成。（一人でつくらせる。）
パーティションを立てない。
■■基礎技術ライブラリ編
PC上でどう再現するか？そしてシェーダの運用。PS３の最適化。
開発用マルチプラットフォーム
考慮した機能と考慮しない機能を明確にわかえている。
vf128という形を使う事によりSIMD演算か。
コンパイラ依存の記述をマクロで吸収。
PCとのマルチプラットフォーム環境
ゲームアプリ開発者には負担をかけない。
チュカンライブラリで吸収。
意味のない最適化はしない！！
オブジェクト数、マテリアル数が多い。
最適化例）１２０００回は異常。じゃあ、何回ならいいの？わからない。
ppuの描画セットアップのほうが時間かかる。
なので、ppuの最適化をspuでおこなったお！
■■第３部デバッグ編
ランタイムでバッグ機能の紹介。
プロジェクト運用技術の紹介。
デバッグがやたら短い。
非デバッグ期間
休日、深夜時間の有効
人手をかけない。
りゅうごとのプログラマは遅刻しないってさw
画像認識技術とゲーム・インターフェイス | CEDEC 2010 | CESA Developers Conference
KinectじゃなくMoveのSCEが画像処理のお話。でもSPU使ってばしばしというわけじゃない。動的差分とか背景差分を使って「いかにゲームをつくるか？」というトピック。面白い。相当に面白い。理論を優先せずに、今できる事で面白くするってのね。ビンビンです。掛さん頭よすぎw
概要
画像認識の基礎、そしてそれらを用いてゲームを作るときの心構え。
メモ
■昨年のおさらい
世界の構築
世界の維持マジックカード
■画像（物体認識）
動き差分は低負荷で高い安定性。実装マジ簡単。
カメラでの一番の問題：環境（光の変化）
PlayStation3 EyePetになって進化したよ。
世界の構築
背景差分：
カメラからの入力は非常に不安定。
ゲームでは安定性が必要。
動き差分：
カエルは動いてるものしか認識できない。
インタラクションの実現。
動き差分で、非常に粗い制度のインタラクションを行っている。
粗い処理がユーザフレンドリな処理を行っている。
回避行動をさせることにより、画面の全面に人が映らない様にしている。
間接的なインタラクション
認識とは・・・・人が「機械が認識している」ことを認識する事。
マジックカード
画像人しい（サイバーコード）
３時源一、傾きの取得
ハンドル（部分隠れの抑制）
認識できるからといってもゲームにはなりたたない。
ボールの遊びのデモ。
傾きの表示はしているが、ボールは平面との衝突しかしない。
認識を使うポイント：精度が高くても、面白い物にはいかに制限を加えて、
それをゲームに適応するかが問題になってくる。
■顔検出、スマイル認識
物体認識！！！！！
認識といっても沢山種類がある
これは車？ Verification 確認
車はどこ？ Detection 検出
どんな車？ Identification
Categorization
画像認識なぜ難しい？
部分的な隠れ、背景の違い、ゆがみなど、様々な変化のために認識ができない！
全体のマッチングでは難しかったが、
エッジ部分などの局所的な部分を認識することが最近有効だとわかってきている？使われている。
1980：線絵マッチングの時代
1990：グローバルマッチの時代
2000：
特定物体の認識 と 物体カテゴリの認識。
the car a car
これらを見つける
入力画像
特徴点検出：画像のどこを見れば良い？
特徴量抽出：画像のなにを見ればよい？
学習 または 認識
・輝度変化が大きい：局所領域での輝度変化
特徴点の検出：ハリスのコーナー検出アルゴリズム。
・特徴点の周りの画像パターンを使う。
局所特徴量：SIFT scal invariant Feature Transform
照明の変化につよい。
矩形フィルタ。
・学習
・カテゴリの認識
統計学集
今後１０年でどう変化していくか？
より難しい物体認識
顔、車→人、馬、犬。
シーンセグメンテーション
３次元の認識
多くの物体の認識
どんな物体でも検索
学会あるよ
ICCV CVPR
