「龍が如く」の高速デバッグ術 - jasst.jp · PDF fileJaSST’16 Tokyo 本セッションについて •KYUSHU CEDEC 2015 でのセッション •概要 • •発表資料

JaSST’16 Tokyo

「龍が如く」の高速デバッグ術～そびえ立つバグの山を踏破するための弾丸ワークフロー～

株式会社セガゲームス

第一CS研究開発部

アドバンスト・テクノロジー開発チーム

阪上直樹

JaSST’16 Tokyo

自己紹介

•関わったゲームシリーズ

• 「プロサッカークラブをつくろう！」

• 「プロ野球チームをつくろう！」

• 「龍が如く」

•ゲームプログラマから自動化や効率化の仕事に移行

• QAプログラマ？

• QAエンジニア？

• ビルド職人？

•アドバンスト・テクノロジー開発チーム

• 龍が如くエンジンのベース部分や各種ライブラリ・ツール等の開発

JaSST’16 Tokyo

本セッションについて

• KYUSHU CEDEC 2015 での同名セッション

• 概要

• http://kyushucedec.jp/session.html#06

• 発表資料

• https://cedil.cesa.or.jp/cedil_sessions/view/1398

今回は完全版です！

http://kyushucedec.jp/session.html#06



https://cedil.cesa.or.jp/cedil_sessions/view/1398


JaSST’16 Tokyo

本セッションのゲームタイトル

龍が如く０誓いの場所 PS3/PS4

PS Vita（無料アプリ）

2015年3月12日発売

龍が如く維新！ PS3/PS4

PS Vita（無料アプリ）


龍が如く極 PS3/PS4


複数プラットホーム×毎年リリース

JaSST’16 Tokyo

「龍が如く」を短いスパンで

リリースするための秘密は？

JaSST’16 Tokyo

ないです。がんばってるだけです。

でも…

JaSST’16 Tokyo

がんばる場所を限定

•ゲームの面白さ

•クオリティ

•ユーザーに感動体験を与えるための仕掛け

他にもやることはたくさんあるよ！

理想論じゃないの？！

JaSST’16 Tokyo

がんばらないために、がんばる

•自動化できるものは、ためらわず自動化

•作業の効率化を徹底して追求

•ワークフローの見直し

本セッションのテーマ

誰でもできる作業をクリエイターにさせない

JaSST’16 Tokyo

本セッションの用語定義

•デバッグ

• バグを修正する

• テストプレイを含まない狭義の意味

•テストプレイ

• プレイチェック

• バグ報告

• ゲームバランス(難易度/面白さ)の指摘

•赤字の用語

• 龍が如くチーム用語

JaSST’16 Tokyo

本セッションの概要

•前半

•高速デバッグ術

• 自動化

• Jenkins

•後半

• そびえ立つバグの山を踏破するための弾丸ワークフロー

• バグ管理

• Redmine

JaSST’16 Tokyo

高速デバッグ術

•自動化

• Jenkinsを使用

• パイプライン

• ビルド

• コンバート

• エラー検出

• ビルドエラー検出

• 静的コード解析

• 例外検出

• テスト

ビルドチェック

コンバート

絵や音楽の中間データソースコード

データのコンバートコンパイル・リンクエラー

コンパイラの警告

静的コード解析

ランタイムエラー（例外・Assert）

オートテスト

人力によるテストプレイ

ゲーム上で動作確認

Exe更新(Nightly Build)

中間データサーバ(TiVersion) Subversionサーバ

最終データサーバ(TiVersion)

最終成果物サーバ(TiVersion)

JaSST’16 Tokyo

Jenkinsによる自動化

• Jenkinsとは

• CI(Continuous Integration:継続的インテグレーション)ツールの一つ

• 日々の開発に必要なビルドやコンバートを自動化し、安定した開発環境を継続していくためのもの

•なぜ必要？

• ゲームの動作が安定していない状態では、実装したものをすぐに確認できないので作業が滞る

• ビルドが壊れた状態で放置すると、修正コストが増大し、他のバグを生む原因にもなる

JaSST’16 Tokyo

パイプラインの自動化

•ビルド

•コンバート

JaSST’16 Tokyo

ビルドの自動化 (1/2)

•ビルドとは

• プログラムをコンパイル・リンクして実行可能な形式に変換すること

• 自動で毎日ビルドした成果物は、Nightly Buildと呼ばれる

• Exe更新とは

