CEDEC2014 「ライブラリを作ってはいけない ～それでも作りたいあなたへのアドバイス～」
- 1. ライブラリを作ってはいけない ∼それでも作りたいあなたへのアドバイス∼ 2014/9/4 @ CEDEC2014 株式会社バンダイナムコスタジオ 黒畑喜弘 2014/10/11 ・講演当日に口頭で説明した内容を追加してあります。(CEDiL提出用)
- 2. 自己紹介 • 1998年 株式会社ナムコ 入社 • 1999年 蚊取り大作戦 (ナンジャタウン) • 2000年 ディグダグ (パチスロ) • 2003年 ミスタードリラー ドリルランド (GAMECUBE) • 2003年∼2004年 ドンキーコンガシリーズ (GAMECUBE) • 2005年∼2006年 リッジレーサー6, 7 (Xbox360, PlayStation3) • 2006年∼ 社内サウンドライブラリ NUSound アーキテクト
- 4. リッジレーサー6 Love FOOTBALL リッジレーサー7 鉄拳5 DARK RESURRECTION 鉄拳5 DARK RESURRECTION ONLINE ビューティフル塊魂 エースコンバット6 鉄拳6 ソウルキャリバー レジェンズ スマッシュコート3 ファミリースキー ファ ミリージョッキー もじぴったん プチプチ ソウルキャリバー4 テイルズオブヴェスペリア Galaga Legions スカイクロラ ファ ミリースキー ワールドスキー＆スノーボード もじぴったんWiiデラックス太鼓の達人 鉄拳6 BLOODLINE REBELLION NARUTO ナルティメットストーム のびのびBOY ミスタードリラーワールド 戦場の絆ポータブル マッスル行進曲 突撃！合戦 スタジアム 塊魂 TRIBUTE ソウルキャリバー Broken Destiny 機動戦士ガンダム戦記 テイルズオブヴェスペリア TANK!TANK!TANK! 鉄拳6 太鼓の達人 Wii ドドーンと2代目！ テイルズオブグレイセス ガンダムビューカイブ 鉄拳6 デッド ストームパイレーツ テイルズ オブ ファンタジア なりきりダンジョンX ACE COMBAT X2 ジョイントアサルト 機動戦士ガン ダム エクストリームバーサス DEADHEAT マクロストライアルフロンティア BIG3 GUN SHOOTING(デッドストームパイレー ツ) NARUTO ナルティメットストーム2 体で答える新しい脳トレ テイルズオブグレイセスエフ 太鼓の達人Wii みんなでパー ティ☆３代目！ エコドライブ パックマン MAXIMUM HEAT ドラゴンボール ZENKAIバトルロイヤル ギャラガレギオンズ DX 太鼓の達人ぽ∼たぶる DX テイルズオブエクシリア劇場版マクロスF サヨナラノツバサ Hybrid Pack GO VACATION 太鼓の達 人 太鼓の達人Wii 決定版 機動戦士ガンダム エクストリームバーサス 湾岸ミッドナイト MAXIMUM TUNE 4 NARUTO疾風伝 ナルティメットストーム GENERATION .hack//VERSUS テイルズオブエクシリア2 デッドストームパイレーツ(立体視版) PAC-MAN Championship Edition のびのびBOY コトバシる アイドルマスター2 戦場の絆 Rev.3 鉄拳タッグトーナメント2 アイドルマスター2 アイドルマスター グラビアフォーユー! VOL.2 鉄拳 HYBRID リッジレーサー 塊魂 ノ・ビ∼タ アイドルマ スター グラビアフォーユー! VOL.3 アイドルマスターモバイルi 鉄拳タッグトーナメント2 鉄拳タッグトーナメント2 WiiU Edition 鉄拳レボリューション マリオカート アーケードグランプリDX 大乱闘スマッシュブラザーズ for NINTENDO 3DS, WiiU
- 5. 8年間で約100タイトル
- 6. 正直辛かった。
- 9. 採用タイトルのスケジュールが不明 • タイトル側の情報はほとんど入ってこないため、マスター提出がい つになるかも分からない。 • 最初にライブラリを渡したときに聞いたスケジュールは、ずれにず れまくってあてにならない。 • 人によって、提示されているスケジュールが違う。
- 12. マスター提出直前になってから 「この症状1ヶ月前から出てました」という報告が来る • かなり多い。 • 原因がタイトル側かライブラリ側かを追求しておらず、ギリギリに なって判明した思われる。 • 1ヶ月前ならもっと余裕を持って対応できたのに…。
- 16. 人員は減らされはしないものの どれだけ忙しくても現状維持 ! • ライブラリチームとして独立した組織になると、人件費が分かりやすく 目に見えてしまう。 • だが、ライブラリの採用によるコスト削減効果は数字には現れない(余 裕ができた分、仕様を詰め込まれてしまう)。 • 「人を増やしたい理由を述べよ」と言われても、いつどれだけ来るか分 からないサポート案件にどれだけ時間を割くべきかが計算できない。
- 17. その分野に詳しい人ほど 変な使い方をして不具合が出る • ライブラリを無理矢理ラップして自分の好きな作り方に合わせよう として、想定外の使い方をされる。 • メリットをことごとく潰すような使い方をされることも。 • キャリアの長い人に多い。
- 18. 安定したと思っていたのに 他のタイトルに貸与するとバグが出まくる • プロジェクトによるプログラミングスタイルの違いは思った以上に 大きい。会社が違うとそれどころではない。 • 何年も経ったのに基本的なところにバグが発見されたりする。 • 当初はタイトル側の勘違いだと思っていたものが実際にバグで、平 謝りということも。
- 20. スケジュールの遅延の言い訳として ライブラリのバグが偉い人会議で広められる • いろいろな要因があるはずなのに、目立ちがちなライブラリのせい にされる。 • 風評被害もいいところ。 • 「あのライブラリ、バグだらけらしいよ」という が出回る。
- 21. シリーズものに使われたら最後 5年10年サポート • 何年も前のライブラリをサポートするのは厳しい。開発環境を維持 したり、最新のSDKやガイドラインに合わせたり。 • なかなか最新版を使ってもらえず、最初に渡したバージョンに手作 業でパッチをあて続けることに。 • 最新版なら簡単にできるはずの機能が使えなくて、はがゆい。
- 23. 最新のライブラリやデータを渡したのに 反映されていない • 修正箇所をメールで知らせたことによるコピペミス。 • プロジェクトのフォルダ構成がややこしくて、ライブラリファイル を違うところに置いてしまっている。 • 担当者が今日は不在だった(情報が入ってきていない！！)。
- 24. ソースで渡すと「高速化！！」 とか言って魔改造される＝不具合発生 • 当然ライブラリの全容を理解しているわけではないので、不具合の 温床になりやすい。 • 改造による不具合の場合、ライブラリチームの環境では発生しない ため、原因の追及が余計に難しくなる。 • 自分のバグより他人のバグを直すのが好きな人もいる。
- 28. 婚期を逃す • 残念です。
- 32. 辛くならないための方法
- 33. APIの数を極力減らして 変な使い方をされないようにする • 想定外の使われ方は、潜在的なバグを呼び起こす。 • 多機能ではなく高機能を目指して、APIの抽象度は高めにする。 • 「アンチパターン」が参考になる。
- 34. ドキュメントとサンプルプログラムを 充実させる • 多くのプログラマーは、サンプルプログラムをコピペして使ってい る(断言)。 • サンプルが正しい使い方をしていれば、変な使い方はされない。 • 問い合わせに丁寧に答えつつ、「マニュアルの○ページにも書いて あります」と返せると、強い。
- 35. SDKのサンプルプログラムを コピペして作る • SDKも「ライブラリ」なので、どう使えば問題が起こりにくいかは 全く同じ。 • SDK開発者が使って欲しいと思っている方法で使ってあげよう！！
- 36. Windows版も作る • 全員が開発機を持っている訳ではないが、Windowsはみんな持って いるので、みんなでデバッグできる！！ • Windowsはメモリ保護もあるしランタイムでのチェックも可能。 • VisualStudioのエディタやデバッガがとにかく優秀。 • 64bit版の実験台にもなる。
- 37. 全機種でデータを共通化 • ライブラリのWindows版を作ったとしても、データが違うと意味が ない。 • 共通部分はリトルエンディアンに統一。現世代はこれが主流である し、変換コストより運用上のメリットの方がはるかに大きい。 • 機種依存部分はチャンク形式によるブロック化で切り離したり。
- 38. エラー処理をきっちりとやりすぎず あっさり落とす • NULLアクセスなどで落ちるはずのところを無理矢理回避してその まま進行すると、想定外の部分で落ちて原因が分かりづらい。 • 使う側がエラーチェックしていないことも多いので、エラーのタイ ミングを掴めない。 • デバッガに落ちる瞬間を拾ってもらった方が分かりやすい。
- 39. 頻度の低いバグを見逃さない • こういったバグはマスター提出直前に「必ず」再発する。 • プログラムに「たまたま」はない！！ • 頻度が低くても、バグ報告をよく読んで状況を絞れば、再現しやす い環境を作ることはそれほど難しくない。
- 40. ソースでは渡さず ライブラリファイルで渡す • 魔改造はさせないぞという意思表明。 • プロジェクトによってビルド設定が違っていたりして合わせるのが 面倒なので、それを回避するためでもある。 • マスター直前の場合、ライブラリの改造ではなく、使い方の変更で バグを回避する手法を提示する。
- 41. ライブラリファイルとデータに バージョン番号を埋め込んでおく ! • 更新ミスを判定するために、ライブラリファイルにSubversionなどのリビ ジョン番号を埋め込み、それを取得するAPIも用意する。 • ヘッダファイルの定義を書き換えるだけではダメ。ヘッダファイルは更新し たがライブラリファイルが更新されていないということもよくある。 • データに日付を 文字列 で埋め込んでおくのも手。タイムスタンプはあてに ならず、これならゲームを実行しなくてもバイナリエディタで確認できる。
- 42. ブランチを切らない • ブランチが増えたら増えた分だけ、サポートの手間が増える。 • どうせマージは失敗するよ。 • 全部trunkで行こう！！
- 43. プログラミング以外の作業は 徹底的に自動化 ! • ビルドはJenkins。古いバージョンのSDKでのビルドとか、ブランチへのパッ チを当てたバージョンのビルドとか、自動化しづらい部分であっても手作業 は最低限で済むような仕組みを作る。 • Windowsのバッチファイルで書いておくと、関連ツールのインストールが必 要ないので、自分以外の誰かに作業を任せるのが楽。 • ドキュメントはDoxygen。コード内に記述できるので面倒がないし、ライブ ラリとドキュメントのバージョンがずれたりすることもない。
- 45. とりあえず何でもメールで受け付ける • ライブラリチーム全員に配信されるメーリングリストを開設して、 とにかく何かあったらメールを投げてもらうようにする。 • 「バグ」や「要望」だけでなく、「相談」も見逃さない。 • 案件管理システムにはライブラリチームやサポート専門要員が入力 し、サイトのアドレスを返信して、以後はそちらでやりとり。
- 46. 「開発者による直接サポート」 を売りにしない • 小規模なライブラリチームが「売り」として言いがち。 • 案件が同時に複数入ると簡単に破綻する。 • 案件への対応が遅れてクレームが来るだけでなく、肝心のライブラ リ開発の進行も止まる。
- 47. サポート依頼に対する返答期限を 「最長で1週間」と表明しておく ! • 一見遅いように感じるが、案外なんとかなる。相手もそれに合わせて 1週間余裕を持って問い合わせてくれる。 • もちろん余裕があればその日のうちに返答。あくまで最悪の状況のと きの時間稼ぎ。 • マスター提出直前ではそういうわけにはいかないが、その対応が特別 なケースであることは理解してもらえるはず。
- 48. ご用聞きに行く • 「便りがないのは元気な証拠」…であった試しがない。 • 最初は「大丈夫だ、問題ない」と言っていても、突っ込んで行くと 怪しい情報が出てくる。 • トラブルの芽は早めに摘む。
- 51. 何でもかんでも プログラムで解決しようとしない ! • 実装が難しいなら仕様を削ってもらう、重いならデータを減らしても らう、不安定ならその機能を使わないようにしてもらう。 • コードをこつこつ削るより、テクスチャ1枚リサイズしたほうが速い こともある。 • 周りもプロのゲーム開発者。何らかの制限がある中でも、ベストな仕 事をしてくれるはず。
- 52. これにて、めでたしめでたし
- 53. …とは行かないようです。
- 55. ツイートツイート 992 ホーム > プレスリリース > ソニー・コンピュータエンタテインメントとユニティ・テクノロジーズ 「プレイステーション」向け「Unity」を すべてのソ フトウェアタイトル開発者の皆様に無償提供 ENGLISH 2014年9月17日 株式会社ソニー・コンピュータエンタテインメント ユニティ・テクノロジーズ ソニー・コンピュータエンタテインメントとユニティ・テクノロジーズ 「プレイステーション」向け「Unity」を すべてのソフトウェアタイトル開発者の皆様に無償提供 株式会社ソニー・コンピュータエンタテインメント（SCE）と、革新的な開発プラットフォーム「Unity」を提供するユニテ ィ・テクノロジーズ（本社：米国カリフォルニア州）は、２０１３年３月に合意した戦略的提携にもとづき、「プレイステー ション」向け「Unity」の「Unity Pro for PlayStation®」を提供していますが、この度さらなるパートナーシップの強化を図 り、「プレイステーション 4」、「プレイステーション 3」および「プレイステーション ヴィータ」向け「Unity Pro for PlayStation®」をすべてのソフトウェアタイトル開発者の皆様に無償で提供いたします。 1,029シェアシェア
- 57. 市販ライブラリ 社内ライブラリ 機能 汎用的 独自機能あり コスト 価格競争が激しい 社内人件費高すぎ サポート サポート専任スタッフ がいる 開発者が空き時間に サポート 力関係 何でも言うこと 聞いてくれる 文句も言う
- 58. 勝負にならない！！
- 59. 生き残るためには… • 特定のプロジェクト専用に進化させる。 • ライブラリを応用した独自のアプリを提供する。 • ゲーム業界以外に進出する。 • …他にも何かあればメール等で私までご連絡ください！！
- 60. まとめ
- 61. 辛くならないためにやるべきこと • バグを減らす。 • デバッグしやすくする。 • 情報を入手する。 • 時間に余裕を持つ。 • 何でもかんでもプログラムで解決しようとしない。