• Save
失敗から学ぶゲーム開発(ドラゴンジェネシス〜聖戦の絆〜の場合)
Upcoming SlideShare
Loading in...5
×
 

失敗から学ぶゲーム開発(ドラゴンジェネシス〜聖戦の絆〜の場合)

on

  • 34,801 views

スマホゲーム、ドラゴンジェネシス〜聖戦の絆〜 ...

スマホゲーム、ドラゴンジェネシス〜聖戦の絆〜
の開発談です。

過去のプロジェクトの失敗を元に、今回はこのようにつくった、というお話をしています。
失敗は色々な形があり、一概にまとめられませんが、
同じような失敗をしないよう、何か参考になれば幸いです。

Statistics

Views

Total Views
34,801
Views on SlideShare
32,892
Embed Views
1,909

Actions

Likes
146
Downloads
66
Comments
0

18 Embeds 1,909

https://twitter.com 731
http://d.hatena.ne.jp 649
http://baba-s.hatenablog.com 252
https://cybozulive.com 92
http://localhost 39
http://www.plurk.com 33
https://www.chatwork.com 28
https://kcw.kddi.ne.jp 26
http://feedly.com 20
http://admin.blog.fc2.com 15
http://slshmatome.blog.fc2.com 10
https://translate.googleusercontent.com 4
http://www.slideee.com 4
https://www.commafeed.com 2
http://www.google.co.jp 1
http://tweetedtimes.com 1
https://www.linkedin.com 1
http://s.deeeki.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

