ボードゲームをテストプレイするときの作業量を減らしたい

テストキットを作るタイミングというか、手順によく悩みます。

ゲーム完成までの作業量を少なくしたい気持ちは当然ありまして、具体的に言うと例えばテストキットを調整のたびに作り替えるのは内容物が多いほど手間が増えるし、システムが一旦完成してから正式なグラフィックを作って再度UIテストにかけるのも大変だし、なんならグラフィックを変えたことで表面化する問題やそのタイミングで偶然見つかるバグもあるし、どのタイミングで何を作ってどうテストするのが最適なの？　とうだうだ悩んでいます。

---

基準のひとつとしては、手間をかけてポシャるのは嫌だ、というのが考えられます。
これは妥当ですよね。アイデアの時点でテンションぶち上がって絶対名作になるって確信してめっちゃ気合入れたテストキットVer.01を作って、いざテストしてみたら感想タイムで誰も何も言わなくて色々察しちゃったけど無意識にサンクコストを引きずって何度も微調整入れてはテスト会に持っていって気づけば3年半、あれ、てかこれもうエタってるよね知ってたけど、みたいなことは誰だってやりたくないんです。俺は嫌だ。

ですから、「初期開発コストは低く抑えておいて、ダメだと判断したら早期に撤退して次のアイデアに取り掛かれるようにする」のは、開発手法として必要なことです。つまり最初のテストキットは簡素にしておいて、説明書も苦手なら無理に書かず箇条書きで済ませて（私は逆に最初から説明書を製品レベルで書いて後をラクにします）、初期テスト結果が微妙だったときに捨てる決断をしやすくする。時間的にも精神的にも負荷が減ります。そうしてある程度ゲームが固まってきたら、またはルールが完成したら、初めて製品版のグラフィックに移行する。

この方法は初期コストを低く抑えられる一方で、冒頭に述べたような問題もあります。先に「システムが一旦完成してから正式なグラフィックを作って再度UIテストにかけるのも大変だし、なんならグラフィックを変えたことで表面化する問題やそのタイミングで偶然見つかるバグもある」と書いたとおり、内容物とそのグラフィックにもテストは必要です。箱を開けたときに内容物は分類しやすいか、カードのインデクスや色や情報の視認性はどうか、ボードはどうか、コマは取り回しやすいか、コンポーネント設計がゲームシステムに悪影響を及ぼさないか、等。

ルールのテストを何度もやった後でUIテストをまたやるのって二度手間じゃないです？　グラフィック変えて説明書もきちんとDTPしたら初めて問題に気づくとか入稿後に見つかる誤植並によくありますよね？　それと皆さまご存じのとおりテスターはどれだけ慣れててもグラフィックに引きずられるもので、テストキットのUIがある程度整ってないとプレイ時間やルール理解に影響が及ぶためシステム／メカニクス本体に焦点を当てたテストになってるかどうか分からない、ということも避けたいじゃないですか？

そう考えると、もうひとつの基準というか方針として「初期段階からグラフィックも完成品に近いものを持ってきて、UIテストもまとめてやってしまう」ことも十分考えられます。初期コストがある程度高くつきますが、開発の早期に作業のレバレッジをかけておいて後工程を楽にすることで、結果として全体の作業コストを減らすという方向性です。作業量を減らすという目的からすれば、これも理に適っています。

---

ここまでは、初期段階の作業量を少なくするか多くするか、という対立軸を考えてきました。で、ご承知のとおり、これは概念モデルにすぎません。正解があるわけではなく、実作業ではこの中間や折衷も可能だし、作る当人のスキルによって最適な進め方は変わります。

軸の一端には「最初から製品に近いテストキットを用意して、ルールブックも完成品に近いものにする」という方針があり、他端には「極力簡易なテストキットでルールの回り方や面白さをまずチェックして、完了したら初めてグラフィック工程に入る」という方針があります。どちらの場合もここまで振り切った制作をしてる人はあまりいないはずで、大体は切り替えポイントを中間のどこかに置いたり、内容物を少しずつブラッシュアップしたりしていくはずです。

ですから、最初に書いた私の悩みは結局私自身のスキルセットと込み込みでしか答えが出ないものだし、そのスキルセットも年々変わってゆくから工程も随時見直してゆくのがベターです。
私は絵がほぼ描けないので、同人活動を始めたころはExcelとWordでゲームデータを作ってましたし、今もジップロックゲームでそういう作り方をする時はあります。一方で何作か完成させるとGIMPやインデザやイラレも少しは触るもので、最初から入稿データを意識したグラフィックを作ることもできるようになりました。
説明書だけは最初からわりと書けたので、製品レベルの文章をWordで書いてテストと調整を通して文章校正を並行するやり方をずっと変えていません。文章を書くコストは私にとって低く、ルールだけでポシャらせるなら撤退しやすいです。

結局いま悩んでいるのは、(1) テストキットのグラフィックを早めに、かつ低コストで入稿データへ移行しやすいよう作るにはどのツールでどう作るのがいいか、(2) 入稿データを意識するのは初回テストからなのか初回で好感触を得た後なのか（でも初回からいいグラフィックのほうがテストのフィードバックも良いのでは？）、(3) 絵は完成品を前提したものを自分で描くか素材で用意するかすべきなのか、という3点です。
グラフィックの技術がない私にとっては(1)が特に問題で、ここを細かく分解して方法に落とし込み、初期開発コストを捨てても耐えられる程度に低くしつつUIチェックを早く行えるようにすれば、だいぶテストの敷居が下がるんじゃないかなと期待してます。たぶん最初からイラレで作るのが正解なんだろうな……だからイラレを使い慣れる必要があるのか……。

目下の問題はそんな感じです。テスト可能なルールが書けてるゲームアイデアだけで10個ぐらいある（面白いとは言ってない）ので取捨選択ができてないとか、テストの場をどうセッティングするかも悩むよねとか、そもそも週末が6歳年長さんの世話で終わるとか、そのへんはまたほかの機会に話します。