:-): CEDEC 2010 - CESA Developers Conference 3 日目

石井裕(マサチューセッツ工科大学)

Tangibleのひと[ 20070209#p03 ]

アラン・ケイ「未来は自分で作る」(ref. Alan Kay - Wikiquote )

遊び/娯楽
- 自分の人生では娯楽とはあまり接点がない
- でも身近なところに娯楽はあることに気づいた
- テトリス
  - これは中間管理職の悲哀だと思っている :-)
- ラプラス - Wikipedia
  - 彼については知ってるよね？
  - でも最近は似たようなゲームがあることを知った :-) ラブプラス

人生/真剣勝負
- 卓球を 30 年やってる
- 卓球は真剣勝負だ
- タモリさんは遊びだと言ってたけど :-)
- ラケットを 30 年使っていると私の体の痕跡が出来る
- その痕跡を計測してみるといい
- それは自分の体と同化するコントローラーである

Physical Design Media
( Physical Digital? Media だった？ )
- 物体を操作する
- 直感的であり
- 見れば分かるし
- 触れば分かるし
- 相手に伝わる
- デジタルの情報
- すぐに拡散できるし
- 計算機向けだし
- 物体とデジタルを簡単に行き来できるようにしたい

ビジョン
- vision => ここにフォーカスする
- user's need => 移り変わりが激しい
- Technic => すぐに廃れる

Tangible/存在
- 触れる
- 安心感
- そこに存在していること
- 目で見て分かる
- 手で分かる
- 自分の筋肉で分かる

感動
- I/O Brush: The World as the Palette
- 素材だけ用意する
- これだけを子供に渡すと勝手に遊び方を創造していく

コラボレーション
- 分業ではない
- アーティスト、デザイナー、エンジニアが各々の言語を相互に理解すべき
出る杭は打たれる
- 出過ぎた杭は打たれない

飢餓感
- 飢餓状態を知っておくといい
- 自分の命を脅かすモノとそうでないモノが見分けられる
屈辱感
- 悔しいという思いを燃料にする
- プライドを持つ

未来
- 2200 年の未来のひとたちに何を残したいか？
- どのように自分のことを思い出してもらいたいか？

「サカつく」のサッカー試合ＡＩシステム

安藤毅(セガ)

サカつくとはなんぞや

サッカーチーム運営シミュレーション
試合ではシミュレーションのみ
アクションしない
監督は直接操作しない
間接的な指示のみ
見てるだけ
リアルタイムシミュレーション

シリーズごとのシミュレーション変遷

完全オーサリング方式
- あらかじめオーサリングしておく( オーサリングとは【authoring】 - 意味/解説/説明/定義： IT用語辞典 )
- 試合のダイジェストを見るような感じになる
- メリット
  - クオリティが高いシーンを作れる
  - AI の処理が見栄えに影響しない
- デメリット
  - 同じシーンばかり再生される
  - 展開が読める
- 対策
  - シーンを増やした
  - しかしそのぶん作業工数が増加した

完全リアルタイム方式
- アクションゲームと同じアプローチ
- メリット
  - 自由度が高い
  - 先が読めない。サッカーの醍醐味を楽しめる
- デメリット
  - チーム力 → 物理挙動 → 結果
  - 物理挙動を挟むのでバランス調整が困難
  - 処理速度向上に限界がある

折衷方式
- オーサリング方式とリアルタイム方式のいいとこ取り

システム概要

DSなので制約が強い
「どうせなら球際だけでも美しく」
「字余りですね :-) 」
処理能力に限界なし
ほぼリアルタイム
- それほどリアルタイム操作じゃない
- 監督の指示出してから 2, 3 手あとに反映される

プレイセット

同一局面、同一プレイ選択から分岐し得るシーンセット
- オフェンス目線
- 行動4パターン
  - 大成功
  - 成功
  - 失敗
  - 大失敗
- 評価関数で行動を決定
- 結果を保存しつつそのシーンを再生

局面計算の結果
- 局面計算結果を構造体へ入れる
- それを試合ヒストリバッファへ格納していく
- バグの再現性が高くなる
- デバッグが楽になった

