2010年03月28日

作品完成後の反省会と今後のバージョンアップ方針

ついに完成!3年間もだらだらとやっていた5つの宝島が作り終わりました〜〜〜!
さて、完成したので今までの振り返りと、今後どうやってバージョンアップしていくかを
語っていこうかな。
  
反省1 プログラムが汚い

一番の反省点はこちら。いや、3年前の携帯電話の世界ではあながち間違いではなかったんだけど

  • 自作クラスは最大で2つ
  • 使用クラスもなるべく少なく
  • メソッドもなるべく減らし、ひとつのメソッドに処理を詰め込む

という方針が、いかにもまともじゃないソースを生み出していた
特にひどいのがメソッド「parse()」。自作スクリプトをパースする処理なんだけど、
1メソッドの行数702行、そしてその大半がif文でトークンを確認して処理するだけという
眠くなるにもほどがあるロジックになってる

これ、ちゃんとしたプログラムだとどういう処理にするべきなのかな?
JavaCCでパーサ自動生成するのが正しいやり方なんだろうか
つっても、5つの宝島のスクリプトは別に構文解析することもない単純な逆ポーランド記法の文法なので、基本的なパース動作はこれ以上変えようがない気がする

それともそれぞれのトークンにクラスを割り当てて、Interpreterパターンをしこしこ作るのがいいんだろうか
ここらへん、まだ答えは出ておりません

反省2 フラグ管理を自動処理にしてしまった

コレ。超重要。最初の反省点は昔は正しかったんだっていうことで自分を慰めることはできるんだけど、
この問題は相当堪えたわー。ていうかフラグ自動管理のせいで最後までバグに悩まされた
自分で自分の首を締めてどうする

どういう反省点かっていうと、例えばメインメニューの選択処理。
最初のメニューでは

  • 魔法
  • 道具
  • 装備
  • 隊列
  • 賃金
  • SYSTEM

から選択肢を選び、なにか一つ選ぶと

  • アタル
  • モサメデス
  • 金紗叉

のように次の選択肢を選ばせる。↑の場合は魔法や道具を使った場合の、誰が行動をするかを選ぶ場面だ。こういった処理を行うとき、バックグラウンドでは現在の選択状態管理配列_args[]を使って

  • 最初選択肢を選んでない状態の場合 ・・・ _args[0]から_args[9]まですべて「-1」が入力されている
  • 一番目の選択肢を選んだ状態の場合 ・・・ _args[0]に最初の選択肢の番号が入力されている
  • そこからさらに選択肢を選んだ状態 ・・・ _args[0]と_args[1]に選択肢の番号が入力されている

というように、選んだ選択肢を自動的にスタックに積むように処理していた
一方、通常イベントシーンではこんな処理をせず、前回の選択肢が_args[0]に入力されるだけだった
これが不可解なバグの元になっていたのだった

一番問題になっていたのはメニューシーンから通常イベントシーンに変わるときなんだけど、

ある場所に向かって「松明」を使う
→通常イベント番号「20」をパースする(ここまではよい)
 →次のイベントを表示するためにイベント番号「32」をパースする

最後のイベント番号「32」をパースしようとするんだけど、現在のシーンがメニューシーンから始まっているので
選択肢をスタックするモードになっており、いつまでたってもイベント番号「20」をパースし続ける
という困った処理をしていたのだった。

その他にも行動者や対象者を選択肢スタックの値そのままを使っていたために、
  1. 次回パース時に0から行動を選択しようとして_args[0]から_args[9]に-1を入力
  2. その後行動者の名前を表示使用として_args[1]を参照
  3. _args[1]の値はすでに-1になっているからArrayIndexOutOfBoundsException発生
  4. なんで?

みたいな現象が続出したりした。最後の方はこれ出てきたらああ、_args[1]か_args[3]が-1なんだな
というふうにカンが働くようになったけどどう考えてもこれはバッドノウハウです本当にありがとうございます

反省3 スクリプトがプログラムしづらい

処理を軽くするために逆ポーランド記法にしたスクリプトが異常に使いづらかった

現在HPが15を下回ったらキュア(イベント0)を実行、それ以外は通常攻撃(イベント17)

という簡単な処理をするために

1 getArgs 3 setArgs hp 15 < if 0 loadMEvent
-1 3 serArgs 17 loadMEvent

こんな謎の文字列を書き連ねていたんだけど、理想はこうあるべきだよね?

if(hp[$ofence] < 15){
  loadMEvent(0);
}else{
  loadMEvent(17);
}

まず現在HPを参照するために対象者を現す変数_args[3]に対象キャラクターを代入しなきゃいけない

1 getArgs 3 setArgs

の処理が不要だし、これやったあと通常攻撃するためには一度対象者キャラクターをクリアしなきゃいけない

-1 3 setArgs

↑をしないとランダムに対象を選ぶことをせず、自分自身を攻撃してしまう

反省点2もあわせて、こういうのはすべてスクリプト側で管理して、javaのロジックでは何も触らないくらいがよかった・・・
本当の理想は、通常攻撃では

if(isEnemy($ofence)){
  $defence = rand(rand(party.length)); // パーティの先頭メンバーが一番対象になりやすいようにする
}else{
  $defence = selectEnemy();
}

damage($defence, atack($ofence) - defence($defence) + rand(4));

ぐらいなのがいいよね!

今後の展望

反省することは他に山ほどあるんだけど、これからの方針についてもちと語ってみるかな。

まずは配布サイトの作成だ。ブログは毎日の記事をかく所だから、最新の記事で流れてしまって5つの宝島の解説やら操作説明やらが見れなくなるから、Wikiか何かで配布サイトつくらないと。

あとあと、マルチプラットフォーム展開も考えないと。せめてアプレットでできるようにして、もうちょっとユーザを増やしたいものだ。

ま、バグ修正とバランス調整も継続してやってくけどー。

いろいろやることあるなあ!楽しいぜ
posted by LoyalTouch at 21:26| Comment(0) | TrackBack(0) | 5つの宝島 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:


この記事へのトラックバック