That's kind of sad, but not strictly relevant.
It makes big sense to me.
Those are the basic requirements for a battle.
This is actually an implementation detail and not part of your model. (I originally addressed it because you offered it as a way to implement a model very different from yours.)
If you don't like them, then specialize the template.
Using compile time polymorphism as an implementation mechanism buys you all the problems of compile time polymorphism. Do you not know those problems? I'll give you an example, your save file loader function functions as a factory to load the player state: what type does that function return? Use some base you say? Which base should you return? Return "Hero" you say? How do you get '*player_hero' to work with a template? Use a reference to "Hero" you say? How do you specialize the template so that my "Wizard" "Fights" differently than your "Warrior" in the context of your source? Don't use a factory you say? How do you load the save state? Examine it and selectively load it into the correct type you say? How do you choose which execution path to take? Use templates to implement all of it you say? That is an option, but you had better have a very limited number of actors... like two.
Indeed. He needs a few points for that...
Actually, that sounds like a very nice abstraction, provided you need such a flexible design.
Where's the difference between design and conceptual model?
If you have a flawed conceptual model you have no chance to design a reasonable model ready for implementation.
I don't know much about chemistry, and if I start off with this flawed conceptual model than any simulation I make will be poor and any implementation probably worthless. How I choose to model the interactions between elements is one thing, but if I model the transition elements the same as the others, because I was working from this flawed conceptual model, you can bet my code will be virtually useless regardless of how perfect I modeled the interactions in my implementation.