現在は情報がまだ不確定すぎるチップを除き、最低限の機能を入れた状態。

いくばくか、開発の際に得られた話を。
普通に使う分には必要な話ではないので、物好きな開発者向け。

規模と必要資源

作業者は純粋に1人のみ。1人日＝8時間換算。

規模としてはデータ部を除き4000行ほど、HTMLエレメント生成を除外した更に純粋なロジック部としても3600前後、共通モジュールとして設計した部分を更に削除して3300行前後。
それほど切り詰めた書き方をしない反面、今回はコメントを少なめにするという方向を試したので極端に長いあるいは短い例ではないと思う。

開発日数としては基本部分作成に6から7人日。データ分析、設計、データ部投入、試験を含む。
上記の4000行というのはこの6人日前後の段階ではなくて、基本部分だけならば確か2400行前後だった覚えがある。

意外と馬鹿にならないのがデータ投入で、これだけで1時間単位がかかった。この時点でデータ構造の間違いを発見してしまうこともある。全パーツ全武器を投入する場合、合計で1人日程度かかると見てよい。

設計方針

特に語るほどの物はなくごく普通の作りであり、あまり語ることはない。

強いて言うならば、例えば武器威力でショットガンならば散弾数とダメージを分割してデータで持つなど、割と面倒な方式にしている程度。これは今後のチップで細かいカスタマイズに対応するため。
当然、コーディングのコストも増加傾向にあるのだが、これは必要だと思っている。

手戻り、あるいはバックトラック

チップ関連の仕様を入れ込むために設計を再度考えなければならない場面があった。ただ、これは事前に練り込むのと捨てること前提の試作品を使う場合のどちらが良いかは安易に結論を出せない。
トータルコストがどちらが上か、という視点で考えたほうが良いと思われる。

意外にもロジックレベルでの手戻りはほとんどない。他のパラメータに干渉する部分こそが肝であるもののデータレイヤー自体は同一で、普通、最も問題を起こす異なるデータ層境界を持たないことが理由ではないだろうか。

データ分析は特段の問題なく、現在に至る。外部から見た場合に、深さ優先と幅優先にも似た設計方向の選択があるが（※1）これは気の迷いだった。
結局は現在の単純な方向で直接扱ってしまったほうがよいというのが現在のところの実感。
ただし、これは後から再度検討しての話であり、データ分析の手法、方向としての解を見つけたということではないことに注意。

（※1）
例えば機体パーツならば「ブランド」（クーガーなど）の下に各パーツを置き、更に階層化したほうが良いのでは、という話も素朴な案の一つとしてありうる。
実際、内部ID（URLにセーブデータとしてくっついてるあれだ）はいずれ1桁では足りなくなるので、最初から階層型にして2桁を振った方が「その部分は」統一はされる。
結局は処理の際に毎回階層構造を扱うのはおかしく、IDと構造の一致という怪しげなメリット程度しかないので、気の迷いを起こしただけとしてこの案は放棄。今のところ選択として間違っているとは思っていない。

パフォーマンス

あまりに極端な物は除き、基本的には何もチューニングしていない。
jQueryはかなり優秀で、selectorさえちゃんと検討しておけばそうそう問題は起きないだろう。
参考までに、クーガーNXで機体パーツは45種類。パーツ一覧表は初回読み込み時のみ描画、並び替えはカスタムのsortを使用。1行に表示する要素数からパフォーマンスの見込みとして実用レベルの検討は付くと思う。

ただ、別のシステムでたかだかセル数300程度のものでありながら軽く数秒は処理を必要とする（※1）事例があった。木構造をトラバースし、要素下のテキストを順次取得、整形…といった流れで何かパフォーマンスを落とす組み方になる事があるようだ。危険な谷（※2）が存在しないか注意を払う必要がある。

（※1）
CPUはCorei7-920、IEとFirefoxで試験。

（※2）
一定量のデータまでは問題なく動作する物が、ある点を境に極端にパフォーマンスが落ちること。試験段階では少量のデータで動作していたものが開発後半のストレステストで露見し、データフローまで見直す必要が出たりする。

アクセス

試作段階ということもあり、全くと言っていいほど宣伝していないため全然使われていない。
と言っても、アクセス解析すらつけていないので推測だが。
正直に言えば、手遊びであるしアクセス数なりにあまり興味が湧かない。