今回は質問が２つ程ありましたので、先にお答えします。 【質問】 ・ステージはいくつあるのですか？ 　 　無限ではなく、1000面までデータとして登録しております。 ・支援の仕方はどうするのですか？ 　こちらは、nanapiさんの記事が詳しく載っているので、 　http://nanapi.jp/85550/　をご覧下さい。 【お知らせ】 http://atnd.org/events/42408 Tech Buzz 様にて、サムライディフェンダーの事例紹介として、登壇することになりました。既に100名突破しているので、非常に緊張しております。 【前回からの続き】 さて、仕様書をプログラマに見せて、一通りのデザイン素材とセットで渡した後、本来であれば、見積もり　⇒　要件定義　⇒　設計　⇒　実装と流れていくのですが、納期は１ヶ月、遅くとも年内に完了して年明けリリースとディレクター判断で勝手に設定しました。 こう書いてしまうと、大変な開発現場だなぁ～　と思われてしまうのですが、（実際大変ですが）、本当はどんなにがんばっても３ヶ月はかかることがわかっていました。(※1)経験上、技術がわからないもしくは仏のディレクターで納期通りで品質基準を満たしたプロジェクトはないために、ハッパをかけました。(※2) 　 技術がわかるディレクターの強みとしては、プログラマーの出来ない言い訳を論破することができるに尽きると思います。但し、ポイントとして、実装経験がないものや、認識を合わせないといけない箇所、前提知識が足りないためにいたずらに工数がかかりそうな箇所に関しては、都度説明する必要があります。説明の時間を省いて実装完了後に作り直しをさせるのはかなりロスになってしまいます。 つまり「ゲーム開発の仕組み」を理解して使いこなすことがどこまでできるかが重要です。 そうすると、普段おとなしいプログラマも、あれが足りない、これが足りない、この仕様が矛盾しているなどと前衛的に行動してくれるため、後はコードを書かない人がどんどん要望を満たしていくことで、概ね想定した納期に近づけることができます。こういった状況の中で遅延なく判断して、作業分担を行っていくのがディレクターの仕事となります。 こうして実装がスタートし、バランス調整、デバッグができるまで私は受託開発を行うことになります。 ※1結果的に実装は３ヶ月かかりました。 ※プログラマ=役員、私(ヘルプ) つづく