失敗から学ぶゲーム開発(ドラゴンジェネシス〜聖戦の絆〜の場合) 失敗から学ぶゲーム開発(ドラゴンジェネシス〜聖戦の絆〜の場合) Presentation Transcript

  • 失敗から学ぶ ゲーム開発 ドラゴンジェネシス 〜聖戦の絆〜の場合 株式会社gguummii 田村祐樹
  • 自己紹介(田村 祐樹) gguummiiに入�ってそろそろ4年 ゲームをつくって早12年 メインプログラマ(のようなもの) ゲームの本数でいえば、12本くらい 基本的になんでもやさん
  • ドラゴンジェネシスとは リアルタイムギルドバトル View slide
  • こんなキャラや View slide
  • こんなキャラが 闘います
  • 幻 獣
  • 幻 獣
  • 主な技術構成要素
  • しかし、今日は 言語の話はしません
  • 今日話すこと ネイティブゲーム開発で 陥る罠 なぜプロジェクトは失敗 するのか
  • 失敗とは? このプロジェクトだけの話ではなく、 ゲーム開発に必ずついて回る問題を話 します ゲーム開発をしたことがない人たちが 見落としがちな構成要素をまず話し そして、失敗に陥りがちな外的要因、 内的要因について話します
  • ゲームの最低限の 構成要素 サウンド アニメーション/絵 データ ゲームバランス
  • FFFFもDDQQもマリオも デザイン(22DD、33DD問わず) サウンド(BBGGMM/SSEE/ボイス) データ(当たり判定とか、パラメータ、 シナリオ) レベルデザイン(難易度やルール決め) 基本の素材は、 この組み合わせで出来ています +プログラム
  • サウンド にまつわる問題
  • サウンド BBGGMM/SSEE/ボイス 経験者がいないと大変なことになる 例えば、量が多すぎて入�らないとか サイズが考慮されていないとか イントロループ再生とか、クロス フェードの事も考えられていない
  • 現場で起きる失敗 BBGGMM数十曲書いて貰いました!! SSEEも○○○個!!! ボイスも×××パターン!!!! 計算すると…�…�1GGBBとかいっちゃう
  • ドラジェネでは? 調整をコンポーザーさんにおねがいし た 特にゲーム専門のコンポーザーさんが いい BBGGMM/SSEE/ボイスの担当者をチーム内 で1人つけた 「鳴らす」だけではないので、思った 以上に必要性が高い
  • アニメーション にまつわる問題
  • アニメーション WWeebbはアニメーション=FFllaasshh ネイティブではFFllaasshhをそのまま使えな い 解決作としてのツール「SSppiinnee」 「SSpprriitteeSSttuuddiioo」「CCooccooSSttuuddiioo」 静止画より動きのある構造は難しい また、UUIIの配置も検討すべき
  • 現場で起きる失敗 何のアニメーションがどれだけあるか を決めずに、発注をかけてしまう! 決められたUUIIを作ってみたら使い勝手が 悪く、直そうとしてもデザインの分解 がされてない! デザインのサイズ、フォーマットなど が統一されておらず、適当!
  • ドラジェネでは ちょうど、CCooccoossBBuuiillddeerrが開発停止して いた 他のツールは軒並みβ以前だった ということで内製ツールで、 FFllaasshh((SSWWFF))からOOppeennGGLL描画できるよ うなデータを吐く仕組みをつくった UUIIも別途構築するツールをつくった
  • データ にまつわる問題
  • データ WWeebbと違い、データはサーバー/クラ イアントが同期しなければならない サーバー/クライアント/DDLLCCのすべ ての同期をとる必要がある 最初に何をどう持つかを考えるのは最 重要課題と言える
  • 現場で起きる失敗 UUIIや、動きをつけるところがデータに なってない!! UUIIをちょっと変えたいだけなのに申請が 必須!! データとデータが複雑に絡み合って て、最新にしたはずが最新にならな い!
  • ドラジェネでは 最初に更新頻度の高いもの、低いもの の切り分けを行った 更新頻度が高いものはDDLLCCに含めるこ とで、改�善をしやすくした また、データ構造を変えやすいよう に、EExxcceellからJJSSOONNを吐き出すようにし た
  • ゲームバランス レベルデザイン にまつわる問題
  • ゲームバランス 最も鬼門になると言ってもいい どんなに面白いゲームもバランスを欠 いていると一気にクソゲーになる 運用がある以上、バランスはとり続け るもの、と考えるべき
  • ゲームバランスは なぜ難しいか? 多くの人は「強さ」を一本の線�で考え がち ひのきのぼう→こんぼう→どうのつる ぎ→はがねのつるぎ→はじゃのつるぎ →ロトのつるぎ…�…�
  • 強さはインフレする ロトのつるぎを手に入�れた先にあるも のは? 真・ロトのつるぎ? それとも…�…� 攻撃力を上げ続ければ切りがない
  • レベルデザインの基礎 正しい答えは ありません ただ、教科書には 目を通して おくと違います
  • なぜプロジェクトは 失敗するのか
  • なぜプロジェクトは 失敗するのか 答えは簡単で…�…� ゲームには答えがないからです *ここでの失敗の定義:  プロジェクトが終わらない  または終わっても売れずに終了
  • 答えがないのが普通 誰もが最初から面白いという答えは 持っていない 作る中で面白いとは何かという答えが 得られないプロジェクトは確実に失敗 する 答えを出すためには試行錯誤が必要
  • ドラジェネで出来た事 完全新作として割り切ってすべてを再 構築できた 「面白い」とは何かをチームで話すこ とができた 試行錯誤する時間を無理矢理つくった
  • いらないものは捨てた gguummiiには既にギルドバトルのソースが あったが、すべて捨てた 1からギルドバトルとは何かを考え、 必要な事とやるべき事を決めた
  • 既存ではダメなのか? 既にあるソースは、すべてのスキルが ソースコードによって実装されていた この構造の最大の欠点として、ゲーム デザイナーがこねくりまわせない
  • どう変わったか? スキルを「効果」に分断し、この効果 の組み合わせによって、色んなスキル をつくれるようにした これによって、ゲームデザイナーが試 行錯誤できる土壌をつくった
  • 計算式を一新した 既存のゲームの計算式を見直し、数値 がインフレする可能性のある式をすべ て見直した ゲームデザイナー(≠ユーザー)が予 想しない数値がでないようにした
  • 考え方をゼロベースに 他のゲームがこうだったから、という 考えは一切しないようにした 新規タイトルとして、仕組みからすべ て考えるようにした 「AAというゲームがこうだから、これを 取り入�れる」をやるとちぐはぐになる
  • 未完成ゲームは 必ずクソゲーである ゲームの面白さは完成が近づかないと わからない 自分たちの頭の中にある「面白い」は 他の誰かに受け入�れられるとは限らな い ゲームは煮詰める段階で必ず面白さが 醸成される
  • 大人数では 煮詰められない ゲームは必ず横槍が入�る 「これ面白くないよ」 「○○さんが面白くないと言ってる」 「流行ってる××というゲームはこれ で売れてる」 チーム外からは必ず好き勝手な意見が でる
  • 自分たち((=チーム))が 信じるものをつくる 「ここクソだから直そう」 自己否定も辞さない 誰かの提言/押しつけに従うと自分た ちへの言い訳になる 「〜は無理って言ったのに無理強いし た××が悪い」 「上が邪魔するから思ったものがつく れない」
  • 技術的に完成しても ゲームは完成しない プログラマはこれを意識するべき 動いている≠面白いゲーム 要するにゲームが売れなければ、技術 的な努力は無駄になってしまう
  • 浪費しているのは メンバーの人生の時間 プロジェクトの失敗=時間の浪費 結果として、自分だけじゃなくて、 チーム全員丸損 人生に何度もチャンスはない
  • ゲーム開発は 想いを形にする開発 根性論も大事 伝えたいことは伝える クソなものはクソだと言う 決定に従うことで逃げ場をつくらない
  • ドラジェネは 失敗がない訳ではない 自分が知りうるだけの失敗を避けよう としたが、避けられていないところも 勿論ある 失敗を避けた先に失敗があるのは避け られない どうやって同じ失敗を繰り返さず、よ り良い失敗をするかが鍵
  • まとめ1 理解してないものをとりあえず用意す るのはやめよう(=リソース) 構成要素が欠けているとそもそもゲー ムとして完成しない 特に目に見えないデータやレベルデザ インに顕著にでる
  • まとめ2 誰かの決定に従ったということを免罪 符にしないようにする プロジェクトが失敗したときに損をす るのは自分とメンバーとユーザー なら、失敗をしないように最善を尽く すしかない
  • 最後に 失敗を避けたからといって成功すると は限らない ただ、避けられる失敗は避けるべき 失敗から学んで後悔しない開発をしよ う!
  • ご静聴 ありがとうございました