質疑応答

プレイセットのチューニングどうやった？
- 評価関数のパラメーターを調整した

『ゲームのお仕事』業界研究フェア 2010ゼロからゲーム開発者になるための職能の身に付け方

CEDEC のうち学生向けプログラムに参加してみた。当然ながら周囲は学生ばかりであり若者が多く、つまりオッサンは私ひとりかー。まあ業界外の人間として業界のことを知るために来たので「業界研究」としては正しいのである。

歴史

18歳
- スクウェア入社
- 聖剣伝説2: プログラマ
- FF11: リードプログラマ
現在
- ゼペット
- 社員は自分一人

15 - 17 歳
- X68000 買った
- 本も買った
- たくさん読んだ
- でも結局何も作らなかった
- ネット上でクリエイターたちに出会った
- 「それだけやって何故なにも作らないんだ？」
- ゲームをつくりはじめた
- ゲームもたくさんプレイした

心構え
自分が就職したい会社のアプリ/ゲームよりも上のものを作ろうぜ
かなり自信になるぜ

2,3 年でゲーム 2, 3 個

何か 1 つ 1 人で完成させておく
チーム開発するときになってもその経験が役立つ

ナーシャ・ジベリ伝説
- FF3 の hack とか伝説あるけど、それはあまり重要じゃない
- 彼はほんとに地道にコツコツと作業した
- それが凄いんだ

リッジレーサーシリーズを作ったときの開発プロセスについての話題。ナムコ社内で作ってると思ってたけど外注だったんだ。全体の人数は明かされなかったけど「プログラマが 10 人を超えると云々」と言っていたのでたぶんプログラマ 20～50人くらいであり、下記の人口比からすると全体で 100 人～になるんじゃないかしら。これくらいの規模になると「根性でがんばればなんとかなる」というレベルはとっくに過ぎてるのでソフトウェア開発プロセスとしてちゃんとやらないと破綻する。いやこんな人数経験ないけどね。私は最近の仕事は研究開発な仕事であり【お察し下さい】なので、こういうしっかりした話を聞いたら感動し興奮してしまった。

ローンチタイトル

PS: リッジレーサー
PS2: リッジレーサーV
PSP: リッジレーサーズ
XBox360: リッジレーサー6
PS3: リッジレーサー7

リッジレーサーズ、リッジレーサー6、リッジレーサー7 を「近代リッジレーサー」と呼ぶこととする。ここではこの「近代リッジレーサー」について述べる。

コンセプト

内的要因
- なぜこの製品を作るのか
- ターゲットは誰か？
- いくら売り上げるのか？
外的要因
- 「新しいゲーム機を買って良かった」と思わせるゲームにする

開発チーム構成人口比

プロデューサー
ディレクター
プランナー: 10%
プログラマ: 35%
デザイナ: 40% 新しいハードのスペックを把握する/ハードの描画能力を見極める
サウンドクリエイター: 15%

組織設計とマネジメント

プログラマの場合

機能別に独立性が高くなるように分離
班を作る
- 骨となるゲームシステム
- ネットワーク対応
- ストリームデータ処理
- 描画処理
- 物理運動

班ごとにリーダーを設置し、専任させる。解釈はリーダーに任せる。

マネジメント

マイクロソフトプロジェクト MSP Microsoft Office Project
※ただし使っていたのは 2010 ではない
- パフォーマンスなどが妥当だった
- 他に良いものが無かった
- 使い勝手はそれほど良くない
最初はガントチャートエディタとして使用
のちに管理ツールとして使用
RR7 のときは MSP server と MSP web access を使用した

スケジュール

プロジェクトの最初にスケジュールを立てる
1 つのタスクは 5 日以下
- これくらいの大きさじゃないと 1 日の終わりにタスクの進捗を把握できない
- 日単位のほうがタスクの大きさを把握しやすい
- 「1週間」だと個人の感覚によりバラツキがある
- 「時間」単位まで細かくは分からない
作業がうまくいったりいかないときもあるけど「普通にやればこれくらいだろう」という見積りをさせる
成果物は作業ごとではなくマイルストーンを設ける
- この日までに○○が出来上がってるはず
マスターアップまで線を引く
- 完璧じゃなくてもいい
- 8 割くらいでも埋めてしまう
必要になる作業は全て書き出す
- 調査
- 機能作成
- デバッグ
- マスター後の出し直し
- 有給休暇
- 特許調査
- 広告用素材対応
  - この辺はカンで 3 日くらいで固定しておく