• Nightly Buildの龍が如くチーム特有の呼称

• PS3/PS4/PS Vitaに加えて、それぞれのターゲットに対応したデバッグ用のWindows版の実行ファイルを定期的に生成

• Windows版もあることから、「Exe更新」と呼んでいる

JaSST’16 Tokyo

ビルドの自動化 (2/2)

ソースコード

Exe更新

(Nightly Build)

Subversionサーバ

最終成果物サーバ

(TiVersion)

コミット

コミット

自動化

PG

プログラムを書く

プロジェクト全員が

最新コードの動作を確認可能

TiVersionとは

• 龍が如くチーム独自のバージョン管理システム

• ファイルサイズの大きなものを高速でやり取り可能

Subversionとは

• バージョン管理システム

• 上書きによる先祖がえりを防ぐため

• サーバにアップロードすることをコミットと呼ぶ

プログラマ

JaSST’16 Tokyo

バイナリ管理を分けている理由

数KB

10MB～100MB

（1GBを超えも！）

テキストバイナリ

ソース(*.cpp)

絵

（3Dキャラ/背景/UI）

音楽

(BGM/効果音) ムービー

マージできなくていい！とにかく高速にやりとりしたい！

JaSST’16 Tokyo

パイプラインの自動化

•ビルド

•コンバート

JaSST’16 Tokyo

コンバートの自動化

背景モデルコンバート

背景モデルの中間データ

データのコンバート


Exe更新

(Nightly Build)

中間データサーバ(TiVersion)



(TiVersion)

コミット

コミット

D

背景モデルを作る

コミット

プロジェクト全員が

最新の背景モデルを確認可能

自動化

メールでエラーを通知

なぜ中間データを一括で

コンバートするのか？

• 各ターゲットに最適化

• 圧縮やパック

• 中間データをテキスト形式にすることで差分を取りやすく

自動化

デザイナー

JaSST’16 Tokyo


•実際にゲームを起動して、データが正しく読み込まれ、動作しているかを確認する簡易なテスト

1. ゲームをテストモードで起動

2. 背景データを読み込み

3. 背景データだけを描画

4. エラーが出ないことを確認し、終了して成功コードを返す

JaSST’16 Tokyo

パイプライン（ビルド・コンバート）の自動化 P

G D


コンバート

絵や音楽の中間データソースコード

データのコンバートコンパイル・リンクエラー


静的コード解析

ランタイムエラー（例外・Assert）

オートテスト

人力によるテストプレイ





最終成果物サーバ(TiVersion)

自動化

プログラマデザイナー

JaSST’16 Tokyo

エラー検出の自動化

•エラーの種類

• ビルドエラー

• 静的コード解析の指摘

• ランタイムエラー

• テストのエラー

•なぜ必要？

• エラーを見つけて報告するのもコスト

• 自動で不具合を見つけてくれるものは、どんどん使う

• 手動だと欠落しやすいデバッグに必要なデータ（ダンプやログ、スクリーンショット等）を自動収集

JaSST’16 Tokyo


•ビルドエラー

•静的コード解析の指摘

•ランタイムエラー

•テストのエラー

JaSST’16 Tokyo

ビルドエラー検出の自動化 (1/4)

PS3

Debug

Release(デバッグ機能有)

Release(デバッグ機能無)

手動で確認するのは大変！

PS4

Debug



PS Vita

Debug



Windows

(32bit/720p)

Debug



Windows

(64bit/1080p)

Debug



Windows

(32bit/960x544)

Debug



自動化

自動化

自動化

自動化

自動化

自動化

≒

≒

≒

JaSST’16 Tokyo


• Exe更新とは別にSubversionサーバを監視して、コミットごとにビルドが壊れていないかチェックを行う

•ビルドが壊れていたら、Jenkinsからメーリングリストにメールを自動送信

•ビルドエラーが出たら即時直すルール

• ビルドエラーは出さないことが望ましいが、ビルド構成が多く、各自がすべてを確認してコミットするのは無駄が多いため

•ビルドは分散ビルドを使用

• PCの台数を増やして高速化

JaSST’16 Tokyo


•コンパイラの警告は、エラー扱い

• ビルドエラーになるので、即時修正が必要

• コンパイラの警告レベルは最高に設定

• 例外的に使いたいものは、設定で除外するか#pragmaで局所的に対応

• まずは警告をゼロにするところから

警告はエラーです

JaSST’16 Tokyo


•ビルドが壊れた状態を短縮するためには

