Diary/2009年06月02日/【制作】キャラチップエディタ_ver0.2 - Akasin_Room

#blognavi

という訳で、ver0.2完成。
[ ペーパードール組み合わせエディタ_ver0.2 ]

変更点は以下の通り。

• 胴体部分の項目追加(body2,body3)
• 画像出力形式の変更（出力画像のサイズを36x36に。加え結合画像の出力も追加）
• 表示深度の任意設定機能の追加

あと何となく、名前を変更してみる。

それぞれの機能追加、修正に要した時間は以下の通り

• 胴体部分の項目追加　：1h
• 画像出力形式の変更　：1h
• 表示深度の任意設定機能の追加　：5h

表示深度の変更に無駄に時間がかかりました(´・ω・)
原因は、初期の設計の甘さ。

具体的には、「部位」が持つ「値」が追加されることを前提に
設計を行わなかったこと。
（部位：head,body等のペーパードールを構成する1部分のこと）

ver0.1の状態では、部位が持つ値は、「キャラチップ番号」のみ。
そのため、その「キャラチップ番号」を表す変数だけを扱えばよかった。
具体的には、キャラチップ番号を配列で管理していた。（部位ごとの値を管理）

ところが、ver0.2で「表示深度」の情報が追加されたため、
キャラチップの番号と共に、もう一つ扱う情報が出現してしまった。
ここで出てくる改修方法は2つ。
　案１．キャラチップの番号の配列と並んで、表示深度の配列を用意する
　案２．「部位」を表すクラスを用意し、そのクラスにキャラチップ番号と表示深度の値を持たせる
　　　　そして「部位を表すクラス」を配列で管理する

部位が持つ値というものが、このソフトの根幹を担う要素であるため、どちらの方法にせよ、
広い範囲の根本的な改修が必要になる。
案１はキャラチップ番号と同じやり方で対応可能、だが今後の属性追加に耐えられない。
案２は値をクラス（オブジェクト）に変更するという、本格的に根本的改修が必要になる、だが今後の属性追加に対応可能。

どちらの対応にするか迷いましたが、
結局、案２で対応しました。
理由は今後の拡張性と、プログラムとして「綺麗」だから。
（案１では、似たような処理を2つ並べて書くことが多くなるため「汚い」、そして(そのため)ミスが発生しやすい）

んで、反省は、
「始めから案２で対応すればよかった」ということ。
「開発」ってのは、ほとんどの場合、「一度作成してはい終わり」とは行かず、
継続的に、機能追加や機能改善を行っていく。
そのため、今後の改修を想定して、設計、製造を行う必要がある。
始めは、多少無駄でも。
特に初期開発、こういう根本的な要素については。

今回の場合、始めから案２で対応すると、
初期開発では、部位用に「キャラチップ番号」しか持たないクラスを作ることになる。
ぱっと見、無駄である。
けど、そう言う作りをすることでver0.2の対応は楽になり、
今後部位に関しては、およそ根本的な改修は必要なくなる。

まあ、あんまり考えすぎると無駄な処理になったり、分かり難い作りになったりするのだけど。
そのあたりはバランス。

　-　-
っていうのを、あらかじめ想定して作れなきゃならないんだよなあ。
開発者として2流である

　-　-　-　-
[追伸]

最近、

「カラム名」
を変換すると、

「絡む姪」
になって困る。

カテゴリ: [ゲーム制作] - &trackback() - 2009年06月02日 01:39:19

#blognavi