■ 2017/07/30 (日) 第9回ウディコン審査開始! ■
【第9回ウディコン審査開始!】
ということで第9回ウディコンのエントリー期間が終了し、
審査期間が開始されました!
エントリーしてくださった皆さま、本当にありがとうございます!
作品総数はNo.67までのなんと全65作品!
去年の68作品とほぼ変わらない数で、
今なおウディタを使ってくださっている皆さまには感謝の限りです!

すでに始まっている審査では、プレイヤーの皆さまからの投票が行われ、
最終結果はその審査結果で決定されます!
よければぜひ、投票していただけますと幸いです。
↓
【WOLF RPGエディターコンテスト(ウディコン)公式サイト】
●審査は「熱中度」「斬新さ」「物語性」「画像/音声」「遊びやすさ」「その他加点」の
6部門の得点を付けて評価していただきます。
●最終結果の「得点」に反映されるためには、最低4作品以上の審査を行う必要があります。
ただし、1作品だけの評価でもコメントは作者様に届きますし、結果発表時にも採用されます。
今のところ、過去数回のコンテストにおける部門別の最終結果は
それなりに納得しやすい感じになっていると考えているので、
評価方法はしばらく同じようにするつもりです。
ただし今後、有効投票数の減少や作品数の増減などの状況の変化によって
無理が出てくるところもあると思いますので、その都度、
適応できるように対応していきます。
それでは第9回ウディコンのすばらしき作品群、ごゆっくりお楽しみ下さい!
ということで第9回ウディコンのエントリー期間が終了し、
審査期間が開始されました!
エントリーしてくださった皆さま、本当にありがとうございます!
作品総数はNo.67までのなんと全65作品!
去年の68作品とほぼ変わらない数で、
今なおウディタを使ってくださっている皆さまには感謝の限りです!

すでに始まっている審査では、プレイヤーの皆さまからの投票が行われ、
最終結果はその審査結果で決定されます!
よければぜひ、投票していただけますと幸いです。
↓
【WOLF RPGエディターコンテスト(ウディコン)公式サイト】
●審査は「熱中度」「斬新さ」「物語性」「画像/音声」「遊びやすさ」「その他加点」の
6部門の得点を付けて評価していただきます。
●最終結果の「得点」に反映されるためには、最低4作品以上の審査を行う必要があります。
ただし、1作品だけの評価でもコメントは作者様に届きますし、結果発表時にも採用されます。
今のところ、過去数回のコンテストにおける部門別の最終結果は
それなりに納得しやすい感じになっていると考えているので、
評価方法はしばらく同じようにするつもりです。
ただし今後、有効投票数の減少や作品数の増減などの状況の変化によって
無理が出てくるところもあると思いますので、その都度、
適応できるように対応していきます。
それでは第9回ウディコンのすばらしき作品群、ごゆっくりお楽しみ下さい!
■ 2017/07/23 (日) 第9回ウディコン開催! ■
【第9回ウディコン開催!】
今年も夏の祭典、『WOLF RPGエディターコンテスト』が始まりました!
すでにエントリー作品は公開されダウンロード可能になっておりますので、
尖ったゲームに飢えている皆さまはぜひごアクセスを!
すでに15作品以上がエントリーしています!
【WOLF RPGエディターコンテスト 公式サイト】

今回は1年前から第9回ウディコンに向けてのカウントダウンを
定期的に行っていたのですが、その影響がどう出るかも
少し注目していきたいところです。
いつもより大作が多くなったり、その逆だったり、特別な傾向が出るかもしれません。
遊ばれる方は、市販ゲームではもしかしたら味わえないかもしれない、
目新しいゲームの数々にぜひ触れてみてください!
そして好みに合うものがあれば、ぜひ作者の方を
応援してあげていただきたいと思います。
それによって、あなた好みのゲームがまた作られるかもしれません。
エントリーの締め切りは7/29の23:59まで!
それまでの間、逐次追加されていく新作にきっとワクワクできることでしょう。
なお、締め切りギリギリのタイミングだと事故が起きやすいので、
エントリーされる方はくれぐれもご注意を!
それでは皆さま、今年のウディコンもごゆっくりお楽しみください!
今年も夏の祭典、『WOLF RPGエディターコンテスト』が始まりました!
すでにエントリー作品は公開されダウンロード可能になっておりますので、
尖ったゲームに飢えている皆さまはぜひごアクセスを!
すでに15作品以上がエントリーしています!
【WOLF RPGエディターコンテスト 公式サイト】

今回は1年前から第9回ウディコンに向けてのカウントダウンを
定期的に行っていたのですが、その影響がどう出るかも
少し注目していきたいところです。
いつもより大作が多くなったり、その逆だったり、特別な傾向が出るかもしれません。
遊ばれる方は、市販ゲームではもしかしたら味わえないかもしれない、
目新しいゲームの数々にぜひ触れてみてください!
そして好みに合うものがあれば、ぜひ作者の方を
応援してあげていただきたいと思います。
それによって、あなた好みのゲームがまた作られるかもしれません。
エントリーの締め切りは7/29の23:59まで!
それまでの間、逐次追加されていく新作にきっとワクワクできることでしょう。
なお、締め切りギリギリのタイミングだと事故が起きやすいので、
エントリーされる方はくれぐれもご注意を!
それでは皆さま、今年のウディコンもごゆっくりお楽しみください!
■ 2017/07/15 (土) 来週よりウディコン! ■
【来週よりウディコン!】
今回もウディコンのお知らせでお茶にごしさせていただきます!
ということで、いよいよ第9回ウディコンが来週に迫ってまいりました!

いつも通りの注意点や、今回のウディコンにおいて
変化がある部分についてお知らせします。
●作品受付は7/23(日)頃と書いてありますが、負荷分散の目的でこっそり
7/22(土)の夜頃からエントリー開始します。これは例年通りです。
●今回から、エントリー用のスクリーンショットサイズの制約がゆるくなりました。
最大サイズは横800x縦600までで、16:9のサイズでも構いません。たとえば800x450など。
→ 最新版のウディタで、画面サイズがだいぶ自由になったための措置です。
今年は色んな解像度のゲームが来そうで、その点も楽しみです。
●コンテストのエントリー時に注意していただきたい点は以下の通りです。
- オープニングで進めなくなるゲームが届くことがありますが、その場合はエントリーできません。
少なくともオープニングが突破できることを確認してください。
- たまにデバッグのために初期位置を変えた状態から始まっていたり、
デバッグモードが入ったままリリースされている場合があります。
一度、アップローダに上げたファイルをご自分でダウンロードして、
意図通りにゲームが動作するか確認してください。
- PSD(フォトショップ用)ファイルなど、いらないと思われるファイルが大量に入っているために
容量が極端に重くなっていた場合はエントリーを拒否する場合があります。
- コンテスト期間中、ふりーむやVectorなどに投稿するとエントリー停止になりますので
そういったところへの投稿は審査終了日まではお待ちください。
●遊ぶ側の皆さまへ。ウディタの最新版が使われていればゲームを複数起動できるようになります!
→ 大した話ではありませんが、今回からはウディタの最新版が導入されていれば、
複数のゲームを2種類3種類と同時起動できます!
これで第8回みたいに、2つ以上のオートバトル系(放置)ゲームが来ても安心です。
●上記以外は、ほぼいつも通りのコンテストの流れとなります!
ゲームが公開されるのは『7/23の0時』頃より!
あなたの好きな作品が見つけられたら、ぜひ応援してあげてください。
私は、私好みの変則操作っぽいアクションゲームや
ローグライク的なゲームが来ないかなーと勝手に楽しみにしていますが、
それ以外にも、予想外の発想で攻めてくる面白い作品が必ずあるはずです。
自分のゲーム観の枠をメキメキ拡張できるような一本を、いつもとても楽しみにしています。
それが楽しめている限りは、私もウディコンを続けられるでしょう。
それでは、7/23をお楽しみに!
今回もウディコンのお知らせでお茶にごしさせていただきます!
ということで、いよいよ第9回ウディコンが来週に迫ってまいりました!

