Design – Using abstract methods to force subclasses to define values for member fields

Don't get too caught up on the State Pattern. This has a specific usage which I don't think necessarily applies in your game, at least not when you are manipulating the state of play.

Take, for example, a drawing application. In this case, the button pressed in the toolbar affects the way the drawing panel reacts to certain stimuli -- in this case, you don't want the application to know what it is going to do, you just want it to pass the stimulus to the State object and let it figure out what to do.

So, the rectangle drawing button is down, the application holds a RectangleDrawingState from which it can request a mouse-over pointer type or a mouse-down action or whatever. If you press the elipse-drawing button then that control switches out the RectangleDrawingState for an ElipseDrawingState and the application continues to ask for a mouse-over pointer type and a mouse-down action and gets completely different responses.

This is the kind of situation that makes for a good use-case for the State Pattern.

Now you may want this in your turn-based strategy game, to handle whether the attack button is pressed or the gather resources button is pressed. But you should handle the state of the game differently.

The state of the game should be handled as a single mutable object, which is manipulated at the end of each action. This object needs to be serializable in some form.

What you should do then is get a Command object by whatever means necessary and act on the mutable state-of-play object (it might be that your immutable State object, which depends on the action selected at any given time, returns a command which can act on the state-of-play object, for example).

Depending on your processing needs, I'd go with either:

a) A bitmap class that stores raw pixel data and format information; when loading, you resolve RLE compression, but otherwise leave the raw pixel values intact. Then add some methods to query the class for its pixel format, and possibly a getter/setter pair to transparently modify pixels in a format-independent way (i.e., convert to and from floating-point RGB representation on the fly). If you ever need to convert between pixel formats, you would do that in this model by loading the original bitmap, creating a new empty bitmap with the desired target format, and then copying pixels over through the floating-point RGB getters/setters. b) Store pixel data as RGB floats (or 16-bit integers, depending on the kind of transformations you want to do). When loading convert everything to that format, and then when saving, specify the target pixel format explicitly.

Method a) has the advantage that some filters can be implemented in a completely lossless way, by using raw data and adapting the filter to the actual pixel format; it is more complicated to write such filters though, and if apply do more than one floating-point filter, you'll get more rounding errors on each pass (because you convert to and from integer every time).

Method b) is easier to implement, especially because your filters only ever need to accommodate one pixel format, and it produces less rounding errors, but it does not allow for completely lossless filters (not even an identity filter: loading and then saving the same bitmap still introduces one round-trip's worth of integer-to-floating-point conversion errors).