MVC doesn't mean you have to separate state, behavior and appearance everywhere. Sometimes you may and should put everything together. One uses MVC approach where multiple objects/entities/components (however you call them) are involved in exchange of data (be it really passing some value, or calling a method of another object).
So it means:
- Model, typically the data you would bother to put into your save files.
- Controller, a piece of code that is used by multiple objects (e.g. your score increases both when you pick a coin and kill an enemy) or an action of one object over another, where first can't be simply a child/parent of the second (where the parent is a single component)
- View, a component, something that could work without the rest, e.g. a scrollbar. It's useless without the rest, but if you put a scrollbar in a game and nothing else, it should work (you should be able to scroll it, if you initialized it with some values). This scrollbar will do all logic inside itself, e.g. calculating how pressing a button will affect slider's position, but it will also send some messages outside, like "scrolled" event with "scroll_percentage" data.
So in your Motorbike game, you will probably want to keep some data in your component
Motorbike, e.g. it's current rotation, keep some logic, e.g.
rotate method, and of course the view,
draw method. But you will probably duplicate some data (rotation) in model, so you have all important data ready on (auto)save event. Also, while your Motorbike can handle itself, you will want it to communicate with the rest of the game (collision detection for example) and you communicate different classes with notifications/events/whatever else your MVC framework uses.