いつも通りの注意点や、今回のウディコンにおいて
変化がある部分についてお知らせします。
●作品受付は7/23(日)頃と書いてありますが、負荷分散の目的でこっそり
7/22(土)の夜頃からエントリー開始します。これは例年通りです。
●今回から、エントリー用のスクリーンショットサイズの制約がゆるくなりました。
最大サイズは横800x縦600までで、16:9のサイズでも構いません。たとえば800x450など。
→ 最新版のウディタで、画面サイズがだいぶ自由になったための措置です。
今年は色んな解像度のゲームが来そうで、その点も楽しみです。
●コンテストのエントリー時に注意していただきたい点は以下の通りです。
- オープニングで進めなくなるゲームが届くことがありますが、その場合はエントリーできません。
少なくともオープニングが突破できることを確認してください。
- たまにデバッグのために初期位置を変えた状態から始まっていたり、
デバッグモードが入ったままリリースされている場合があります。
一度、アップローダに上げたファイルをご自分でダウンロードして、
意図通りにゲームが動作するか確認してください。
- PSD(フォトショップ用)ファイルなど、いらないと思われるファイルが大量に入っているために
容量が極端に重くなっていた場合はエントリーを拒否する場合があります。
- コンテスト期間中、ふりーむやVectorなどに投稿するとエントリー停止になりますので
そういったところへの投稿は審査終了日まではお待ちください。
●遊ぶ側の皆さまへ。ウディタの最新版が使われていればゲームを複数起動できるようになります!
→ 大した話ではありませんが、今回からはウディタの最新版が導入されていれば、
複数のゲームを2種類3種類と同時起動できます!
これで第8回みたいに、2つ以上のオートバトル系(放置)ゲームが来ても安心です。
●上記以外は、ほぼいつも通りのコンテストの流れとなります!
ゲームが公開されるのは『7/23の0時』頃より!
あなたの好きな作品が見つけられたら、ぜひ応援してあげてください。
私は、私好みの変則操作っぽいアクションゲームや
ローグライク的なゲームが来ないかなーと勝手に楽しみにしていますが、
それ以外にも、予想外の発想で攻めてくる面白い作品が必ずあるはずです。
自分のゲーム観の枠をメキメキ拡張できるような一本を、いつもとても楽しみにしています。
それが楽しめている限りは、私もウディコンを続けられるでしょう。
それでは、7/23をお楽しみに!
■ 2017/07/08 (土) 今週はお休みです ■

今週はドタバタしすぎて開発日誌を書く元気が確保できなかったので、
今週の開発日誌はお休みさせていただきます!
ちなみに、今週はウディコンの準備も進めておりました。
今回のウディコンは7/23(日)より作品応募開始です!
といっても例年のごとく、負荷対策やデータ破損対策のために、
作品応募は前日22日の夜頃からこっそり始めると思いますのでご了承ください。
ウディコン公式サイトはこちら↓です。すでに開催まで二週間を切りました!
今年も熱い夏がやってきます。
【WOLF RPGエディターコンテスト 公式サイト】
http://www.silversecond.com/WolfRPGEditor/Contest/
今年からワイド画面や大画面のゲームなども作れるようになったので、
これまでと少し違った雰囲気になるかもしれません。
今年のウディコンも楽しみです。
■ 2017/07/01 (土) 開発で最近試していること ■
【ゲーム開発で最近試していること色々】
今回は私が最近のゲーム開発で行っている、
自分にとって有効そうだと考えているいくつかの試みについて整理してみました。
私と似た悩みを抱えている人や、私に近いタイプの人には、
部分的に役立つ部分もあるかもしれません。
以下の項目だけ見て分かる方には、飛ばしてくださっても大丈夫だと思います。
●最初: 「面白そうに見えるゴール」を先に考えてから作る。
●中盤: 見た目をきれいにする作業はやる気が減りそうなタイミングに回す。
●全編: 絵は最後まで徐々にブラッシュアップし続けるよう作る。
●一定頻度: 段階ごとに人に見せて方向性を確かめる。
●リリース前: できれば余裕を持って終わる。