• 声かけが一番効果的

• チェック結果を分かりやすく表示する

• ビルドチェック待ちページ

このリストから

自分の名前が

消えたら帰宅可能

unused variable

警告はエラー扱い

JaSST’16 Tokyo






JaSST’16 Tokyo

静的コード解析の自動化

•静的コード解析とは？ • プログラムを実行せずにソースコードを解析し、不具合やその可能性となるものを検出するツール

•なぜ必要？ • すべてのコードを人力でレビューするのは大変

• 不具合の芽を先に摘んでおく

•静的コード解析ツール • 使用ツール

• Coverity（精度が高い/有償） • Visual Studioのコード分析（Visual Studioの標準機能） • Cppcheck（オープンソース）

• 使用ツールは、管理できるなら多ければ多いほどいい

• Jenkinsを使って毎日自動的に解析して、結果をメールやチケットでフィードバック

JaSST’16 Tokyo






JaSST’16 Tokyo

ランタイムエラー報告の自動化

•エラー送信（クラッシュレポート機能の龍が如くチーム用語）

ゲームやツール実行中に

例外発生！ネットワークドライブ

デバッグに必要な情報を自動収集

• ダンプ

• ログ

• コールスタック

• スクリーンショット … etc

メール送信

• ダンプ表示batのURL

• ログ表示batのURL

• コールスタック

• リビジョン

• ターゲット

バグ管理システム(Redmine)

JaSST’16 Tokyo

エラー送信の実装例 (Windowsの場合)

• C++ • 未処理例外のキャッチ

• SetUnhandledExceptionFilter

• コールスタック • StackWalk

• C# • 未処理例外のキャッチ

• System.Windows.Forms.Application.ThreadException • AppDomain.CurrentDomain.UnhandledException • System.Threading.Tasks.TaskScheduler.UnobservedTaskException

• コールスタック • Environment.StackTrace

• ダンプ出力 • MiniDumpWriteDump

• C#ではアンマネージド・コード呼び出し

• ダンプを開くときは、ダンプファイル(.dmp)以外に、exeファイルと対応するpdbファイルが必要

JaSST’16 Tokyo

