For example I currently have a Player object that contains it's textures/animations and how to render these (I'd consider this as the view). Player also has an update() method which controls where the player is going to move, if it's going to lose health etc. (controller). Finally Player also has all it's attributes like runspeed, health, max health, inventory items etc.
The Player class is starting to look very cluttered and unorganized and serializing the complete Player class isn't really possible, so I made a separate PlayerState class which basically contains all it's attributes that could be changed while playing (This could actually be turned into the PlayerModel). I was wondering if it would be a good idea to split the Player up using a MVC pattern. I would have a Player, PlayerController and PlayerRenderer. Serializing the Player would be easy and it would be easier to keep the rendering separate from the updating and make sure rendering only happens when everything for the next frame has been updated.
This seemed like a good idea, however then I would also want to do this for GameMap. A GameMapRenderer that renders the map and it's textures to the screen. A GameMap model that contains what animals and hostiles are in the map and other various attributes the map might have. And of course a controller that controls everything that happens in that map.
I could go even further and say a Pig may need a model since it has attributes that can change, a renderer to render it's texture and a controller to control movement etc. but this seems a bit excessive. However, I don't like only implementing the MVC pattern to the player and then ignoring it for other classes like Pig. But the way I'm working currently is very badly structured imo and it's frustrating to work with.