【最初:「面白そうに見えるゴール」を先に考えてから作る】
まず私は、「できるだけ多くの人に遊んでもらいたい」という欲求が強いのですが、
どうやれば自分の作ったゲームを知ってもらえるか考えるのに四苦八苦しています。
「作ったものを面白そうにアピールすること」がいかに困難か、何度も思い知らされました。
たとえば「自分にとってそこそこ自信のあるゲーム」ができあがったとき、
その完成品から「とても興味を惹かれるキャッチコピー」を考えるのは、
実はとても難しいことだと思っています。
実のところ、これまでの私のゲームを見直しても、
「分かりやすく興味を惹くキャッチコピー」が思いつかないゲームが結構あります。
たとえば『シルフェイド幻想譚』の場合、目新しい要素が実は少ないので
「ストレス少なめの時限フリーシナリオRPG!」くらいしか言えません。
コンテストに投稿したことによって目立つことができた面は大きいと思いますが、その他は
『シルフェイド』という名前が付いている、ということが実質的に最大のアピールポイントで、
作品の概要情報や、キャッチコピーが普及力に貢献できた部分はあまり大きくはないでしょう。
そんなわけで私は、基本的には『ブランド』に頼るアピールのみがメインで、
作品紹介による宣伝面ではかなり苦戦していると感じていました。
そこで、私はここ数年でこう考えるようになりました。
自分のような宣伝が苦手な人間にとって
「面白そうに感じさせるキャッチコピーや見た目」を考えることがボトルネックになるのなら、
その「一目で面白そうに感じる部分」を先に考えておいてから
ゲームを作った方が普及力を上げやすくなるのでは? と。
たとえば、以下のいずれかのような方法でゲームを作るのです。
●遊びたくなりそうな宣伝文句を先に考えて、それに合わせてゲームを作る。
●遊びたくなりそうな画面写真を先に考えてみて、それに合わせてゲームを作る。
●やたら興味をひかれる物語紹介だけ先に作って、それに合わせてゲームを作る。
これらは、私のような宣伝が苦手な人間には一定以上、効果が上げられるやり方かもしれません。
さっきも言いましたが、「完成済みのものを面白そうに紹介する」のは意外に大変です。
ある程度の開発能力を身に付けているなら、「作った後のもの」を面白そうに見せるより、
先に「面白そうに見える状態」を考えておいて、
それにたどり着けるものを作る方がたぶんいくらか簡単です。
特に「画面写真」は、作った後からではなかなか面白くいじりようがない!
「物語説明」もそうです。一度読んでみれば物語の内容自体はすごく面白いのに、
いざ「紹介用のあらすじ」を書いてみるとなかなか面白そうに書けない、
あるいは興味を惹くのに苦労する、といったことはないでしょうか?
私は、あらすじで興味を惹くことを意識していなかったので、そこで悩んだことが何度もありました。
こういった苦労があるのならいっそ、先に「面白そうに見せるためのゴール」を考えておいて、
チャンスがあればそれに近付ける、という作り方は一つの手です。
私の場合、『片道勇者』がその方法で生まれたもので、
最初に『強制横スクロールRPG!』という
「興味をひきそうな宣伝文句」が生まれて、そこから開発が始まりました。
思いついた時点では果たして面白くなるのか、
どんなジャンルのゲームになるかは全く分かりませんでしたが、
最終的には『強制横スクロールRPG』という期待を満たせる程度の作品に作りあげ、
目新しいキャッチコピーにより新鮮さを伝えることができたと考えています。
もしこれがただのローグライクRPG、あるいは説明が難しいローグライクRPGだったら、
見てもらえる人の数は今の半分以下や、1/4以下になったかもしれません。
もちろん、こういう作り方で失敗してしまう場合も当然あると思いますが、
今はどこへ出すにしても作品数が増えすぎて、
まず「少しでも興味を持ってもらえるかどうか」が
一番のネックになっているのではないか、と私は考えています。
そんな環境で少しでも目立てるようにすることを考えると、
上記のように先に「面白く見えるゴールを作ってから挑む」、
言い換えれば、「企画重視」の考え方をするほうが生き残りやすいのかも?
という考えで、私は今の状況を見ています。
ただし、「自分の力量」以上にこういった考えに縛られてしまうと息苦しくなるので、
取り入れるべき度合いは当人の能力や状況によって変わってくるはずです。
「なんでもそれなりに面白いものに仕上げられるようになったけど、何を作ればウケるんだろ」
くらいの気持ちを持っている人向けかもしれません。
『片道勇者』でもそうでしたが、「企画重視」のテーマは開発においては扱いが難しい、
大変なじゃじゃ馬になりやすいものだと思っています。
『片道勇者』も、その時点の私の能力を考えれば、
「たまたま運が重なったから一本として完成させられた」という危ういものでしたから。
<本職の人にとっては当たり前のことかも?>
なお企業さまなどにおいては、偉い人に企画を承認してもらう都合上、
「企画」という名の「面白そうに見えるゴール」を偉い人に見せてから
プロジェクトが始まることが多いのではないかなと思います。
そういう意味では、これは企業的な作り方の一部を取り入れた方法とも言えるかもしれません。
(企業さまにおいては、「売れるか否か」という判断もそこに入るのでしょうけれど)
一方、個人開発の私の場合だと「偉い人に承認してもらう」といった制約がないため、
「どうやれば興味を持ってもらえるものにできるか」を全く考えずに作ってしまって、
完成した後に「これどうやって面白そうに紹介するんだよ!」と悩んでしまうということを、
私は15年以上も繰り返してきてしまいました。
「自分が作りたいものを、可能な限り面白そうに見せるためのゴール」を最初に考えておくこと。
宣伝文句を考えたり、面白そうな画面写真を選ぶのに苦労する状況は、
どのみち作る前でも作った後でも必ず1回は遭遇するのですから、
後になって方針を変えにくい状況になってからそれを考えるよりは、
先に考えておいた方がいい未来に繋がるかもしれません。
【中盤:見た目をきれいにするのはやる気が減りそうなタイミングで】
以前、「ゲームを完成させる作り方」というのをご紹介しました。
それは「レベル1」で最低限の骨だけ作って、「レベル2」で肉付けして短編を完成させて、
「レベル3」で追加の実装を行う、という方法です。
ゲーム開発は最初から全ての素材が揃っている状態から始まるわけではなく、
必ず「グラフィックを良くする作業」、あるいは
「正式な画像を作成・導入する作業」がどこかに入ります。
そして「完成させるゲームの作り方」では、
「レベル1」では画像はサンプル画像でもラフ画でもよくて、
「レベル2」で本番の画像にする、という感じの話をしました。
そして、その「レベル2」内の部分的な工夫として最近考えているのが、
「本番画像を搭載する、立ち絵を清書し始める」などの「見た目をよくする作業」は、
レベル2の肉付け作業中の『気力が減ってきたあたり』で行うようにすることで、
開発中盤あたりの飽きを少し緩和しやすくなるのではないか。
ということです。というのも、「見た目をきれいにしていく作業」は、
「作る→見た目がよくなってやる気が上がる→作る→見た目がよくなってやる気が上がる」
の連鎖で、個人的にはものすごくモチベーションのブーストがかかる場所だと考えているからです。
ゆえに、そういった「おいしい部分」は最初から使い切らずになるべく温存しておいて、
やる気が下降気味になりそうなタイミングで少しずつ投入するのが
持続性の面で効率的かもしれない、と最近考え始めています。
グラフィックを良くする以外にも、あなたにとってやる気が回復しやすい作業があるなら、
それを部分的にでも温存しておくと、モチベーションの給水所として
役立てられるかもしれません。
だいたいの場合、私が無意識に開発を進めると「楽しい作業」を先にやりたがってしまって、
苦しい作業だけが後に残って絶望することが多いので、そんな苦労をするタイプの人には、
おいしいところを意識的に残しておくのは割と効果的な手段だと考えています。
【全編:絵は最後まで徐々にブラッシュアップし続けるよう作る】
これは主に、あなた自身が絵を作れる場合の話です。
個人制作の場合、ほぼまちがいなく、あなたは開発中に様々な面でレベルアップします。
「絵を描く能力」など、目で見て分かる力は特にそうで、
最初にしっかり仕上げて作ってみたつもりにも関わらず、
完成前になってちょっと変だと気付いてしまう場合が多々あります。
場合によっては、開発前半と後半で作ったキャラの絵のタッチが変わってたり、
あるいは上手下手が見て分かるほど差が付く場合さえあります。
だいたいの場合、こういう場面に遭遇すると後から全部修正したくなる気持ちになってしまい、
開発の満足度的な意味でかなりキツい状況に陥ります。
でも、年単位の開発においてはこういう状況はたびたび発生します。
私は、なんとかこういう状況を避けられないかなと考えていました。
そこで、やり方を変えて個人的に今のところうまくいきそうだと考えている方法が、
「絵の一つ一つを100%に仕上げて次に行く」のではなく、
「絵は一気に仕上げず、最後まで全てをまんべんなく
ブラッシュアップし続けるつもりで描く」ようにする方法でした。
やり方を整理すると、以下のような感じです。
1.最初は雑なキャラクターのラフを書いて、そのままゲームに導入する。
2.開発が進むにつれ、全キャラを『徐々に』ブラッシュアップしていく。変なところに気付いたら直す。
3.「仕上げ」をするのは開発が終わる直前あたりにする。
この方法には、以下のような利点があると考えています。
●あとあと精神的に楽になる。
1枚ずつ100%にしていって「一旦完成したもの」を
あとで描き直す状況に遭遇すると精神的にゲッソリしますが、
一方で「最後まで全部未完成にして、全て平均的にずっと微調整し続ける」
という前提で作業すると、終わり際だけでなく、その道中もだいぶ気が楽になります。
私の場合、時間が経てばどのみち過去の絵が下手に見えてくることは分かっているので、
「時間をかけて絵を良くしていけばいい」という環境にしておくことで、
未来の自分を恐れるストレスを感じにくくする効果がある気がしています。
そういったストレス源があると、気付かないうちに
モチベーションにもじわじわダメージを受けてしまいがちです。
さらには「今すぐうまく描けなくても、不安にならずにメインの仕事を進められる」
といった効果も得られるので、個人的にはこの点が助かっています。
●クオリティを均質にしやすい。
平均的にブラッシュアップしていくことで、
「一枚だけ気合を入れすぎて、他も同じように描けなくて苦労する状況」
が起きにくくなります。
言い換えれば、クオリティを均質にしやすくなる利点があると考えています。
これとは逆に「最大クオリティで仕上げた一枚に質を合わせる」ように
作ろうとしてしまうと、個人的には意外と大変です。
描く対象によってモチベーションが変わってくるのもあって、
普通はそうそう全部に対して最大に近いクオリティは出せないはずなんですが、
不慣れだった自分はなぜかピークの成果を出し続けられると思ってしまうのです。
そして、うまくいかないギャップで苦しむことになりました。
●新たな発見を取り入れやすい。
「描きかけの画像」があると、自分のセンサーが強化されやすいというのも利点だと思っています。
「いま若い男性キャラを描いてるんだけど、どうやったらかっこいい
細マッチョを描けるだろう、他の人はどう描いてるのかな?」とか、
「かわいい女の子キャラって、どこをどうすればかわいく見えるんだ?」など、
いま抱えている課題をよりよく解決するための情報に、より敏感になれる期待があります。
「未来の自分」を育てる価値が出てくる、とも言えるかもしれません。
一方で、「一つ一つを完成させてしまった」後によりすばらしい方法に気付きそうになった場合、
一度完成させたものを修正するコストは心理的にも非常に大きいので、
新たな発見から無意識的に目を逸らしてしまうかもしれません。割と私がそうです。
仮に「新たな発見」を受け入れるにしても、いちいち修正し続けると永遠に開発が終わらないので、
たいていは「よりよくできる可能性を知りながら無視し続ける」という、
かなりの精神力を消費する行為に挑戦することになりがちです。
だからこそ、「いま仕上げず、最後までいじってもいい」という前提のまま置いておくことは、
ストレスを低減させる大きな効果をもたらすのではないか、と考え始めています。
誰かと協力して開発している場合は、こういった方法はやりにくいかもしれませんが、
個人開発なら作りかけのものが大量にあってもそんなに困らないので、
これから試していきたいと考えている方法です。
ただ「作業の順番が変わるだけ」で、いずれはやることですからね。
私の中では、「完成品の絵をさらに作り直させたがる未来の自分」が
無意識のうちに『敵』のような存在になってしまっていて、
これまでも意志力で何度も殴り倒してきたのですが、だんだんと疲れてきました。
どうせなら今回のやり方のように、「未来の自分」と一緒に協力する方向性でやった方が
丸くおさまりそうかなと感じています。
【一定頻度:段階ごとに人に見せて方向性を確かめる】
ゲーム開発初期はテストプレイをお願いできる友達がいないことが多いので難しいのですが、
できれば「開発の各段階ごとに他人に見てもらう」ようにすると、色んなことが分かります。
これは以前の「楽しくて学べるゲームの作り方」の記事で述べた
「小さく作って、そのたびに見てもらう」やり方の「内輪版」とも言えます。
プロトタイプの段階でも、人に見せることで以下のことに気付く機会を得ることができます。
【中度】 インターフェースや分かりやすさの確認。
→ 初めての人にとって操作が直感的でない部分や、
ルールの分かりづらい部分を知ることができます。
特に、開発者側は「『初めての人にとって分からない部分』が分からない」ことが多いので、
貴重な情報になるはずです。
【中度】 難易度の確認。初めての人にも適正か?
→ 基準の難易度が適正かどうか、という点が早めに分かるでしょう。
開発者好みのバランスで作ると、意外と最初から難しくしてしまいがちです。
配信プレイでも、横で見てるのでも何でもいいのですが、実プレイの光景を生で見ていれば、
あまりに苦戦してイライラしている様子などを確認できる確率も高いので、
もしそうであれば想定するバランスの修正が必要でしょう。
【重大】 そもそもの方向性に問題がないか?
→ 自分が普通だと思っていたゲーム内容や操作は、
もしかしたら他人にとって非常にやりにくいものになっているかもしれません。
ゲームの「方向性」の善し悪しを、完成前に知ることができるのは重要です。
たとえば私の場合、『シルフドラグーンゼロ』の開発時、最初は操作しにくい
「エストック」の機体しかなかった状態のプロトタイプをテストしてもらったら、
「操作が直感的じゃなくてやりにくい」と言われたので、
分かりやすい操作性の「ギガント」と「ラプター」を追加したという経緯があります。
もし、テストしてもらって出たその指摘がなければ、
私は確実に「エストック」の機体のみでリリースしていたはずで、
まちがいなく遊ぶ人を選ぶゲームになってしまっていたでしょう。
完成後に「機体」を追加するなんてのは修正箇所が多すぎて大変でしょうから、
早期に方向性の問題に気づけたのはとても大きな収穫でした。
方向性の問題は、早く気づければ気づけるほど対応が容易になります。
<初めての人は大事>
それと「段階ごとに見てもらうとよい」と言いましたが、
もし残せるようなら「一度もプレイしていない人」を最後まで残しておくと後で助かります。
というのも、「ゲームのやり方が理解できない」と指摘してくれる可能性が
あるのは初見の人だけだからです。
一度見せれば初見ではなくなってしまうので、「初めて」の人は貴重です。
今なら、内輪での配信プレイもしてもらいやすいので、
身内で映像を流してもらいながらゲームを遊んでもらっているところを見て、
「自分が一切説明せずに遊べるか」などをチェックするとよさそうです。
そして遊ぶ人が分からずに困っているところに遭遇しら、きっと解説のために
あなたは口出しをしてしまうでしょうから、その「口出ししたところ」のタイミングで言ったことを、
そのままチュートリアルに追加することで、よりよいチュートリアルに仕上がっていくはずです。
また私の視点だと、「ゲームが下手な人」はもっといいです。
「知ってて当然」のことさえ知らない人にもやさしく教えられる、
あるいは遊べるゲームができれば、遊んでくれる人の幅も広がるでしょう。
一方で、「知ってる人ならチュートリアルを無視できる」ようにする配慮も大切です。
できる人とできない人、両対応した配慮をしていきたいです。
【リリース前:できれば余裕を持って終わる】
ゲーム開発は、「少し余裕を持ってリリースする」ことが非常に大事だと考えるようになりました。
なぜかというと、プレイ人数が一定以上確保できるゲームをリリースすれば、
ほとんどの場合、自分が気付かなかったゲームの問題点を、
リリースの直後からプレイヤーさんが指摘してくれるからです。
「ウディコン(私が開催しているゲームコンテスト)」で滑り込み投稿しておられる方などを見ると、
たまに地獄のような状況を目にすることがあります。
たとえばあなたが完全に疲れ切った状態で、「もうこれで開発の苦労から解放される……」と
思いながらゲームをリリースしたら、その直後から様々な報告が大量に届くのです!
数々のバグ報告! こうしてくれという要望、などなど!
ですが、あなたが身体的、精神的に限界オーバーしてるときにそれらを抱えてしまうと、
慣れない内は「あなたをこれ以上働かせようとする意見」の全てが
まるで敵のように見えてしまうことも多々あると思います。
真っ当なバグ報告や要望ですら、受け止める余裕がなくなって
「ア゙ア゙ア゙ア゙ー!!」と叫びたくなってしまうこともあるでしょう。
私にも、今でもたまにそう感じることがありますが、そういった心理面の問題の多くは、
「自分の残りの元気・気力が足りないこと」によって発生しがちです。
私の場合に限れば、ゆっくり休むことで心理面の問題は8割以上解消されると思っています。
とはいえ、冷静にそれらの問題点を指摘する意見を見たときに、
「明らかに直した方がよさそうなもので、かつあなたが直せるもの」なら、
修正しておいた方が、これから遊んでもらう人達にももっと喜んでもらえることでしょう。
早く直せれば直せるほど、その問題で被害を受けるプレイヤーさんも減るわけですからね。
もちろん、様々な事情を加味した上で大変そうなら後回しにするのも大切な判断ですが、
余裕がないほど退く判断をするのも難しくなってしまいます。
何かの拍子に爆発したり折れたりしてしまわないよう、
リリース前にはできれば「身体的・精神的な余力を残しておく」、なおかつ
「リリース後の何十日かくらいは、その対応に追われる覚悟をしておく」、
というのも大切なことだと、今の私は考えています。
今となっては、「リリースした一秒後からは、しばらく休むことはできないだろうな!」
くらいの覚悟でいる方が、たぶんうまく回るだろうと思うようになりました。
私の場合、ひどいケースだと、『片道勇者プラス』のときは
リリースしてからたった一ヶ月で1000行にも渡るバグ修正リストができてしまいました。
まさかそんなにたくさん直すことになるとは思っていませんでしたが、
これまでの開発の経験から、リリース直後から多くの問題報告が来ることは
なんとなく覚悟していましたので、心身が衰弱した状態で公開することだけは
なんとか避けようと当時の私は考えていました。
しかし、その心身の準備をしていても限界を一時オーバーしていましたからね!
とにかく、もしあなたが「リリースさえできれば解放される!」と考えて
今もボロボロになりながら開発を進めているのなら、
「実はリリース後の方が激しい戦争が始まる可能性がある」ということだけ
頭の隅に置いてくださると、万が一そうなった場合にショックを受けにくくなるかもしれません。
私もいまだに、大変さが最大想定を越える場合がたびたびあるので、
覚悟が不十分だと痛感しています。
なるべく無理しない程度に進められるのが一番ですが、
どんなときでも想定外の事態というのは発生してしまいます。
いつでも対応できるよう、できるかぎり余力を常に残しておきたいですね。
以上、「ゲーム開発で最近試していること色々」でした。いかがだったでしょうか。
あくまで私個人にとって有用だと考えている方法や心構えですが、
部分的にはお役に立てる内容もあるかもしれません。
ちなみに、今回述べた試みのほとんどは「順序を変える」という手段を取っています。
面白そうなゴールを「先」に考えるとか、見た目をきれいにするのは「後回し」にするとか、
絵は「最後まで徐々に」ブラッシュアップするなど、これらは
いずれやることを先に行ったり後回しにしたり薄く引き延ばしたりする形です。
基本的にこういった「順序の変更」だけなら新たなコストを大きくかけずに済むので、
少ない負担で取り入れられるのかなという印象があります。
ただ複数人で開発する場合だと、作業を分けたりすることで
管理のコストが増大したりする危険性があるので、そこは注意が必要ですが、
一人ならば管理コストの問題も起きにくいですしね。
他にも、「順序の変更」によって精神的に楽になったり、
より効率的になる部分がどこかに潜んでいるかもしれません。
ただでさえゲーム開発は苦しみが大きく、アウトプットに苦戦する場面も多々あるので、
自分の力を最大限に発揮できる開発順序を生み出せるよう、
今後も考えていきたいと思っています。
他にもし何か「こんな話題を聞いてみたい!」というお話がございましたら、
ぜひ拍手コメントからお送りください!
答えられそうなものはどんどんお答えしていきます。
今回は私が最近のゲーム開発で行っている、
自分にとって有効そうだと考えているいくつかの試みについて整理してみました。
私と似た悩みを抱えている人や、私に近いタイプの人には、
部分的に役立つ部分もあるかもしれません。
以下の項目だけ見て分かる方には、飛ばしてくださっても大丈夫だと思います。
●最初: 「面白そうに見えるゴール」を先に考えてから作る。
●中盤: 見た目をきれいにする作業はやる気が減りそうなタイミングに回す。
●全編: 絵は最後まで徐々にブラッシュアップし続けるよう作る。
●一定頻度: 段階ごとに人に見せて方向性を確かめる。
●リリース前: できれば余裕を持って終わる。