1日は 8 時間
- 休日有りとする
「この機能はあの人じゃないと出来ない」はウソ
- 十中八九他の人でも出来る
- 1割くらいはたしかに出来ない
「自分がやるほうが早い」もウソ
スケジュールは遅れるものであるという前提
- バッファを持たせる
- だいたい6ヶ月で1ヶ月遅れる
- デバッグ期間を食いつぶしてはならない
- この段階で問題が見つかったらスケジュールを再調整

プログラマチーム内で管理専任を確保
最低でも 1 週間に 1 度はスケジュール更新しておく
作業報告は日単位で報告させる
- 進捗は % で報告させてはダメ
- 遅れを認めたくない心理が働く
- 「80 %」以降進まなくなる
- 物理量を報告
- 何 h やった？何日やった？
新規作業が発生したら必ずタスクを追加させる
- 必ず遅れるのだから
- 遅れた理由を知るため
致命的なスケジュール遅延はタスク配分を修正する
- 判明した時点でやる
基本的に残業しない
- 最初から消耗戦させない

実際のガントチャート
(ここでとあるプロエジェクトで使用したガントチャートが表示される。詳細はボカシ )
- 見積りと実績はだいぶ異なる
- 着手順はバラバラになった
- タスクは増加した
1 プロジェクト
- 23 ページ
- 1300 行くらい

ローンチでのコーディング

ハード構成から性能を予測する。分かる範囲で

CPU
GPU
メモリ
バスの構成
転送レート
....

優先度順位づけ 3 種類
- 必須
- オプション(努力目標)
- 野望

ハード開発
- 描画、音声以外はどれもだいたい同じなのでコード書いておく
- 描画は情報を 集めながら 設計→コーディング
- 最後に残るところはチューニング
- その手前まで作業しておく
最低限の構成(「必須」)からひとつずつ追加しておく
- 少しずつクオリティを上げていく

細々としたこと

自分たちで作っていないソフト(ミドルウェアなど)は動いているモノを当てにする
- 動いている物が入手できた時点での性能を考える

開発チーム内では:
- プランナーが 1 番
- プログラマは出来ない仕事は出来ないと言うこと

全体

プログラマの作業は「全員が違う作業をしている」
- 作りかけの物は引き継ぎづらい
- なのでスケジュールを最初に作っておくことが重要になる
出来ないことは出来ないのである
- 「やってダメだった」は物凄くムダである
- 研究開発ならそれでいいけど、そういう仕事じゃない
やらねばやらないことをやる

デバッグのコントロール

バグ件数を計測する
- 収束する時期を見極める
- いつデバッグをやめるか見極める

torne(トルネ)に注ぎ込まれたゲーム制作現場のノウハウ

西沢学(ソニー・コンピュータエンタテインメント)
石塚健作(ソニー・コンピュータエンタテインメント)

ゲーム制作のうちおもに UI についての説明だった。最後のほうに技術的なことも説明していたけどほんのちょっと。むしろ自己紹介とトルネの紹介が長過ぎる。関わったタイトルについての話を聞きに来たんじゃない。

ゲームデザインのノウハウ

PS3らしいレコーダー
- 圧倒的に快適なUI
- PSPとの連携
- ネットワークを利用した新しい体験

圧倒的に快適なUI

マニュアル不要な使いやすさ
気持ちイイ応答
- 操作のステップを減らす
効果的な演出
- アニメーション
- サウンド

→操作すること自体が楽しい

マニュアル不要な使いやすさ

