July 19, 2007.

やり直したいこともある

先日より開発中のS!アプリ、機能の完成度は９割となりました。パッと見には普通に動きます。あとちょっとで完成ではありますが、何点か課題が残っております。完成までに中身を明かすのが嫌いな人なので書きにくいのですが、一つは情報を左右反転するロジック。ドット単位で場所を指定してdrawしているため、情報を左右変更した場合など、操作と描画ロジックの関係が崩れてしまうため、そのあたりをコントロールする方法を考えなければならないのです。反転機能無しの状態でリファクタリングをかけてからの方が楽かも。個人で開発すると設計書が無いため、結構グダグダな作りです。っていっても所詮600行ぐらいのプログラムですが。

もう一点はUNDO機能。今の構造だと操作ミスを修正する手段がありません。UNDO機能を想定した作りの予定だったのですが、いざ作ってみたらこのままの構造ではちょっとつらいかも。やはり設計書を起こすべきかな？デスクトップJavaのFormアプリであればデータ部分をSerializableなクラスにして、UNDOバッファ分Serializeして配列につっ込んでおくのですが、携帯のCanvasベースではそうも行きません。必要最低限の操作情報を配列に保存しておき、それを元に普段の逆ロジックを処理することになります。さて上手く動くかなぁ。「Q: UNDOができません」「A: 仕様です」とかが楽なのですけど(笑)。そういう機能が必要となるのがツールの宿命ですね。ゲームなら不要なのに。

そうそう、今作ってるものが完成したら動きのあるものが作りたいなとおもい、SpriteCanasの仕様について調べて見ました。そしたら、Spriteは256個までしか保持できないのですね。同時にはって事ですけど、初期化の時間を考えると例えばゲームのステージが進む際などのタイミング以外での切り替えは現実的ではないです。256って多いように見えますが、Spriteは8 x 8のため、例えば32 x 32のキャラを4パターンアニメでフルに動かすとすでに64個使い切ってしまう。RPGやシューティングのように同じコマが多いものには向くけど、ディズニーアニメのようにコマごとの形が大きく変わるものには向かないのです。多くの待ちうけアプリがフラッシュな理由がよく分かりました。

Copyright 2007 barista. All rights reserved.