リストのアイテムのリストのアイテムのリストのアイテム・・・状態のアンドゥリドゥの管理に苦しんだけど、
とりあえず親リストの何番目の何番目みたいなの覚えさせてなんとか良い感じに落ち着いた( ´∀｀ )

反転描画の無駄のない方法とか分からんけども、とりあえず形になってよかった。
しかしやっぱり人とかパターンの多いオブジェクトはさらにひな型とか作らないとめんどくさいかも。(；´∀｀)
あともう一段階深く作らないとキャラクター管理できないことに気付いた(;^ω^)

正面向いてのその場足踏みだけだと簡単なんですけどね(^^;

色を変えるのにビットマップ形式だと扱いづらいような気がしてきたり・・・
うーむ。やりたいことが増えていきます(;^ω^)

> リストのアイテムのリストのアイテムのリストのアイテム・・・状態のアンドゥリドゥ

なんかわからんが深い！
なぜそんなことに…？

---

アンドゥ系の思い出：

//データの現在値を返すぜ
int GetData() const;
//データ値を変更するぜ（ただし引数が有効値域外の場合は失敗）
bool SetData( int NewValue );

みたいなのがあったとき，
「これのアンドゥが欲しいって？　そんなの【事前にGetData()の戻り値取っておいてSetData()に渡す】だけやん」
とか思ってると，

「GetData() が返す値は SetData() に受け入れられる値とは限らないんだなぁ」
（値域制限は SetData() のみに存在するのであって，データ値が常にある範囲内に保たれるという話ではない）

ということがあったりして，そんな簡単には済まなかったり．

上の画像的に説明すると
オブジェクトのリスト(親)
オブジェクトのシーンのリスト（子）
オブジェクトのシーンを表現するためのパーツのリスト（孫？ｗ）

ほとんどの処理を覚えさせて再現するので細かくなってしまいます。
末端のパーツのイメージを変えたとか、中心差分の座標を変えたとか。

記録して初期化して再現するのにアイテムが新しくなっちゃって子以降のリスト参照が変わっちゃって処理されなくて苦労しました。
しかも仕事でプログラミングやってないから自分のやってる方法は合ってるのかもよく分からないまま手探り状態・・・(;^ω^)

何かで Undo/Redo 作ったときは
とりあえず各種編集操作をコマンドパターン的に実装して

各編集操作コマンドの実施メソッドは必ず「その操作の逆」になるコマンドを返す
（つまりその戻り値のコマンドを実施すれば Undo になるし，Undoの実施時に返ってきたコマンドはRedo操作になる）
→返ってきたのをUndoかRedoのStackに積む

的な感じで作ったっす．
Undo/Redoのスタックを空にする（履歴を捨てる）タイミングは，Undo/Redo機能を持っているアプリケーションの挙動を調べてそれに倣う形に．

逆操作のほうがシンプルで良さげ。
あーでもペイント機能から作り始めたから巻き戻して履歴再現するようになったっていうのを今思い出した。

「逆になる処理」を用いるのではなくて

ある時点におけるデータの状態と
その時点より後に実施した操作（コマンド）の履歴全てを
保持しておけば，
履歴を順に再生すれば（その時点以降の）任意の時点での状態を復元できる

という形態でもよいかも．
（「履歴を順に再生」の処理時間が問題とならないのであれば）

そうなると今の設計とそんな変わらないかなぁ。