ルールを書き直すのではなくソルバーを借りる
デモが製品のロジックを必要とするとき、本物のコードを取り込むほうが、その簡略版を書き直すより安全か。
·
ブラウザのデモは普通、見た目が正しくなるのにちょうど足りるだけ製品を再実装します。それは、製品の面白い部分が「説明は簡単で、正しく作るのは難しいルール」になるまでは問題ありません。その時点で、書き直しは宣伝している対象の劣った版をひそかに出荷してしまいます。
Glow Garden はまさにその例です。そのルールはパズルの定型文のように読めます。各行、各列、各色の領域にホタルを一匹、どれも隣接しない。しかしゲームは配置をそのルールに照らして確認していません。盤がまだ完成可能かをソルバーに尋ね、できないならタップを拒否します。つまり、ある配置は単独では合法でありながら却下されうるのです。それがこのゲームを恣意的ではなく公正に感じさせているものであり、まさに書き直しが平坦にしてしまう繊細さです。
そこで書き直すのではなく、ルールの中核をアプリから無改変で複製し、そのハッシュを記録し、その前に型付きの境界を置きました。元のコードがいつか乖離すればビルドが壊れるようにするためです。同じやり方はその後、Veyra のステンシル関数にも通用しました。
分かったこと
ここまでに分かったこと。
- 01
複製する価値のある部分は、複雑に見える部分であることはまれです。それらしい再実装が繊細にまちがっていて、しかも誰も気づかない部分です。
- 02
取り込みには複製だけでなく境界が必要です。借りたコードの前に手で書いた型付きの面があることが、「乖離した」を静かな挙動の変化ではなく失敗したビルドに変えます。
- 03
ロジックがすでに純粋な場所でしか通用しません。きれいに移植できた二つの部品はどちらも import を持たず、下にフレームワークもありませんでした。これはそう書くことで得られる性質であり、あとから願って得られるものではありません。
- 04
固定した盤でも、本物の生成器の保証は必要です。デモの盤は手で描いて期待するのではなく、解がちょうど一つの盤が現れるまでアプリ自身のソルバーで探しました。
動いているところを見る
ルール判定は Glow Garden 自身のコードで、無改変で取り込んでいます。盤面を解けなくする配置を拒否するソルバーも含みます。盤面は生成ではなく固定で、同じソルバーで解がちょうど 1 つのものが見つかるまで探索しました。