Should entities know how to draw themselves? I’ve used this approach: it’s simple and it works, but after learning MVC-patterns I feel uneasy about this. It’s hard to change the art style when all the display logic is buried in the model.
One could introduce a view class, which takes the level as an argument and draws it, but this would mean it has to identify entity types and introduce a “switch”-statement, which I learned is also bad.
Where should one place code for drawing, in a way that is extensible, easy to change, clean and dry?
Theres nothing inherently wrong with having an abstract Draw() style method in your entities that lets them decide how they will be drawn, especially for smaller games that probably won’t be extended significantly. I’ve used this method in a ton of small projects and it works great.
An improvement you can make to that strategy is to use your game resources as a proxy for the actual drawing operations. For example an enemy entity can defer all the rendering through a resource object it owns that represents the mesh; likewise for the texture/skin and effects.
I’ve recently switched to using my entities as ‘dumb’ containers for interfaces that define their behaviours. A player entity might contain IMoveable, IControllable, IRenderable, and many more interfaces that simply apply a specialized operation to that entity depending on the data it contains. The entity doesn’t know much about this and all the execution happens when the scene graph is traversed for culling/rendering.