さて、デザイナーもジョインしたことで、プロジェクトが本格的にスタートできることになったわけですが、弊社の取締役である和田から、ひとつお願いごとをされていました。 ・仕様書がないプロジェクトが振り回されるだけなので、仕様書を用意して欲しい。 私もプログラマー経験が長いので、気持ちはよくわかります。 そのため、まずデザイナーと世界観の決定と、その間にコツコツ仕様書を書くところから始めました。 よく勘違いされてしまうのですが、ＲＰＧ一人で作れるくらいならコード書いた方がいいんじゃないですか？と聞かれることがありますが、私自身は元々ディレクター志望で、修行のためにプログラマーをやっていたという経緯があり、そこそこＰＧの仕事ができたため、気が付いたらＲＰＧ丸投げされるくらいになっていましたが、さすがに、これ以上やってても人生の目的が到達できないので、当時の上司にディレクターやらせてもらえないなら別の会社探しますといって、配属転換をお願いしました。つまり、ＰＧはとっくに引退しているのですが、起業したらそんなことも言ってられないので、たまに受託でのコードを書く仕事をしています。簡単に言ってしまうと、優秀なプログラマが振り回されてバタバタ手だけ動かしても、誰も得する「結果」にはならないので、できる限り間違いのない方向性で進めるようにしています。 前置きが長くなりましたが、世界観決定には、以下の点に注意しました。 ・新人デザイナーが理解できる（実現可能と思える世界観） ・最低限必要なデザイン素材に物量を抑えること。 １．世界観 私は、下手くそな絵しか描けないので、参考作品となるものをかき集め、 各作品の参考にして欲しい点、参考にして欲しくない点を、私情と市場環境の説明を交え、洗いざらい話しました。 その私が話したことで、どんなラフが挙がってくるのかをチェックし、説明の仕方、指示の出し方を調整していきました。 間違った指示の例 ゆるキャラ　⇒　動物を連想してしまうので人が出てこない。 うまくいった指示の例 ドラゴンボール　⇒　世界的にヒットしているマンガであり、日本人であれば誰でも知っているレベルなので、似たような絵が出てくる。 こういった、指示出し、ラフ描きを繰り返し、世界観を構築していきました。 ２．仕様書 書き出せることは全て書き出そうと思っておりましたので、かなりのページ数になりました。リリース時点では１００ページ強だったのですが、現在見直してみると、改版履歴を含め１７８ページありましたｗ 主な記載種別としては、下記４点ほどなのですが、 基本的に全ての状態に関して、 ・画面イメージ（最初はエクセルの図形で○□△で、枠組みの構成） 　 　 　 　 　イメージの隣りは、フローチャート ・各種計算式 ・計略時の挙動 ・敵、ボスＡＩ ※各項目ごとに、細かい説明 など、出来る限り具体的に細かく記載しました。 （ちょっと記載が足りない部分もありますが・・・） ただ、これは後でプログラマーに、「こんなに仕様書、読み切れないよ・・・」と、言われてしまいます。。。仕様書を書いたら書いた分だけ、読む時間もスケジュールしておかないといけないですね。 ともあれ、世界観構築(キャラ製作含む）と仕様書作成を並行して進めていき、受託開発が落ち着いてきたころにプログラマがプロジェクトにアサインされることになります。 つづく

前回からの続き プロジェクトの企画は決まったものの、デザイナーがいませんでした。 方方に相談してみましたが、いまいちピンと来ないというか、なかなか弱小企業を手伝ってくれるデザイナーさんはいなかった(※1)ので、ベンチャーKANDA内で回ってきた情報で、「若年者緊急就職サポート事業」に応募して、現代の若手の力に賭けてみることにしました。 （というか選択肢が他にありませんでした） http://www.metro.tokyo.jp/INET/BOSHU/2013/04/22n48100.htm ゲーム業界は、若手にとって人気の職種なのですが、我々は大変であることは知っているので、「想像以上に大変ですよ」と説明した上で、ジョインしてもらうことになりました。 こういう姿を見ると自分が若いころも、大変な業界だと知りつつもドップリとつかってしまったので、感慨深いもの(※2)を感じながら、世界観作りと仕様書作成に移っていくことになります。 ポイントは、 ・新人デザイナーでも、クリアさせることのできるプロジェクト規模、精度にすること。 孫子の言葉を借りれば、「彼を知り己を知れば百戦殆からず」 つまり、市場を知った上で、自己の戦力を知り計画を練らなければならない状況だったので、開発の落とし穴になりそうなところは、事前に取り除いておくことが必要でした。 これは仕様書の精度、見積もりの精度と言った計画段階の精度を上げて、スタッフに的確に情報を伝えることがミッションとなります。 つづく ※1　現状も市場環境的には、カード製作でひっぱりダコです。 ※2　私は業務システム系からゲーム業界に転職した時、母親に泣かれ、父親には怒られました。「システム作ることができるなら、ゲームよりも世のため人のためになるものを作れ」と、これは私が彼らが生きている間に、ゲームが世のため人のためになるものなれると証明しなければならなくなったので、大きな宿題を背負うことになりました。（現在も親に会う度にアピール中です）

前回からの続き。 自社プロジェクトを始動させるにあたって、企画ネタが３本ありました。 １．Fruit Ninja っぽいアクション ２．オリジナルパズルゲーム ３．サムライディフェンダー １は、どう発展させればよいか、わからなかったので、 パズルを当初進めようとしていたのですが、オリジナルなだけにステージを充分な数を用意することができそうにありませんでした。 そこで、当時、ディフェンダーというUSAのゲームにはまっていたので、このゲームをどうにかできないかと考えました。（日本のゲーム開発ではUSAのヒット作をインスパイアしてゲームを作るのは事例として多かったりします。） DEFENDER(以下D) https://play.google.com/store/apps/details?id=com.droidhen.defender&hl=ja プレイすると違いがわかるのですが、Dとサムライディフェンダー(以下SD)は、操作感が全然異なります。操作の違いは１、２点程なのですが、SDからプレイした人にとって、Dは結構疲れてしまうのでプレイが続かないそうです。 変更点としては、おおまかに５点です。 １．ＵＩ ２．操作感 ３．世界観 ４．成長要素の構成 ５．SNS要素等、追加要素 ゲームの基本ルールである下記３点は同じです。 ・右から左に敵が出てくる。 ・城門が壊されたら負け ・敵をすべて倒したらステージクリア ？あれ？パクリ？と思われそうですねｗ これに関しては取締役である和田ともよく議論します。 流行りのランニング系ゲームで例えると、 同じルール ・左から右へ自キャラが進む（走る） ・穴に落ちるか、敵に触るもしくは攻撃を受けるとゲームオーバー 違うルール ・アイテム構成 ・ステージ構成 ・他 これだけで違うゲームに見える・感じてしまうんですね。 ※同じジャンルのゲームだとは認識できます。 従って、基本ルールだけ踏襲（ジャンルは同じ）で、それ以外を変えるようにしました。コアゲーマーである和田は「パクリ」は作りたくないと常々言っておりますので、これで企画はまとまり、プロジェクトがスタートとなりました。 つづく

9/24に、 Hatch up様主催のTech Buzzで、お話しさせて頂くことになりました。 http://atnd.org/events/42408 主催者にお願いして、この日に設定してもらいました。 CAMP FIREの募集最終日ですね（＾＾ 公開処刑となるか、神風が吹くかは神のみぞ知るところですが、 タイトルの通り、振り返りながら数字も交え、時間の許す限りお話しして行きます。追って発表しますが新しい試みもあるので、お時間ある方は是非いらして下さい。 サムライディフェンダーの始まりは去年の６月、当時担当していた受託開発が買い叩かれに、買い叩かれすぎて、倒産の危機的状況でした。 こういった時の社長の仕事ととしては、顧客と交渉しつつ、資金調達のために銀行を駆けずり回り、開発チームに踏みとどまってもらうために調整し、先のことも考えなければならない、自分は当面のキャッシュフローのためにサイクルの良い開発を行うという、非常にやることがたくさんありました。 何のためにベンチャーKANDAにまで入って受託をやっているのか？ 自分達でゲームを作るために、会社まで作っているやっているんだろ？ 自問自答の日々も続いたある日、このままじゃいけないと思い、ここで、一気に自社開発に向けて大きく舵を切りました。 「サムライディフェンダープロジェクト」の始まりです！ つづく