デバッグの仕方
デバッグモンキーズのSunnyです。
この記事は、上記、I was gameさんの主催のAdvent Calendar の記事です。
だいぶ時間が経ってしまいました。申し訳ないです。
遅ればせながら参加いたします。よろしくお願い致します。
デバッグモンキーズのデバッグの仕方。
何を書こうと思ったんですが、やはりサークル名にあるデバッグの話をするのが一番メッセージが出せるかなと思い、書いています。
デバッグとは？
元はコンピュータの開発環境での言葉だと思いますが、僕らはゲームを良くしていくために改変していくことをデバッグと呼んでいます。
この時、改良になっているかどうかは、そのデバッグでの成果に依存します。
「予想する反応が得られたか？」「不具合はどんな感じか？」「予想できなかった事象は？」などと、様々な問いに対して総合的に考えて行ったデバッグが良かったかを評価します。
その評価に応じて、このゲームをどうするか？を考えていきます。
デバッグの指針について
デバッグするにあたってゲームをどうしたいのか？という指針が大事になると思うのですが
僕らがよく話すのは「その体験のコアは何か？」ということです。
これがあれば、どうするべきかが、見えてくる気がします。
体験のコアとは、「どういうことをユーザーにさせたいのか？」ということです。
ゲームは様々なフェーズで出来上がるかと思いますが、その組み合わせで、「本当にさせたいことがおざなりになってないか？」というのを考えます。
例えば、冒険をして魔王を倒すというゲームを作る時、倒すという行為がコアなのか？育て上げる行為がコアなのか？などによってアプローチが変わるはずです。
極端な話、30分程度のゲームで、コア以外が占める時間的割合、感情的割合が多い場合は、させたいことができてるかと言うと怪しいですよね。
そして裏返すとこれは、「自分がどうしたいか？」という問いにもなり、より自分の軸がはっきりしてきます。
なので、自分がどうしたいか、がわかっていれば、させたいことは見えてくるはずです。
この方針に基づいて、デバッグを行っていきます。
デバッグの方法は「量か質か」
デバッグの方法として、有識者問わずたくさんテストプレイを回すのがいいのか、有識者に少なくテストプレイするのがいいのか、みたいな「量か質か」みたいな問いが結構あると思うんですけど
僕ら的には、開発初期は少なく質の高いテストプレイ 、開発の後期は多くの量のテストプレイ、だと思っています。
なぜかと言うと、開発初期は上に書いた「させたいこと」「やりたいこと」が不明確だったり、弱かったりすると思うからです。
やっていきながら、やっぱこっち！とか、ゲームの方針も変わってくるはずで、開発初期はそこがまだ完全に決定するのは難しいと。
(最初から強固にできる人はこの限りではないです)
(言い方はあれですが)詰めが甘い段階でたくさんの人にテストプレイして、フィードバックもらってもゲームでそれを消化しきれないと思ってます。
考え切れていないことをテストプレイ会のタイミングで考えて答えを出すのは、かなりリスクだと思います。
なんやなんやフィードバックをもらい、意図したことやされてないことを言われるはずなので、精神的にドキドキしてるはずなので、
この精神衛生で適切な答えを見つけるのは難しいと考えてます。
ましてや、そのフィードバックの量が多かったら、詰めの甘さに愕然とし、最初に挫折しちゃうと思います。
適切なタイミングで適切な量と質のフィードバック。
これが大事だと思います。
とりあえず、テストプレイ！というのは、よほどやりたいことが明確じゃない限りおすすめできないです。
なんでこれを言うかというと、ボードゲーム同人界隈においては、商業向けや趣味など違う属性の人が同居していて、得られるフィードバックも性質が違うはずなので、適切な精神衛生を保とうという話です。
デバッグの注意事項は？
デバッグの方針や方法を話したところで注意事項です。
ここではシンプルに書きます。
作り手は、フィードバックにへこまずに、選びましょう
色んな意見をきっと聞くはずです。その１つ１つに真摯に取り組むべきですが、選ぶものは選びましょう。
優先順位をつけましょう。
これはなんでかっていうと、自分が選んでいかないと、責任を自分でとれないからなんですよね。
「相手に言われたからこうした」で仮に思ったような売り上げだったり反応にならなかったりして、その時にきっと、その相手は何も助けてくれないと思います。（いい意味で）
てなると、行き場のない悲しみがたまるだけで、精神衛生はよくないと思います。
自分の中で納得感/責任感をしっかり持って作るために、選ぶ。
その軸は上に書いた、「ユーザーに何をさせたいか」「自分は何がしたいか」です。
何度も書きますが、同人ボードゲーム制作において、精神衛生をよく保ちながら、楽しく作れるような環境を構築できるといいなって思います。
まとめ
１：デバッグとは改変すること
２：デバッグするときは、「ユーザーに何をさせたいか？」を軸に
３：デバッグは、開発初期は「質は高く」、開発後期は「数を多く」
４：デバッグでは、へこまず、意見を選ぶ
お忙しいところ恐縮ですが、よろしくお願いいたします。
このような内容は頑張って続けていきます。