ダンプを開いた例(C#)

JaSST’16 Tokyo






JaSST’16 Tokyo

夜間の開発用PC(100～200台)

最新のゲームを起動して

モンキーテストを行う

テストの自動化 (1/4) • モンキーテストとは

• ランダムに擬似パッド入力を行うテスト手法

• オートテスト（モンキーテストの龍が如くチーム用語）

PC

各PCの設定を

一括管理

• 開始シナリオ

• ターゲット

• 使用デバッグ機能

明朝出社

• バグ報告

• 目視でのチェック PC PC

PS4 PS3 VITA

JaSST’16 Tokyo

テストの自動化 (2/4)

• Excelファイルに設定を記述

PC名開始シナリオ

条件

JaSST’16 Tokyo


•各PCでオートテストを実行

オートテストクライアントを実行

設定ファイルから

iniを生成

TiVersionから

最新のexe更新を取得

ゲームを自動起動

(iniファイルのシナリオ/条件)


(TiVersion)

JaSST’16 Tokyo


•テストで検出されたバグを見逃さない • エラー送信

• ログ出力

• 動画撮影

•人力で出せないバグの検出 • 1/60秒単位の特定のパッド入力で発生

• 長時間同じ動作を繰り返すことで発生

•人力で出せないバグを見つける必要があるのか？

• 数十人では出ないバグも、数十万人がプレイすると出てしまう可能性がある

• 人力のチェックはリソースに限りがあるため、バグを自動で検出する仕組みは、大規模ゲーム開発には欠かせない

JaSST’16 Tokyo


各コンバート

高速デバッグ術（自動化）のまとめ絵や音楽の中間データソースコード

データのコンバートコンパイル・リンクエラーメール


メール

メール

静的コード解析メール、チケット化

ランタイムエラー（例外・Assert）エラー送信

オートテストエラー送信

人力によるテストプレイバグ報告

ゲーム上で動作確認エラー送信メール




最終成果物サーバ(TiVersion) 成果物を確認

自動化！メール

JaSST’16 Tokyo

そびえ立つバグの山を

踏破するための弾丸ワークフロー •バグ管理

• Redmineを使用

• バグ報告の掟

• バグ管理システムの導入の歴史

• バグ管理システムの問題と解決

JaSST’16 Tokyo

バグ報告の掟

なんかおかしいんだけど・・・

PG

ふーん

（ｶﾀｶﾀｶﾀ…）

JaSST’16 Tokyo

バグ報告の掟（破り）

ちょっと

見て見て！うう・・・

なんとかしてプログラマにバグの現場を見せる！

JaSST’16 Tokyo

バグ管理システムの必要性

•口頭でのやり取りは、数人程度が限界

•バグ管理システムが必要な場合

• 数百人規模のプロジェクト

• それぞれが別の場所で作業している

JaSST’16 Tokyo

バグ管理システムの導入の歴史

•口頭だけ

•紙で管理

• Excelで管理

•オリジナルツールで管理

• Mantisで管理

• Redmineで管理（現在）

JaSST’16 Tokyo


•口頭だけ

•紙で管理

• Excelで管理


• Mantisで管理


JaSST’16 Tokyo

紙でバグ管理 (1/2)

バグ箱報告者

発生日時

阪上直樹

2016/3/8

14:00

ラスボスのやられ演出中のモーションブラーでフリーズしました。

バグ報告

済

担当者に振分

修正

修正NG

PG

バグ１つに紙１枚（チケット）違うバグを１枚にまとめない！

JaSST’16 Tokyo

紙でバグ管理 (2/2)

• メリット • バグの見える化

• 各自の記憶に頼らない

• 誰が何個バグを抱えているのか

• アナログならでは

• バグの報告者・担当者間のコミュニケーションがスムーズ

• 少人数では一番高速

•デメリット • かかわる人数が増えると、チケットの管理が煩雑

• チケット全体を管理できない

• 総数が分からない

• バグの傾向が分からない

• 各バグのステータス（対応状況）が分からない

• どのバグから手をつけていいのか分からない

JaSST’16 Tokyo


•口頭だけ

•紙で管理

• Excelで管理


• Mantisで管理


JaSST’16 Tokyo

Excelでバグ管理

※Office 365がなかったころの話

• メリット

• 情報のデジタル化

• 共有設定にして、１ファイルですべてのバグを管理

•デメリット

• 誰が編集したのか分からない

• 共有設定にすると、ファイルがたびたび壊れる

• 部外とのやり取りが煩雑

• マージ作業が発生してしまう

• 情報が漏洩しやすい

• バグのステータスが分からない

JaSST’16 Tokyo


•口頭だけ

•紙で管理

• Excelで管理


• Mantisで管理


JaSST’16 Tokyo

オリジナルツールでバグ管理

• メリット

• サーバで一元管理

• ツールの開発者が社内にいるので、要望を追加しやすい

•デメリット

• ツールの属人化

• 開発者がいなくなったらメンテナンスできない

• ツールの学習コスト

• 社内システムなので、ツールに慣れてもらう時間が必要

JaSST’16 Tokyo


•口頭だけ

•紙で管理

• Excelで管理


• Mantisで管理


JaSST’16 Tokyo

Mantisでバグ管理(1/2)

• Mantisとは

• バグ管理システム(BTS)

• Webブラウザでアクセス

• オープンソース

JaSST’16 Tokyo

Mantisでバグ管理(2/2)

• メリット

• サーバによる一元管理

• スクリーンショットやログファイルを添付できる

• コメント入力やステータス、優先度を設定できる

• 有名なツールなので、学習コストを削減できる

•デメリット

• バグ以外の管理には不向き（タスクなど）

JaSST’16 Tokyo


•口頭だけ

•紙で管理

• Excelで管理


• Mantisで管理


JaSST’16 Tokyo

Redmineでバグ管理 (1/5)

• Redmineとは

• バグを含めた課題管理システム

• Webブラウザでアクセス

• オープンソース

JaSST’16 Tokyo


•タスクも管理するためにMantisからRedmineに移行

• あれがない、これがない、使いにくいと言われる

• 代替手順を提示して、なんとかツールに慣れてもらう

• どうしても必要と思われる機能は、プラグインとして実装

• リマインダー送信

Mantisのリマインダー送信

見た目もそのまま

Redmineに移植

JaSST’16 Tokyo


• メリット

• サーバによる一元管理

• スクリーンショットやログファイルを添付できる

• コメント入力やステータス、優先度を設定できる

• 有名なツールなので、学習コストを削減できる

• APIやプラグイン等の拡張機能が豊富で、開発も活発

• タスクも管理できる

•デメリット

• 自由度の高いツールなので、運用ルール作りが必要

• プラグインを多用すると、保守・メンテナンスコストが高くなる

JaSST’16 Tokyo


バグ報告

担当者に振分

修正

修正NG

PG

新規

確認済み差し戻し

バグのステータスの一例

確認待ち

ワークフローは紙と同じ！

JaSST’16 Tokyo


•なぜ「確認待ち」なのか？

• 「修正完了」ではない？

• バグ修正を実装した時点で、チケットは終わっていない！

• 修正を確認して、はじめてチケットは完了する。

• ステータス名は、見ただけで次に何をしなければならないかがすぐ分かるのがよい

JaSST’16 Tokyo

ツールを使えば、すべて解決？

•バグ管理システムの問題点 • Excel使いたいよ・・・の声

• バグ報告の問題点

• バグのワークフローの問題点

• 各ツールにプロジェクトの情報が分散

もちろん、そんなことは無いです。

JaSST’16 Tokyo

バグ管理システムの問題と解決

• Excel使いたいよ・・・の声

•バグ報告の問題点

•バグのワークフローの問題点

•各ツールにプロジェクトの情報が分散

JaSST’16 Tokyo

Excel使いたいよ・・・の声 (1/2)

• RedmineにExcelのインポート＆エクスポートを追加

•数百個のタスクを一括で登録したい

• redmine_importプラグインを導入

• Redmine 3.2で標準機能に追加

• Excelで見たい人にチケット一覧をxlsファイルに変換

• redmine_xls_exportプラグインを導入

JaSST’16 Tokyo

Excel使いたいよ・・・の声 (2/2)

•インポート用のテンプレートを作成

• Redmine REST API経由でトラッカー別に自動生成

• Jenkinsで定期的に更新

• カテゴリやメンバーの追加に対応するため

JaSST’16 Tokyo






JaSST’16 Tokyo

バグ報告の問題点

•必要な情報を入力するのは結構大変

• テストプレイがメインの仕事でない時に、バグ報告を怠りがちになる

•ログの添付を忘れやすい

• 手動だと、必要な情報を入力・添付し忘れる

•入力ミスも発生する

• リビジョン番号が違う

• ターゲットの選択を間違える

JaSST’16 Tokyo

バグ報告に必要な情報

基本情報

• 原因

• 結果

• 再現率

• 重要度

• カテゴリ

• 報告者

• ターゲット

(Win/PS3/PS4/VITA)

• 言語

(日本語/中国語)

• リビジョン

添付ファイル • ダンプファイル

• デバッグログ

• 使ったデバッグ機能（設定ファイル等）

• スクリーンショット

• セーブデータ

龍が如く独自

• プレイヤーキャラ

(桐生/真島/秋山…)

• ステージ

(神室町/蒼天堀…)

• プレイヤーの座標

• シナリオ進行度

• 時間帯(昼/夜)

• 天候(晴/雨/雪)

自動入力できる！

JaSST’16 Tokyo

バグ報告の自動化

•どこでもバグ報告とは

• Redmine REST APIを使用して、専用アプリ経由でゲームアプリから直接Redmineにチケット登録

• 全ターゲット(Win/PS3/PS4/PS Vitaに対応)

• エラー送信からも直接バグ報告が可能

• デバッグ機能がないと使えない

JaSST’16 Tokyo

どこでもバグ報告 (1/3)

デバッグメニューからどこでもバグ報告をクリック！

JaSST’16 Tokyo


自動入力

自動撮影＆自動添付

JaSST’16 Tokyo


自動入力

自動添付

JaSST’16 Tokyo

バグ報告自動化による効果どこでもバグ報告

使用件数

バグの

総数

龍が如く維新！ 9,338件 17,448件

龍が如く０誓いの場所 6,307件 12,955件

龍が如く極 1,925件 4,799件

３タイトル(9,338件+6,307件+1,925件) X 10分(短縮時間/件)

= 約3,000時間を削減

バグ報告の質が均一化して、精度も向上

テストプレイヤーは、バグ探しに専念！

クリエイターは、バグの修正・バランス調整・クオリティの向上に専念！

JaSST’16 Tokyo






JaSST’16 Tokyo

バグのワークフローの問題点

•修正したものがいつ反映されたか分からない

•バグチケットに対して、どういう修正が入ったのか分かりにくい

Redmineと各システム・ツールを連携して

ワークフローを自動化

JaSST’16 Tokyo

Redmine

Redmineとパイプラインの連携 (1/4)





Exe更新

(Nightly Build)




(TiVersion)

コミット

コミット

D

背景モデルを修正

コミット

報

修正したものはいつ反映？

新規

確認待ち

８時間ごと

1日3～4回

明日くらいかなぁ・・・修正確認が迅速にできないよ！

デザイナー

バグ報告者

JaSST’16 Tokyo

Redmine






Exe更新

(Nightly Build)




(TiVersion)

コミット

コミット

D

背景モデルを修正

コミット

「確認待ち」は

すぐ確認が可能！

新規

確認待ち

８時間ごと

1日3～4回

コンバート待ち

Exe更新待ち

デザイナー

報

バグ報告者

♪ ♪

JaSST’16 Tokyo


「確認待ち」になったら

確実に修正確認が可能

コンバート予約とは

コンバートの種類を選択して

予約を作成

JaSST’16 Tokyo

RedmineとSubversionの連携 (1/2) •バグチケットに対して、どういう修正が入ったのか分かりにくい

→Subversionのコミットログにチケット番号を入力

バグチケットに対して、どういう変更が入ったのか一目瞭然！

JaSST’16 Tokyo

RedmineとSubversionの連携 (2/2)

ソースコード

Exe更新

(Nightly Build)

Subversionサーバ


(TiVersion)

コミット

コミット

PG

プログラムを修正

Redmine

新規

確認待ち

Exe更新待ち

「確認待ち」は

すぐ確認が可能！

1日3～4回

プログラマ

報

バグ報告者

♪ ♪

JaSST’16 Tokyo






JaSST’16 Tokyo

各ツールにプロジェクトの情報が分散

•様々なツールを行き来して、作業が煩雑になる

•バグとタスクの管理を分けると、チケット全体の優先順位が把握できなくなる

Redmineに情報を集約

JaSST’16 Tokyo

RedmineとCoverityの連携 (1/2)

• メリット

• バグやタスクと静的コード解析の不具合を一括管理

• Redmineのワークフローに統一して作業を効率的に

•連携方法

• RedmineとCoverityのそれぞれのAPIを使った同期ツール

• セガゲームス開発技術部の粉川氏制作

JaSST’16 Tokyo

Coverity(全自動)

Redmine

RedmineとCoverityの連携 (2/2)

新規の不具合検出

Coverityチケット生成

担当者を振り分け

不具合の修正

[確認待ち] 再解析(次の日)

チケット終了

[確認済]

Coverity不具合

チケットを自動作成

[新規]

Coverityの解析

１日１回(Jenkins)

不具合の修正確認

NG

OK

JaSST’16 Tokyo

そびえ立つバグの山を踏破するための

弾丸ワークフロー（バグ管理）のまとめ

• Redmineを使ってバグを一元管理

• バグ報告に必要な情報は自動入力

• どこでもバグ報告

• バグ管理システムと他のシステムの連携 • ワークフローを自動化

• コンバート予約

• Subversionと連携

• Redmineにプロジェクトの情報を集約

JaSST’16 Tokyo

本セッションのまとめ

•大規模＆高速リリースの秘密は無い

• 地道な自動化・効率化

•自動化

• パイプラインの自動化

• エラー検出の自動化

• バグ報告の自動化

• ワークフローの自動化

• ためらわず、小さなことから、こつこつと

•効率化

• 開発チームの規模や環境・風土に適したツールを導入

• 情報を１つの場所(Redmine)に集約

JaSST’16 Tokyo

最後に

私(QAプログラマ)がいないと

龍が如くは毎年出せない！

JaSST’16 Tokyo

参考資料

• 「10ヵ月でHDゲームを開発する方法～龍が如くを支えたテクノロジ～」（CEDEC 2010）

• 前半の高速デバッグ術の関連情報

• TiVersion

• エラー送信

• オートテスト etc..

• 概要 • http://cedec.cesa.or.jp/2010/program/PG/C10_P0064.html

• 講演資料(CEDiL) • https://cedil.cesa.or.jp/cedil_sessions/view/324

http://cedec.cesa.or.jp/2010/program/PG/C10_P0064.html

http://cedec.cesa.or.jp/2010/program/PG/C10_P0064.html



Documents

「龍が如く」の高速デバッグ術 - jasst.jp · PDF fileJaSST’16 Tokyo 本セッションについて •KYUSHU CEDEC 2015 でのセッション •概要 • •発表資料