■ 名越さんの講演 
３日目の名越さんの基調講演、豊かな経験を持つ人の話は含蓄があってどれも面白い。「インストールベースが一番多い所に興味と時間を取られるので、そうなったものには勝てない」「デジタルは便利だけど、デジタルに頼れる限界を自分で持っておく必要がある」「損をしたくない、という感覚はそもそもデジタル」
※損をした、という経験も楽しめるようになりたい
「デジタルは確実に裏切るもので、然うなった時には人のそれよりも冷徹」
プランナーの受講希望者が増える
セガの紹介：
業務用を作っている→家庭用も作っている
（もともとの足場がそこにある、という…。）
言葉の端々からアーケードも大事にしている感があるあたり、なんか来るものがある
「インストールが多いものに興味と時間を取られる、勝てない」
悲しいとは思わない。
いまスクリーンに映ってる映像、アルベドが低くてスペキュラの反射率は高いのでライティングが難しい感じ
白根小プロジェクト、また厄介なものが出て来たな、と。
最強のインストールはスマホ、まだ２倍から３倍は伸びる、と思ってるので、そこを狙わない手はない
※長くやってる人の話は面白い。見ているスパンが違う。
「〇〇向け 企画書」でググった話。
怒っていいのかどうなのか、迷った。
新卒の面接、同業他社でなく、異業種を希望しているひとが増えている。
新しい時代にあわせたモノを作れる会社である為には、そういうひとも以内と
「バンダイ派かセガ派か迷っています」という人も笑顔で迎えられるようになった（！！！）
「デジタルに頼れる限界」を自分で持っておかないと。
「損をしたくない、という感覚はそもそもデジタル」
※損をした、という経験も楽しめるようになりたい
「デジタルは確実に裏切るもので、然うなった時には人のそれよりも冷徹」
※豊かな経験を持つ人の話は含蓄があって面白い
「『とにかく認知が高くて、誰もやってない事をやる』、これがヒットする」
仕事の進め方は４つに分類される。
１、「早くて、正確」
２、「早いけど、間違ってる」
３、「遅いけど、正しい」
４、「遅くて、間違ってる」
１は難しい。４は論外。残った２と３のどちらを選ぶか、で人間性が出る
質疑：
CEDECに若い人が増えている、
歳を取ってくると現場感覚が亡くなってくる、世代間ギャップを埋めるという意味でも取り組んでる事はないか？
→普遍的なもの、仕事をする上で、とか、ゲームを楽しむ上で、とか。
道理というコドバが大好き、道理はかわらないので、これに逆らったらダメ。
それをさらにスピードに乗って進めるようにする為にどうするか、は、そこのノウハウは100年前も100年後も変わらない。
そういう道理に乗った言葉を（信じていたけど間違っていたな、と取捨選択しながら）溜めていって、
それを適切なタイミングで若い人に伝えて成功の確率を上げていく、というのがキャリアのある人の勤め。
個人の生活様式が変わる。でも、それは仕方ない。ジャンプよりも子供と遊んでる方が楽しい。
時間の使い方が変わるのは仕方ない。
でも、若い人が面白いと言っている事に対して、どこが面白いのかを「ああ、そうか！」と知るのは大事。
そういうものを見ながら、いまはこれとこれでこういうパターンが流行っているのか、くらいはわかっておくる必要がある。
？４つの選択、失敗したケースは？
勉強になるのは失敗したとき。
上手くいったプロジェクトで何か学びましたか？っていわれると「自信がつきました」意外にいえる事がほとんどない。
「道理に従ったから」はあっても。
失敗に関しては、絶対に嫌なので、
性根は変わらないので、こっちでしっぱいして絶対嫌だ、と思っても、しらずしらず体がそっちを向いていたりする。
※名越武芸帳ににた話が。
スマホはトライアンドエラーが多いので、羨ましい。10年で3本、ってこともある。
2年で7本だと、失敗の量も多いのでキャリアの詰み方が変わってくる
失敗の落とし穴に落ちた自分が死ぬほど悔しい！から。
でも、これを考えすぎると冒険しなくなる。バランスが難しい。
？いまアーケードゲームの企画が上がって来たら通すと長内の基準は？
プリクラ、UFO、カップル以外はコアな世界
オンラインに繋がってないゲーム機はない。運営。
運営商売はモバイル系のビジネスに近くなっているのがいまのアーケード
100万円で売っていたのを50万円で売って、残りの50万をインカムを7:3で3を頂く型値になった
コアな人に向けたものになる。
でも、コアな人だけでは広がらないので、それ以外も。
現状ある遊び方が好きな人が中心。基準はそちらにミートしているかどうか
プライズ以外も広げたいので考えている。
海外のアーケード、安い。日本で1xx万のところが30万円くらいで売ってるが、
PL法に引っかかるレベル。でも安い。その辺とけんかするのが大変。
もう一つ悩み、興味があってもインストを呼んだだけではわかりづらい。そこを解決できる企画を出していきたい。
いまはコアを重視するのが突破口。賞金つき大会、Eスポーツ的な流れを見込んで徐々に。
海外のEスポーツプレイヤー、年収10億で子供も寄ってくる。
？作りたいものが作りにくい。昔からやってて憧れてるゲームが作りづらい、インディーが発達している。その変動思ってる？
29が若い。
作りたいものは作れない！
作れるべきものの中から取捨選択している。ニーズに対してシーズ、提案だけで飯は食えない。
どこまで厳しさという前提を考えているか、はわからない。
それを理解したという前提で、二極化している分、（コンソールとスマホ、など）日本のゲームって20年くらい前は海外でもトップ20のかなりを締めていたのに、今はほとんどない。
大型投資に躊躇しない海外には勝てない。それが当たり前。
ゲーム先進国みたいにいわれたのは京都の花札屋が世界制覇したから。
すべての文化は西洋に吸収される。
小島さんはすごい戦いっぷりで頑張っているので応援してる。
大型のものが通用しない
あとは、みんな夢を持ってるから、その中で是非やりたいものと、きっとこれが売れるものがあったら、プロは迷わず後者を選ぶ。
やりたい事と売れるものの重なっているものを選ぶ。その領域は限りなく小さい。それを探すのがプロの仕事。見つけられたら、売れる。
その重なりを広げたければ、自分自身の興味や知識を広げて、いろんな事をやって興味の範囲を広げれば、その重なった部分が広がる！
？バンナムではゲームジャムをつかって失敗を経験させてる。セガは業務外でやってる。ゲームジャムを活用する考えはあるか？
セガの製品は、開発が全部やっているわけではなく、事業部が外のブランドから買い付けて来てパブリッシングしているパターンもある。
リスクのチャンスという意味では、バンナムは儲かっているから？
一応そういう課題を出すような仕組みはある。新しいシステムでそういうのをやりたいと話している。
そういうのを作りたい、実験をして、あわよくばパイオニア的なプロジェクトに育っていけるようなものは是非やりたい。
メカトロ部門がある、ニューテクノロジーカンファレンスにいくと、尾奈品物がたくさんある。
電磁波だけで宙に浮いている玉とか。
ゲームじゃないけど、企画者はそこにインスパイアされる。
ゲームセンターで成立しないけど、企業の受付では？、とか、そういう機会はうち（セガ）は多くある。
ラボ的な昨日はいまだに結構強く保った会社ではあると思う。
？短いスパンで作る、コンシューマーは重い、映像的にこう見せたい、という描画はどうしてる？
それは僕が決めてるわけじゃない、ただ、すごいプログラマがいる。その人と話をして、ぜひこういうニュアンスはつくってみたい、と伝えたり、これを取り入れたい、という意見が出てくる。じゃあそれを入れると何ができるの？、というやりとりからセッションから生まれる。
両方があるのが望ましい。
？元ゲーセン店員。今の世代にキャッチアップする、とインスパイアする、という点について。時系列的に変わっていっているな、という場所や人について、秋葉原を20年以上眺めてて、人の好みや建物を変わっていって、今この人達はこう思ってるんだな、と。それからインスパイアを受けて店のサービスにて尿している
龍が如くに10年間歌舞伎町を扱って、人とか建物とかで印象に残ってる事。
そんなにない。
ただ、一年で１作作ってるとメリットがあって、タレント起用は古くは鬼武者だが、1年スパンでだと今旬な人が使えるのでタイアップするだけ。
変わった事をそのまま取り入れていく事も部分的にはある。ただ、それをゲームに取り入れるとテンションが下がってしまうので、自分たちが然うなってほしいと言う願いをゲームに組み込む事の方が多い。
?F2P
サンプルムービー、試したい。
それやっちゃうと買わなくなるんだ、という声を退けて、もうかるから見せるんだ、とやった人の頭の中。
ペイ２ｘｘｘ、のｘｘｘの新しいキーワードを探していける人が、F2Pの勝ち組になったり、小さいプロジェクトのなかでも
そういうのを見つけるのが
？リーダーとはこうあるべきだ、という名越さん的なリーダー論。
「ヤクザものの裏社会」は認知がある。で、ゲームでそれをやった人がいない。
雑誌に乗った時に読飛ばされないだけのエネルギーは持ってる。
だが、わかってもらえない。
最終的には100人になるチームに、一人一人説得しながら伝える。
ぱっと見は３流に見えて、それを一流のお金をかけてやる事に意義があるんだろう。
いろんな人に勝手なことを沢山言われた。
「あの人はこれを作ってこの仕事を辞めるんだ」と言われたり、
子供が生まれるんだけど、子供に自慢できないようなゲームは作りたくない、と言われたり。
「自分がぶれちゃダメ」それが一番当たり前なんだけど、難しい。
まずは信じれるところまでスタートしない。スタートしたらぶれない。間違いは一秒でも早くただすのがリーダーだが。
何を考えているかわかりやすいのがリーダーには大事。
---------------------------------------
木の葉や草がやけに戻りっぽい、炎などのエフェクトが別の場所に奥とおかしく見える、黒いビニール袋がやけに際立つ
別のカメラで変わるくらいの精度が求められるものなのか？
「RawTherapee」というフリーソフトでLinearRawが抽出できる
「Dcraw」をビルド（c99）でビルドエラー、
「RibRaw」で、C++CLIでUIを作るのがいいらしい。
コーンやビニール袋はそれっぽいが、壁のコンクリ０とは今一に見える事も多い。
スペキュラーの反射のせい？
権利的に、実在の場所の写真を出すのは権利的に問題があるばあい、それを完全再現したCGを出すのは同様の問題があったりしないんだろうか？、などと思った
露出を再現するのが、フォトリアルのキモになる。
「カメラで見た時の値が正しい」と、目で見た時の印象を会わせるのはどっちが大事か？
カメラにあわせるのが正解なのか？
写真に撮ったときの炎が白飛びして肉眼で見た印象より白く見えすぎる問題への対応として、FPSや没入型のVRでは「フォトリアル」の次の段階として、「肉眼で見たときの印象をそのまま再現させる」というステップがやって来たりするんじゃないか、とか思った
LEDライト、 0.0025
太陽光 220
スカイライト 90
（あまり意味のある値でないかも）
最近ブログの更新が止まってるという指摘を頂いた。１年遅れのブログ更新を始めてから２年が経っていて、つい面倒になって半年前で更新が止まった結果として最新日付は1年半前になってるというややこしい状態になってる。
高架下をLookDev環境とする時の、環境マップはどうしたんだろう？スペキュラーの入力。
--------------------------------------------------------------
サッカーパンチ
エフェクト重要、という文化を感じる。親近感。
ゲームを作り始めて16年。
固定機能のパーティクルのパイプラインを持っていて、SPUのC++が書かれていて、アーティストにスイッチを提供してたが、
変換して実機に出すまでに数分かかる、という事があった。
SPU->GPU、コンピュートシェーダーでアップデートを行う。
CPUのメモリアクセスよりGPUの方が10倍速い。
エフェクトアーティストにより多くの事ができるようにしたかった。新しいコードを書く事なく、なるべく反復を早くする。。
ポジションやカラーなどの数式の集合体。アーティストはこうした数式を書いて
数式を書いたものを、PSSLにコンパイル
絵ミットCS、updateCS
ダブるバッファ。
PS4の今ビューとシェーダーはメインのグラフィックスパイプと非同期に動かす事ができる。ハードウェアがスケジューリングする。
APIをコールしてプライオリティを着けられるが、タスクを始めて終わったかどうかを見るだけでいける。
ほとんどの処理を非同期のCS
今ビューとのタスクをディスパッチするのはCPU、それ以外のほとんどはGPU
エミット、アップデート→ドローレコードを出力
ソートレコード→ソート、をドローレコードの並び情報をGPUで別途出力
リボンの繋ぐのも別処理。（）
フレームごとに、
30Kパーティクル(128Kまで)
雨が30〜40K
1000エミッタがアクティブで、
update+sort 4ms
描画 3ms
一つのシステムの中に複数のエミッタ。
キーフレームエディタがある。リニアファンクション
キーフレームを止めた状態でリアルタイムに変えている。
リモート可能、UIをホストPCに移動する事もできる。このシステムは時間を掛けて作られていて、パーティクルエディタ以外にも使える。
式→PSSL→マシンコード、に変換。
最適化はPSSLのコンパイラに任せる。
定数を微調整可能。
全ての定数をグローバル変数に置き換える、値を変更するとリコンパイル無しに修正できる。
値を帰ると、結果が瞬時に反映される。
コンパイルすると20秒かかるので、瞬時に変更できると一番いい値を見つけるのがすごく楽になる。
ユーザーパラメータ、外の世界にさらされた変数。
スクリプティング言語で設定されて、パーティクルに値を渡す（smoke color、爆発のサイズなど）
プレイヤーの速度に基づいて明るさを変える、など。
エミットイベンツ
いつ生むのか、を規定する
CPU側で、エミッタごとに実行している。コンピュートシェーダースレッドをいくつ実行するか、を決めている。
カールノイズ
位置から時間的、空間的に滑らかに変化させる。煙が自然に消える、
カールの伊豆フィールドの動きを視覚化すると面白い。時間軸で回るようになってる。
カールノイズの3D視覚化、かっこいい
一日中ぼーっと画面の前で見とれてしまう→同じ病気だ！
リボンパーティクル
親子構造。パーティクルを何らかの型で繋げる。親と子を別のエミッタで繋げて、この方のエミッタを出した場合には親の方でもエミッタを定義し、独自のエミッタを定義する
子の方でも親を参照できる
リボンの色は親と同じものにする
親が発生させたパーティクル位置にエミッタがついてく、ついていったエミッタがリボンを生む。
スプラインは一連のコントロールポイントとして指定している。
ジョイントから取得したスプラインでリボンを生成して、カールノイズで歪ませる。
スプラインの周りにもパーティクルを発生させられる。
メッシュからパーティクル発生もできる。モデルがパーティクルに解けたり、戻ったりする。
ネオンサインから発生させて、吸収する
一つのテクスチャをパーティクルのメッシュに使う
Synned area tabke メッシュの表面に置ける位置を確率的に選んで、均一に発生させる。
CHOOSE_POS()
->ある基準を満たすまで続ける(テクスチャの明るいピクセルを見つけるまで、とか)
POS_FROM_MESH()
COLOR_FROM_UV()
パーティクルをメッシュにSpownするだけでなく、メッシュに戻せる。
ここのパーツは新しいものではないが、システムとしてこういったパーツを組み合わせて作る事ができる仕組みは革新的。
始めにシステムを作った時には想定していなかったような昨日も生み出せる。
良くない点：
- アーティストフレンドリーではない
アーティストはコードを翔るのか？→手助けがあれば書ける、プロジェクトの終わりには複雑なものを自分たちだけで作れる
- コードサイズ
オーサリングされたエミッタごとにシェーダーになる、コードのサイズが大きくなる。
何千もあって、それぞれが10KBあるので何十MBにもなる。
PS4はメモリが大きいのでなんとかなった。将来的にはなんとかしたい
ノードベースがいいのでは？という考え方もある。実際にはあまり違わない。同じ意味で、表示の仕方が違うだけ。
GUIの方が奇麗に見えるが、平文での表示にもアドバンテージがある。
マージやソースの検索が簡単にできる。
同じような命名規則や引数があると不便。
不透明なパーティクルはデプステスト＋ディファードライティング。
エミッタごとにドローコールが発生、
ディストーションやリップルバッファは順番に関係なく描画されるが、半透明は
全ての半透明ソートされたものを１ドローコールで実装。
透明のパーティクル全てを同じシェーダーで書かないと行けない。
S_VERTEX_IDを使ってマニュアルで
マテリアルテーブルのインデックス、アトラスされたテクスチャ配列のiDなどの情報を持っている。
512x512から64x64をランタイムでアトラスする。
パーティクルシステムがロード、アンロードするタイミングで更新する。
UVについては数式を使ってエミッタごとに設定
環境カラーのグローバルシャドウマップのカスケードからルックアップして影
エッジ検出
デプスを比べて、パーティクルの色と明るさを変える。
→皮膚の上を這いずり回るようなエフェクトになる、メッシュの周りにたくさんのビルボードを生んでる
タイルベースのディファードレンダリング
別の今ピューとシェーダーをタイル解決時に入れる。
パーティクルをによってライトレコードをアレーに入れるとライトに見える
低コストでライトが表現できる。
1000のパーティクルライトを使う事は珍しくない
跳ね返りはCPUのHAVOKのレイキャストで計算、あまり効率は良くない
■ コンピュートシェーダー 
マルチスレッドとは本質的に違う、並列処理。
10000スレッド産んで、ほとんど同じ事をさせる必要が在る。
syncコマンドをステージ間に挟む。
パイプラインを切るのであまり頻繁に使いたくないので、シンプルに並べる。
エミット→update→リボン化->ソート
の順番で同期しながら処理してる。
乱数の実装、簡単ではなかった。CPUで使って来た乱数発生機は使えない。前の数に依存する。
並列で何万もの乱数を出す必要が在る。
そんな複雑なものはいらない、軽くて早い乱数が欲しい
→後で資料を見よう！（スレッドIDトCPUから来た種）
→SIN関数の出力の下の方を使う、という手がある！
■ パーティクルのGPUソート 
十分な性能が出るまで何度も修正した。
何万もの8バイトソートレコードをGPUでソートする必要が在る。
→バイトニックソート。
→書くのが大変だった、アルゴリズムを循環的に書く、書くスレッドに比較する為にはひっくり返して、など複雑。
より大きな問題は、少数の入力にはいいが、パーティクルが増えると速度が低下する、パス数が増える。
18万パーティクルでパス数が256。
なにかマージソートの更なる並列化を工夫してるよ！
相手側をバイナリサーチして、自分の入れる場所を決めてるよ！こんなのうまくいくんだ！
スレッドグループ単位で実行、
→出力側をスレッドで動かす
自分のインデックス(5)から、入力元が(1-4)とか(2-3)などがわかるはず、なので、バイナリサーチしながら比較してる。すごく考える必要が在りそう。
バイトニックソートより10倍以上早くなった！
※そろそろGPUソートは身につけておく必要が出てきつつある…
質疑：
アーティストが生み出すエミッタのひとつひとつが別のシェーダーになってるが、同時にどのくらい動いているか？
→数多く出しているが、ハードがどうしてるかの数字は把握していない。
非同期コンピュートは役立ちましたか？
→役立った。他のCPUコンピュートと同じフレームでできる。パーティクルは全部CSでやった。
リボンのソートが必要でしょうか？
→はい、これら全て半透明でやっていて、全部をソートしている。
リボンを一つのエンティティとしてそーとしているわけではないが、リボンの四角形がそれぞれパーティクルと同様にソートされている。
リボンが煙に入っていく時にはだんだん透明になる。
※リボンは矩形の塊として
煙が流体っぽいが何かやってるのか？
→一部はカールノイズ。
メッシュからはなれて煙のようにに動いて、一つのエミッタに戻る要な動きになっているが、流体ではない。
CSのプロセスはGPUの処理の中でどの位食っているか？
→updateに4〜5msくらい、drawが数ms
※個性的なインハウスツール、一般的なフローとはかなり別物で熟練が必要だが高機能。
-----------------------------------------------------------
12人の追加のエンジニアが追加できたら？
自分たちの能力と足りたい事のギャップが広がってくる。
プリプロが終わって本製作に入る時に、自分たちのゲームはHaloやCodの要にはならないと気付く
エンジニアリングはスケールアウトしない。
ターン10,レドモンドで2002年に設立、プレイグランドシステム→フォルツァホライゾン
フォルツァ５で、なぜ外部のエンジニアを使う事になったか？
→自分たちの期待と能力のギャップに気付く。9〜12ヶ月進んでリリースまであと1年くらいで気付く事が多い。
フォルツァホライゾンのプリプロが終わって、フォルツァ4のリリース前、X1のローンチリリースに間に合わせる必要があった。
140人年必要、DX9のエンジンしか持っていなく、陳腐化の兆候が見られていた。
MAXを使っているが、DX11比対応、オーディオやUIのエンジンを置き換える必要があった
新しいネットワーキングのスタック、マルチプレイの書き直しも、レースや車体の数も。
新しいプラットフォームでフォルツァ４と同様のものを作るにはそれらが必要だった。
なぜ？
→スタジオのエンジニアリングのキャパシティが高めて、ゲームの質を高めたり、多くのゲームを開発するため
→スタジオの安定性が増す
1+1>2
複雑なストリーミングシステムの視覚化二苦しんでいたが、協業でできた。
→グラフィックリソースが圧縮展開されて読み込まれていく様子をプレビューするツール
OSの変更も加えて、高度なストリーミングシステムが作れた
これまでもあらゆる種類のコンテンツをアウトソーシングしてた。
コードのアウトソーシングと今展のアウトソーシング、どこが似ていてどこが違うのか？
→パートナーシップは有益、ベンダーとか下請けでなく、パートナーシップを組んだ方がより有益。
スタジオやソフトウェアハウスという場合もある、いい関係を持つ
※ナックのと違うのは、出す種類や求める品質の違い？アジアに出すとか。
タイミングについて：
いつ外部のリソースを使うべきか？
→エンジン、技術を新しいコンソールに移植するところでは外部を使わず自分たちで。
プリプロダクションは自分たちで。
実際にプロダクションに入って、ハイレベルのソフトができた段階で、外部のエンジニアのリソースを使いたい。
コンテンツのアウトソーシングから学んだ事：
ITとインフラに投資をする必要が在る、サーバインフラを増強した。コンテンツのアウトソーシングの為に構築した。
→コードはもっとここが重要になる。サーバやテストインフラは対応できるのか？
IT投資をしないと生産能力が発揮できない
コンテンツのアウトソーシングから学ぶはことあったが、同じではない
200の車を作ってもらったが依存性はない、並列して独立に作れた。
→ソフトウェアは同じようなやり方をとれるが、やらなかった。
作業単位は「フィーチャー」、コードの中の複数のシステムにまたがる、そこにスペックを割り当てるのはよくない
パートナーをスクラムに組み込む、不自然なシステムの境界を作らない
できるだけ仕事の単位は小さくして以来、社内の人とおなじ
密なコミュニケーションを維持
コンテンツのアウトソーシングを行う事によっての品質の安定性
依存性がないのでコンテンツがどこから橘高と独立して行える
→エンジンは一枚岩なので、コードを別に置くシステムにはなってない
開発者を35->55に増やしたとき、従来のアプローチではインフラがキャパに耐えられない
自動化されたカバレッジが耐えられない、安定性の問題が発生した
→品質保証に対するアプローチを買えないと行けない
フィーチャーエンジニアが自動化テストを開発しないと行けなくなってもそうした
バグフィックスがあるため、コンテンツと同じ扱いにはできなかった
コードが増えればバグも増えるが、バグフィックスは少人数のエンジニアリングチームでもできる。
思っていたより直さないバグが増えた。
知識の移転を行うにはコードレビューが有用、それを強化するにはフィーチャーの担当者が外部で作られたコードをチェックするようにした
バグフィックスや問題解決を製作段階で導入した
３つの製作スプリントに対して１つのリリーススプリントを持ってる。
製作段階において外部のリソースを…、彼ら自身のバグをフィックスできるように下
コミュニケーション
企業文化や国の文化の違い、パートナーシップとして信頼し合い、尊重し合うようにしないと行けない
個人的なコンタクトを持つ事が重要。
８人のエンジニアをプレイグラウンドからターンてんに招待した、出張費を掛けてもメリットが大きい。
より小さな作業ユニットに対してチームの納得を持たせない解けない
クリエイティブチームではそうしないと最終的なやり直しが多くなる
モチベーション
外注がホライゾンを出した後、疲れていた。
外部の会社を手伝っている間に自社の重要な仕事に就けないのでないか、と思われないように信頼関係が重要
相手がオーナーシップを持ってくれると、モチベーションにはプラスに働く。
なぜベンダーを使わないのか？
パートナーシップを使ってのスケールアウトの方が、ベンダーを使ってのスケールアップの方がいい。
ベンダーのデメリット
→コードの保守、ベンダーが離れると知識が亡くなる
パートナーだと、コアチームが保全されやすい。
１２デベロッパーを追加
6人年追加された。28%増
6人月の作業を切り分けて、オフサイドチームとして使うか、
スクラムチームとして統合するか<-こっちにした
クライアント、オンライン、コンテンツ
12人の開発者を6つに統合
コミュニケーションについては、オンサイトの訪問から始めた。
各スクラムチームには２週間ごとにプロヂューサーなどと個人の会議が行われた。毎日メールも送ってた。
スクラムの原則を守ってた。
「我々との作業は楽しんでいるか？」と聴いたら「イギリス人的に控えめな反応をしているんだ」と答えた
※海外の人同士、同じ英語圏のアメリカとイギリスですらそういう違いが在るんだ。
エンジニアリングリーダーやプロデューサーは仕事が大変になった。
顔を合わせてのキックオフと人間関係が重要だった。
仕事を切り離して分けるよりも、チームに入ってもらった方がいい、能力を活用してもらうのもメリット。
プロダクトバックログ
エリアオーナーとパートナーシップ、
シャットダウンの為に、エリアオーナーが外部で開発されたコードをレビューする
仕事をフィーチャーレベルでなく、バックログのレベルで渡す
→誰か内部のエンジニアが絡めるように
QAについては改善したいと考えている
→各バックログに関して、より良く承認を死体
→初期の段階で十分なQAのリソースを割り当てて、作った後すぐにQAを行って本人に直してもらう
自動化されたテスト
プログラマがフィーチャーを設定して実装する→QAチームがバックログ単位でテスト→フィーチャーをテスト
→オンラインサービスではフィーチャー開発の中でテストをする、これをクライアント開発にも適用する
３つの製作スプリントと、１つのリリーススプリント。
最初のデベロッパーがバグを直すほうが、リリース時に直すより簡単。
※スプリントごとの内部と外部の仕事の進み具合とか、セクションごとのバグフィックスレートなどをグラフとして提示できるようなシステマチックさ。同じジャンルを作り続けてるから、だろうけど。
よかったこと５つのポイント
１、パートナーシップから得たものは大事
２、対面でキックオフをする
３、直接チームに統合する
４、エリアオーナーがコードレビューする
５、コミュニケーションを頻繁に行う
良くなかった事５つ
１、自動化テストと導入
２、QAスタッフがたりない
３、
４、外部のパートナーを早く統合する
５、
デザイナとのイテレーションが必要なものは速く
曖昧な作業はスケジュールのリスクになる
質疑：
自動テストについて、フォルツァでは結構な部分の自動テストをやってると思うが、
できている部分のテストをどうやって自動化しているか？
→Windows上でもX1でもWIn64DX11でも動く、
ビジュアルテストとビジュアルスタジオで作っているが、ゲーム上で動いている。
それぞれのテストは再起動がいるので時間がかかる。
書くビルドのコースごと、車ごとに、コンテンツが有効であるかを確認して、クライアントに対して自動ストを行っている
最終的なゲームができ上がるまで検知する事ができる
OSのリカバリーの変更でパフォーマンスが下がった事が検知できた。
フォルツァの中でテストモードが実装されている？
ゲームのデバッグ版というのはシンプルなテクノロジーを使っている。最適化されたバージョンでバグ
ブラウザを通してPCを実行させる事で、大量の統計を取る事ができる。
SQLサーバに吐き出して、実行して、後で取り出す事ができる。
エリアオーナーの仕事に就いて、エリアオーナー自体はコードを書くのか、書くならレビューとコーディングの割合は？
→エリアオーナーはほぼ全てのエンジニアのチームが何らかのテクノロジーエリアのオーナーになっている。
より小さいキャパで定義する、という形にはなっていない。彼らのこれまでの履歴をとっていて、どれだけのキャパが在るかを計測している
ジュニアのキャパは小さく、シニアの方が大きなキャパのエリアオーナーになる。
レンダリングのエリアはシニアがやるが、ポストエフェクトのエリアはジュニアでもいい。
トラッキングした結果に応じてエリアが割り当てられる。
プログラマのキャパシティはどう計っている？
バックログの、個人に作業要素を割り振っていく。デベロッパに対してS,M,Lなど。XLは分割して、それぞれにポイントを割り振る
時間軸に対してバックログをクローズするごとにポイントを獲得していて、その履歴を取る。
９のバックログのポイントをスプリントあたりに取れるはずだ、と決められる。
そういった数字を得る事に寄って、全体的なキャパシティを得る事ができる。
そういったデータを個人にフィードバックしていく。
PS4 1000万代、日本でパイオニアに慣れるビッグチャンスが在る、との宣伝。
UE4 Unity PhyreEngie Orochi
SCEは、ゲームエンジンがハイエンド対応の懸念にたいするソリューションになると考えている。
最近のゲームエンジン動向：
安い、導入コストが低い、とりあえずつかってみる
使いやすい、直感的
膨大なノウハウ、フォーラム、大量の本当ユーザー同士の助け合い
Unity導入
SCE DEVNetから落とせる。同じもの、最新版。
VitaやPS4でも同じものが出る
専用プラットフォーム向けの性能や安定性ってどうなの？
→性能改善は日々続けていて、進化している（プロファイラの画面）
SCE独自に検証目的に違うブランチで独自に手を入れているものがある。
が、そういう事をやっている。し、ここで大前さんの名前を出して入れてくれ、とアピール。
30万パーティクルを出して10〜11fps → SCEは 60fpsで動いている。
i-saintさんのシーンを使って最適化してる！
パーティクル追加、生存機関管理、描画などすべてGPUで完結させてる
PS4のパワーはまだまだつかえる、と主張。
CPUの処理負荷を意識して作る。
スクリプトは便利でイテレーションも早いが、規模の在る独自システムはネイティブプラグインで。
→アルゴリズムの検証と仮組みはスクリプト、性能を必要とする本番環境はプラグインで。
非同期コンピュートシェーダーの活用
使えるところはCSを使え、と。
非同期コンピュートシェーダー強い！
既にPS4でリリース済みゲームが在る。
stick it the man, counter spy
VITAからの移植が４日で終わった。
Never Alone
Unityの移植の注意
プラットフォーム固有のシステム(セーブデータなどの違い)
シェーダーの書き方の調整、PS4世代からセマンティックの運用がシビアになった
ムービー再生にはプラットフォーム専用のクラスが用意されているので、それを使うように調整
モーフィアス対応も簡単。
Oculus対応しているひとには、インターフェースの差はあるけれどすぐ対応できる。
試作は無料。
「こわくないのでぜひ、お気軽にアクセスしていただければと思います」