【最初:「面白そうに見えるゴール」を先に考えてから作る】
まず私は、「できるだけ多くの人に遊んでもらいたい」という欲求が強いのですが、
どうやれば自分の作ったゲームを知ってもらえるか考えるのに四苦八苦しています。
「作ったものを面白そうにアピールすること」がいかに困難か、何度も思い知らされました。
たとえば「自分にとってそこそこ自信のあるゲーム」ができあがったとき、
その完成品から「とても興味を惹かれるキャッチコピー」を考えるのは、
実はとても難しいことだと思っています。
実のところ、これまでの私のゲームを見直しても、
「分かりやすく興味を惹くキャッチコピー」が思いつかないゲームが結構あります。
たとえば『シルフェイド幻想譚』の場合、目新しい要素が実は少ないので
「ストレス少なめの時限フリーシナリオRPG!」くらいしか言えません。
コンテストに投稿したことによって目立つことができた面は大きいと思いますが、その他は
『シルフェイド』という名前が付いている、ということが実質的に最大のアピールポイントで、
作品の概要情報や、キャッチコピーが普及力に貢献できた部分はあまり大きくはないでしょう。
そんなわけで私は、基本的には『ブランド』に頼るアピールのみがメインで、
作品紹介による宣伝面ではかなり苦戦していると感じていました。
そこで、私はここ数年でこう考えるようになりました。
自分のような宣伝が苦手な人間にとって
「面白そうに感じさせるキャッチコピーや見た目」を考えることがボトルネックになるのなら、
その「一目で面白そうに感じる部分」を先に考えておいてから
ゲームを作った方が普及力を上げやすくなるのでは? と。
たとえば、以下のいずれかのような方法でゲームを作るのです。
●遊びたくなりそうな宣伝文句を先に考えて、それに合わせてゲームを作る。
●遊びたくなりそうな画面写真を先に考えてみて、それに合わせてゲームを作る。
●やたら興味をひかれる物語紹介だけ先に作って、それに合わせてゲームを作る。
これらは、私のような宣伝が苦手な人間には一定以上、効果が上げられるやり方かもしれません。
さっきも言いましたが、「完成済みのものを面白そうに紹介する」のは意外に大変です。
ある程度の開発能力を身に付けているなら、「作った後のもの」を面白そうに見せるより、
先に「面白そうに見える状態」を考えておいて、
それにたどり着けるものを作る方がたぶんいくらか簡単です。
特に「画面写真」は、作った後からではなかなか面白くいじりようがない!
「物語説明」もそうです。一度読んでみれば物語の内容自体はすごく面白いのに、
いざ「紹介用のあらすじ」を書いてみるとなかなか面白そうに書けない、
あるいは興味を惹くのに苦労する、といったことはないでしょうか?
私は、あらすじで興味を惹くことを意識していなかったので、そこで悩んだことが何度もありました。
こういった苦労があるのならいっそ、先に「面白そうに見せるためのゴール」を考えておいて、
チャンスがあればそれに近付ける、という作り方は一つの手です。
私の場合、『片道勇者』がその方法で生まれたもので、
最初に『強制横スクロールRPG!』という
「興味をひきそうな宣伝文句」が生まれて、そこから開発が始まりました。
思いついた時点では果たして面白くなるのか、
どんなジャンルのゲームになるかは全く分かりませんでしたが、
最終的には『強制横スクロールRPG』という期待を満たせる程度の作品に作りあげ、
目新しいキャッチコピーにより新鮮さを伝えることができたと考えています。
もしこれがただのローグライクRPG、あるいは説明が難しいローグライクRPGだったら、
見てもらえる人の数は今の半分以下や、1/4以下になったかもしれません。
もちろん、こういう作り方で失敗してしまう場合も当然あると思いますが、
今はどこへ出すにしても作品数が増えすぎて、
まず「少しでも興味を持ってもらえるかどうか」が
一番のネックになっているのではないか、と私は考えています。
そんな環境で少しでも目立てるようにすることを考えると、
上記のように先に「面白く見えるゴールを作ってから挑む」、
言い換えれば、「企画重視」の考え方をするほうが生き残りやすいのかも?
という考えで、私は今の状況を見ています。
ただし、「自分の力量」以上にこういった考えに縛られてしまうと息苦しくなるので、
取り入れるべき度合いは当人の能力や状況によって変わってくるはずです。
「なんでもそれなりに面白いものに仕上げられるようになったけど、何を作ればウケるんだろ」
くらいの気持ちを持っている人向けかもしれません。
『片道勇者』でもそうでしたが、「企画重視」のテーマは開発においては扱いが難しい、
大変なじゃじゃ馬になりやすいものだと思っています。
『片道勇者』も、その時点の私の能力を考えれば、
「たまたま運が重なったから一本として完成させられた」という危ういものでしたから。
<本職の人にとっては当たり前のことかも?>
なお企業さまなどにおいては、偉い人に企画を承認してもらう都合上、
「企画」という名の「面白そうに見えるゴール」を偉い人に見せてから
プロジェクトが始まることが多いのではないかなと思います。
そういう意味では、これは企業的な作り方の一部を取り入れた方法とも言えるかもしれません。
(企業さまにおいては、「売れるか否か」という判断もそこに入るのでしょうけれど)
一方、個人開発の私の場合だと「偉い人に承認してもらう」といった制約がないため、
「どうやれば興味を持ってもらえるものにできるか」を全く考えずに作ってしまって、
完成した後に「これどうやって面白そうに紹介するんだよ!」と悩んでしまうということを、
私は15年以上も繰り返してきてしまいました。
「自分が作りたいものを、可能な限り面白そうに見せるためのゴール」を最初に考えておくこと。
宣伝文句を考えたり、面白そうな画面写真を選ぶのに苦労する状況は、
どのみち作る前でも作った後でも必ず1回は遭遇するのですから、
後になって方針を変えにくい状況になってからそれを考えるよりは、
先に考えておいた方がいい未来に繋がるかもしれません。
【中盤:見た目をきれいにするのはやる気が減りそうなタイミングで】
以前、「ゲームを完成させる作り方」というのをご紹介しました。
それは「レベル1」で最低限の骨だけ作って、「レベル2」で肉付けして短編を完成させて、
「レベル3」で追加の実装を行う、という方法です。
ゲーム開発は最初から全ての素材が揃っている状態から始まるわけではなく、
必ず「グラフィックを良くする作業」、あるいは
「正式な画像を作成・導入する作業」がどこかに入ります。
そして「完成させるゲームの作り方」では、
「レベル1」では画像はサンプル画像でもラフ画でもよくて、
「レベル2」で本番の画像にする、という感じの話をしました。
そして、その「レベル2」内の部分的な工夫として最近考えているのが、
「本番画像を搭載する、立ち絵を清書し始める」などの「見た目をよくする作業」は、
レベル2の肉付け作業中の『気力が減ってきたあたり』で行うようにすることで、
開発中盤あたりの飽きを少し緩和しやすくなるのではないか。
ということです。というのも、「見た目をきれいにしていく作業」は、
「作る→見た目がよくなってやる気が上がる→作る→見た目がよくなってやる気が上がる」
の連鎖で、個人的にはものすごくモチベーションのブーストがかかる場所だと考えているからです。
ゆえに、そういった「おいしい部分」は最初から使い切らずになるべく温存しておいて、
やる気が下降気味になりそうなタイミングで少しずつ投入するのが
持続性の面で効率的かもしれない、と最近考え始めています。
グラフィックを良くする以外にも、あなたにとってやる気が回復しやすい作業があるなら、
それを部分的にでも温存しておくと、モチベーションの給水所として
役立てられるかもしれません。
だいたいの場合、私が無意識に開発を進めると「楽しい作業」を先にやりたがってしまって、
苦しい作業だけが後に残って絶望することが多いので、そんな苦労をするタイプの人には、
おいしいところを意識的に残しておくのは割と効果的な手段だと考えています。
【全編:絵は最後まで徐々にブラッシュアップし続けるよう作る】
これは主に、あなた自身が絵を作れる場合の話です。
個人制作の場合、ほぼまちがいなく、あなたは開発中に様々な面でレベルアップします。
「絵を描く能力」など、目で見て分かる力は特にそうで、
最初にしっかり仕上げて作ってみたつもりにも関わらず、
完成前になってちょっと変だと気付いてしまう場合が多々あります。
場合によっては、開発前半と後半で作ったキャラの絵のタッチが変わってたり、
あるいは上手下手が見て分かるほど差が付く場合さえあります。
だいたいの場合、こういう場面に遭遇すると後から全部修正したくなる気持ちになってしまい、
開発の満足度的な意味でかなりキツい状況に陥ります。
でも、年単位の開発においてはこういう状況はたびたび発生します。
私は、なんとかこういう状況を避けられないかなと考えていました。
そこで、やり方を変えて個人的に今のところうまくいきそうだと考えている方法が、
「絵の一つ一つを100%に仕上げて次に行く」のではなく、
「絵は一気に仕上げず、最後まで全てをまんべんなく
ブラッシュアップし続けるつもりで描く」ようにする方法でした。
やり方を整理すると、以下のような感じです。
1.最初は雑なキャラクターのラフを書いて、そのままゲームに導入する。
2.開発が進むにつれ、全キャラを『徐々に』ブラッシュアップしていく。変なところに気付いたら直す。
3.「仕上げ」をするのは開発が終わる直前あたりにする。
この方法には、以下のような利点があると考えています。
●あとあと精神的に楽になる。
1枚ずつ100%にしていって「一旦完成したもの」を
あとで描き直す状況に遭遇すると精神的にゲッソリしますが、
一方で「最後まで全部未完成にして、全て平均的にずっと微調整し続ける」
という前提で作業すると、終わり際だけでなく、その道中もだいぶ気が楽になります。
私の場合、時間が経てばどのみち過去の絵が下手に見えてくることは分かっているので、
「時間をかけて絵を良くしていけばいい」という環境にしておくことで、
未来の自分を恐れるストレスを感じにくくする効果がある気がしています。
そういったストレス源があると、気付かないうちに
モチベーションにもじわじわダメージを受けてしまいがちです。
さらには「今すぐうまく描けなくても、不安にならずにメインの仕事を進められる」
といった効果も得られるので、個人的にはこの点が助かっています。
●クオリティを均質にしやすい。
平均的にブラッシュアップしていくことで、
「一枚だけ気合を入れすぎて、他も同じように描けなくて苦労する状況」
が起きにくくなります。
言い換えれば、クオリティを均質にしやすくなる利点があると考えています。
これとは逆に「最大クオリティで仕上げた一枚に質を合わせる」ように
作ろうとしてしまうと、個人的には意外と大変です。
描く対象によってモチベーションが変わってくるのもあって、
普通はそうそう全部に対して最大に近いクオリティは出せないはずなんですが、
不慣れだった自分はなぜかピークの成果を出し続けられると思ってしまうのです。
そして、うまくいかないギャップで苦しむことになりました。
●新たな発見を取り入れやすい。
「描きかけの画像」があると、自分のセンサーが強化されやすいというのも利点だと思っています。
「いま若い男性キャラを描いてるんだけど、どうやったらかっこいい
細マッチョを描けるだろう、他の人はどう描いてるのかな?」とか、
「かわいい女の子キャラって、どこをどうすればかわいく見えるんだ?」など、
いま抱えている課題をよりよく解決するための情報に、より敏感になれる期待があります。
「未来の自分」を育てる価値が出てくる、とも言えるかもしれません。
一方で、「一つ一つを完成させてしまった」後によりすばらしい方法に気付きそうになった場合、
一度完成させたものを修正するコストは心理的にも非常に大きいので、
新たな発見から無意識的に目を逸らしてしまうかもしれません。割と私がそうです。
仮に「新たな発見」を受け入れるにしても、いちいち修正し続けると永遠に開発が終わらないので、
たいていは「よりよくできる可能性を知りながら無視し続ける」という、
かなりの精神力を消費する行為に挑戦することになりがちです。
だからこそ、「いま仕上げず、最後までいじってもいい」という前提のまま置いておくことは、
ストレスを低減させる大きな効果をもたらすのではないか、と考え始めています。
誰かと協力して開発している場合は、こういった方法はやりにくいかもしれませんが、
個人開発なら作りかけのものが大量にあってもそんなに困らないので、
これから試していきたいと考えている方法です。
ただ「作業の順番が変わるだけ」で、いずれはやることですからね。
私の中では、「完成品の絵をさらに作り直させたがる未来の自分」が
無意識のうちに『敵』のような存在になってしまっていて、
これまでも意志力で何度も殴り倒してきたのですが、だんだんと疲れてきました。
どうせなら今回のやり方のように、「未来の自分」と一緒に協力する方向性でやった方が
丸くおさまりそうかなと感じています。
【一定頻度:段階ごとに人に見せて方向性を確かめる】
ゲーム開発初期はテストプレイをお願いできる友達がいないことが多いので難しいのですが、
できれば「開発の各段階ごとに他人に見てもらう」ようにすると、色んなことが分かります。
これは以前の「楽しくて学べるゲームの作り方」の記事で述べた
「小さく作って、そのたびに見てもらう」やり方の「内輪版」とも言えます。
プロトタイプの段階でも、人に見せることで以下のことに気付く機会を得ることができます。
【中度】 インターフェースや分かりやすさの確認。
→ 初めての人にとって操作が直感的でない部分や、
ルールの分かりづらい部分を知ることができます。
特に、開発者側は「『初めての人にとって分からない部分』が分からない」ことが多いので、
貴重な情報になるはずです。
【中度】 難易度の確認。初めての人にも適正か?
→ 基準の難易度が適正かどうか、という点が早めに分かるでしょう。
開発者好みのバランスで作ると、意外と最初から難しくしてしまいがちです。
配信プレイでも、横で見てるのでも何でもいいのですが、実プレイの光景を生で見ていれば、
あまりに苦戦してイライラしている様子などを確認できる確率も高いので、
もしそうであれば想定するバランスの修正が必要でしょう。
【重大】 そもそもの方向性に問題がないか?
→ 自分が普通だと思っていたゲーム内容や操作は、
もしかしたら他人にとって非常にやりにくいものになっているかもしれません。
ゲームの「方向性」の善し悪しを、完成前に知ることができるのは重要です。
たとえば私の場合、『シルフドラグーンゼロ』の開発時、最初は操作しにくい
「エストック」の機体しかなかった状態のプロトタイプをテストしてもらったら、
「操作が直感的じゃなくてやりにくい」と言われたので、
分かりやすい操作性の「ギガント」と「ラプター」を追加したという経緯があります。
もし、テストしてもらって出たその指摘がなければ、
私は確実に「エストック」の機体のみでリリースしていたはずで、
まちがいなく遊ぶ人を選ぶゲームになってしまっていたでしょう。
完成後に「機体」を追加するなんてのは修正箇所が多すぎて大変でしょうから、
早期に方向性の問題に気づけたのはとても大きな収穫でした。
方向性の問題は、早く気づければ気づけるほど対応が容易になります。
<初めての人は大事>
それと「段階ごとに見てもらうとよい」と言いましたが、
もし残せるようなら「一度もプレイしていない人」を最後まで残しておくと後で助かります。
というのも、「ゲームのやり方が理解できない」と指摘してくれる可能性が
あるのは初見の人だけだからです。
一度見せれば初見ではなくなってしまうので、「初めて」の人は貴重です。
今なら、内輪での配信プレイもしてもらいやすいので、
身内で映像を流してもらいながらゲームを遊んでもらっているところを見て、
「自分が一切説明せずに遊べるか」などをチェックするとよさそうです。
そして遊ぶ人が分からずに困っているところに遭遇しら、きっと解説のために
あなたは口出しをしてしまうでしょうから、その「口出ししたところ」のタイミングで言ったことを、
そのままチュートリアルに追加することで、よりよいチュートリアルに仕上がっていくはずです。
また私の視点だと、「ゲームが下手な人」はもっといいです。
「知ってて当然」のことさえ知らない人にもやさしく教えられる、
あるいは遊べるゲームができれば、遊んでくれる人の幅も広がるでしょう。
一方で、「知ってる人ならチュートリアルを無視できる」ようにする配慮も大切です。
できる人とできない人、両対応した配慮をしていきたいです。
【リリース前:できれば余裕を持って終わる】
ゲーム開発は、「少し余裕を持ってリリースする」ことが非常に大事だと考えるようになりました。
なぜかというと、プレイ人数が一定以上確保できるゲームをリリースすれば、
ほとんどの場合、自分が気付かなかったゲームの問題点を、
リリースの直後からプレイヤーさんが指摘してくれるからです。
「ウディコン(私が開催しているゲームコンテスト)」で滑り込み投稿しておられる方などを見ると、
たまに地獄のような状況を目にすることがあります。
たとえばあなたが完全に疲れ切った状態で、「もうこれで開発の苦労から解放される……」と
思いながらゲームをリリースしたら、その直後から様々な報告が大量に届くのです!
数々のバグ報告! こうしてくれという要望、などなど!
ですが、あなたが身体的、精神的に限界オーバーしてるときにそれらを抱えてしまうと、
慣れない内は「あなたをこれ以上働かせようとする意見」の全てが
まるで敵のように見えてしまうことも多々あると思います。
真っ当なバグ報告や要望ですら、受け止める余裕がなくなって
「ア゙ア゙ア゙ア゙ー!!」と叫びたくなってしまうこともあるでしょう。
私にも、今でもたまにそう感じることがありますが、そういった心理面の問題の多くは、
「自分の残りの元気・気力が足りないこと」によって発生しがちです。
私の場合に限れば、ゆっくり休むことで心理面の問題は8割以上解消されると思っています。
とはいえ、冷静にそれらの問題点を指摘する意見を見たときに、
「明らかに直した方がよさそうなもので、かつあなたが直せるもの」なら、
修正しておいた方が、これから遊んでもらう人達にももっと喜んでもらえることでしょう。
早く直せれば直せるほど、その問題で被害を受けるプレイヤーさんも減るわけですからね。
もちろん、様々な事情を加味した上で大変そうなら後回しにするのも大切な判断ですが、
余裕がないほど退く判断をするのも難しくなってしまいます。
何かの拍子に爆発したり折れたりしてしまわないよう、
リリース前にはできれば「身体的・精神的な余力を残しておく」、なおかつ
「リリース後の何十日かくらいは、その対応に追われる覚悟をしておく」、
というのも大切なことだと、今の私は考えています。
今となっては、「リリースした一秒後からは、しばらく休むことはできないだろうな!」
くらいの覚悟でいる方が、たぶんうまく回るだろうと思うようになりました。
私の場合、ひどいケースだと、『片道勇者プラス』のときは
リリースしてからたった一ヶ月で1000行にも渡るバグ修正リストができてしまいました。
まさかそんなにたくさん直すことになるとは思っていませんでしたが、
これまでの開発の経験から、リリース直後から多くの問題報告が来ることは
なんとなく覚悟していましたので、心身が衰弱した状態で公開することだけは
なんとか避けようと当時の私は考えていました。
しかし、その心身の準備をしていても限界を一時オーバーしていましたからね!
とにかく、もしあなたが「リリースさえできれば解放される!」と考えて
今もボロボロになりながら開発を進めているのなら、
「実はリリース後の方が激しい戦争が始まる可能性がある」ということだけ
頭の隅に置いてくださると、万が一そうなった場合にショックを受けにくくなるかもしれません。
私もいまだに、大変さが最大想定を越える場合がたびたびあるので、
覚悟が不十分だと痛感しています。
なるべく無理しない程度に進められるのが一番ですが、
どんなときでも想定外の事態というのは発生してしまいます。
いつでも対応できるよう、できるかぎり余力を常に残しておきたいですね。
以上、「ゲーム開発で最近試していること色々」でした。いかがだったでしょうか。
あくまで私個人にとって有用だと考えている方法や心構えですが、
部分的にはお役に立てる内容もあるかもしれません。
ちなみに、今回述べた試みのほとんどは「順序を変える」という手段を取っています。
面白そうなゴールを「先」に考えるとか、見た目をきれいにするのは「後回し」にするとか、
絵は「最後まで徐々に」ブラッシュアップするなど、これらは
いずれやることを先に行ったり後回しにしたり薄く引き延ばしたりする形です。
基本的にこういった「順序の変更」だけなら新たなコストを大きくかけずに済むので、
少ない負担で取り入れられるのかなという印象があります。
ただ複数人で開発する場合だと、作業を分けたりすることで
管理のコストが増大したりする危険性があるので、そこは注意が必要ですが、
一人ならば管理コストの問題も起きにくいですしね。
他にも、「順序の変更」によって精神的に楽になったり、
より効率的になる部分がどこかに潜んでいるかもしれません。
ただでさえゲーム開発は苦しみが大きく、アウトプットに苦戦する場面も多々あるので、
自分の力を最大限に発揮できる開発順序を生み出せるよう、
今後も考えていきたいと思っています。
他にもし何か「こんな話題を聞いてみたい!」というお話がございましたら、
ぜひ拍手コメントからお送りください!
答えられそうなものはどんどんお答えしていきます。
← 今回のような記事を 1冊の本にまとめたゲーム開発本、 『ゲーム開発者の地図』、 Kindleで好評発売中です! |
| 開発日誌トップ |