I have recently becoem enamored of a game mechanic in paper rpg systems. During combat, the characters declare their actions from slowest to fastest, and then action occurs from fastest to slowest. For example: Slow character declares he will move from point A to B Fast character declares he will fire at the slow character. The fast character now has the choice of firing before or after the slow character moves, targeting the character at either point A or point B. The implementation of the declared moves is an easy binary tree. But I could use some opinions about the map/display. During the decision making portion, any given square can hold two character references. The character that is there now, and the character that intends to be there at the end of the turn. The simple method is to add another field onto every map square. But combat is only going to take place on-screen (or screen + a few tiles). And the extra field is only needed during one portion of the combat sequence. Adding an extra field for all map squares can cost memory without benefit. Then I thought of holding a separate array of roughly screen dimensions (in tiles) to handle only the extra data. The extra array and the standard map covers the immediate requirements more efficiently. And then I considered, since I already have a small screen sized array, why not expand it to handle all of the screen routines (display, etc). The array would be of a struct that handles the basic map info and any other transitory effects like spell or missle animations (as well as the character decision phase). It would mean a small duplication of basic tile info between the main map and the local screen version, but it would separate the visual info from the stored map data. Example: A torch object might be animated, but the animation frame is not stored on the large map, just the torch reference. Once the torch comes within viewing range (just outside of the bounds of the screen), the screen sized map duplicates the main map and also starts tracking the animation, perhaps from a random initial frame. When it leaves viewing range, the animation frame info is discarded. Does anyone see any obvious shortcomings that I''ve missed, or have other comments?

Thanks for the feedback, I had missed that case in my design.

JSwing