○×ボタンの意味を統一
十字キー○×のみで操作
画面中央下に情報を表示
左から右へ流れるように操作させる
選択は上か下のみ
迷子にならないように
- 迷ったらとりあえず×を連打すればトップに戻れる
できるだけ中央に表示する
- 左右に表示すると目が疲れる
必要な情報を際立たせる
- 不要な情報は隠す

気持ちイイ応答

いつでも応答する
- ブロッキングしない
- 1/60 フレームで操作を受け付ける
- ゲームと同じ
直前の状態を覚えておく
- 自分がたどった軌跡を覚える
よく使う機能を優先
画面によってキーリピート速度を調整

効果的な演出

リビングに合う清潔なデザイン
長時間楽しめるようにする
- レコーダーなので長時間起動させているので
- 常に何かを動かしておく
SEによるフィードバック
- スピード感を上げるような音
待ち時間の軽減
- スプラッシュみたいな

ゲームのチューニングと同じ工程

クラッシュアンドビルド
- 作っては壊し作っては壊し
- インクリメンタル(?)
スピード感重要
ゲームのUI制作の基本をトルネへ応用
- 機械との対話であることには変わりない

技術面

スケジュール
- 1年未満
- ハードが出来上がる前からソフトウェアをつくり始めた
- 2009/10 から結合
- クラッシュアンドビルド
構成
- アプリケーションモジュール
  - 通常のゲームと同じ構成
- サーバー
  - なんとたったの 500KB !
  - スレッド 2 つ

番組表
- 文字単位でのレンダリング
- 文字数は多い
- でも文字種はけっこう少ない
- 文字テクスチャ 1 枚だけ用意
- 4096 x 4096
- インデックス(?)で文字選択
- キャッシュしておく

次期アイドルマスターグラフィクス＆アニメーションプログラミングプレビュー

前澤圭一(バンダイナムコゲームス)
竹内大五郎(バンダイナムコゲームス)

アイドルマスターはせいぜい塊魂の一致団結くらいしか知らないけどなんとなく来てみた。

1 と 2 の差異

トゥーン
1
- 3段階のトゥーン
- ハイライトを重ねて
- ソフトシェーディング
- view 追従光源
  - ステージの上でアイドルを包みこむ光
2
- 髪ハイライト
- 照り返し
- センシティブトゥーン!
  - 胸のふくらみ等がよりリアルになったよ!

ステージ
- 動くモノ
  - 汽車
- 揺れるモノ
  - 波打ち際
  - ヤシの木
- パーティクルエンジンを一新
  - 紙吹雪
  - 蒸気
- ステージ上はすべてが見えるようにする
  - 暗いところに行ったらアイドルが見えなくなってしまう!

キャラと背景
- ブルーム
- フレア
  - ステージ上の床からの明かり
- 被写界深度
- ソフトフォーカス

コミュ
- 2人以上立ったときにセルフシャドウが不自然になる
- 3D的に正しくない
- キャラごとにレイヤー
- セルフシャドウは不自然だけどキャラの見栄えを重視した

揺れモノ

髪
アクセサリー
スカート
胸
質感、躍動感
プログラムで実現

お下げ髪を作ろう
- 高槻やよいさん(14)
- キャラはスキニング
- 骨の位置を動かす
- 揺れる点と点をノードとして扱う
- 速度 x 減衰係数 + 位置 => 次の位置
- 骨の長さは変わらない
- 根本の位置は揺れない
- 重力と風の影響
- 親ノードから見て元の位置に引っ張る

ロングヘアを作ろう
- おさげ x N と考える
- 骨を複数用意
- 隣の骨との距離を保つようにバネを入れる
  - これにより広がらなくなる

めり込まないようにする
- 髪やスカートは手足にぶつかる
- 髪に球、体にも球
- 腕や胴体を円柱で囲む
- 球が円柱に衝突したら弾かせる
- 円柱の継ぎ目を球で埋める
- 基本は球

[ツッコミを入れる]


		2010年 9月
日	月	火	水	木	金	土

ヨタの日々

2010-09-02 :-)

_ [CEDEC]CEDEC 2010 - CESA Developers Conference 3 日目

Defying Gravity: The Art of Tangible Bits 重力に抗して：タンジブルビット