I don't think I'm understanding you correctly.
Are you suggesting that it
would make sense to make the sprites not abstract -- not have any inheritance? That would imply that either:
1. All sprites share the same class, or
2. Every sprite is its own class.
#1 would be problematic because the sprite parameters, states, and sizes are all implemented in the derived sprite classes. The states and sizes could maybe be implemented generically in the base class somehow, but the sprite parameters would have to be drastically different (well, at least until I start using/requiring .NET 4.0, where you can dynamically add properties to an object, at least with VB.NET). It's nice to have parameters so directly correspond to variables defined in the derived sprite class. Also, eliminating object inheritance seems to be a step in the wrong direction with OOP, where right now you
can define a base class and take advantage of the fact that your derived class inherits all the base class functions, and can add new functions and variables only applicable to this specific new type of sprite.
#2 would be problematic because the framework code needs to be able (among other things) to determine the position of a sprite generically. And that would also mean a lot of overhead if every sprite type had to totally rewrite all those SpriteBase functions.
OR are you suggesting that SpriteBase
should be abstract (asking the question "would it make sense to just have SpriteBase not be an abstract class" suggesting a "no" as the right answer)?
To that I say, SpriteBase already is abstract in some ways. All these members are abstract and must be overridden by the derived sprite generated by SGDK2:
- SolidWidth and SolidHeight
- SpriteState
- ExecuteRules
- ClearParameters
- RemoveFromCategories
Also, the framework takes advantage of the ability to refer to and interact with sprites generically in a number of ways as indicated above (sprite position, size and appearance).
But if you are saying that SpriteBase should be
more abstract, I am undecided. I started adding "virtual" to many of the functions implemented in SpriteBase until I stopped and asked the question, "how am I deciding what makes sense as virtual and what doesn't?" and I didn't know the answer. Under what circumstances will you need to override a function? Was I correct to begin with in having only those members that the framework cares about be abstract? So maybe you are suggesting that nothing more than the framework's minimum requirements should be abstract, and things are OK as they were?
Edit: Oh, also Processrules is virtual and can be overridden, but is not abstract because it has a default implementation.