SRPGでアイテムの整理を実装しました。そして破綻しました。
破綻した原因は、アイテム交換のアイテム選択項目の原理をうまく掴めておらず、
変数が行き当たりばったり、フラグも行き当たりばったりに書いたので
交換自体は実現できましたが、バグを生み出し破綻しました。

原理は理解したので次は変数とフラグ管理をちゃんと行ってリファクタリングします。
4時間位掛けたのですが、上手くいかないもんですねー・・・。

外観上は上手くいってるアイテム交換画面を掲載します。
薄々、書き進めている途中から自分でも気が付いていたのですが、内部コードはもう支離滅裂です。
デスマーチに突入する前にバッサリ諦めて書き直す勇気が必要だと感じました。

プログラミングのフローチャート書けば大体整理しやすいですよ

>>naohiro19さん

フローチャートは重要だと今回思ったのですが
いかんせんフローチャートを書くために必要な変数とか関数が想像できませんでした。
場数が足りないなーと思っています。


+4時間かけてやっとキャラクター同士のアイテムの入れ替えの実装が終わりました。
輸送隊とかアイテムを捨てるとかアイテムの装備とかをこれから実装したいと思います。

アイテムの交換だけで25関数も書いてしまいました。多態性を持つ関数を書かないとだめだなと合わせて通過・・・・。

世の中ではゲームプログラムは継承の使いどころのように言われることが多いですが、実際はデータテーブルとそれを処理するある種の委譲クラスで作られています。
隠蔽化と当たり前のことは考えないのコンボで、フローチャートというものの必要性は薄れていると思います。

アイテムを持っているかどうかを動的に変更できるようになっていればアイテムの交換は簡単なはずです。
中断データからの再開とかに必要ですし、何よりデバッグの役に立ちます。

とりあえずフラグを多用しているっぽいのでフラグを使わないように心掛けると良いと思います。

強制リファクタリングですって？
なんて素敵な響き（意味深）なんでしょう


冗談は置いておきまして
書きなおさざるを得ない状況まで進んでしまうと、非常に萎えてしまうので
場合によってはもっと早い段階で自発的にリファクタリングをするのも、リスクを抑える為にはアリなんですよね

僕もローグライクゲームで、後から書き直したら破たんする可能性が高いと踏んで
敢えてダンジョン生成の処理を部分的に書き直したりもしました
一気に全部書き直すんじゃなくて、嫌な予感がしたら時間がある時に少しずつ書きなおしていくのもいい方法だと思います

>>ISLeさん

>世の中ではゲームプログラムは継承の使いどころのように言われることが多いですが、実際はデータテーブルとそれを処理するある種の委譲クラスで作られています。
実際SRPGを書いていて、データに対する専用の関数（クラス）での処理が非常に多いです。
キャラクタークラスなどは継承し易いのですが、それ以外のシステム周りになるとほとんど専用関数になってしまっています。
その中で、継承出来るものは、使いまわして楽したいのですが、継承しどころや仕方が思いつかないのが現状です。

>とりあえずフラグを多用しているっぽいのでフラグを使わないように心掛けると良いと思います。
フラグを多用すると、ワケがわからなくなって自爆することが非常に多いので、Enumを定義して状態遷移で処理しました。

>>jayさん
>場合によってはもっと早い段階で自発的にリファクタリングをするのも
自分で「あ、これはやばい」と思ったら直し時なんだと感じています。

複雑になればなるほど後に戻れなくなりますから。
ダンジョン生成アルゴリズムとかは最後まで行っちゃうとリファクタリングっていうより書き直しになりそう。

そうなったときのダメージが非常にデカそうですね。