MVC should help to organize code, but for now it turned my code into complete mess.
When you get into design patterns in general (of which MVC is just one of many), then you need to quickly learn that design patterns aren't applicable everywhere, they don't have to be implemented exactly as described, and they aren't legos that you build with (they are shorthands you use to describe concepts).
What this means is:
A) Is this the appropriate place to use MVC?
B) What is the best way to implement it in this situation?
C) Are you using it just because you've heard about MVC, or are you using it because you have a genuine need for MVC?
Also, MVC is primarily about separation of concerns, not necessarily code organization.
Some people implement MVC as a View, with the Model also being the Controller. Sometimes the Model and the View are both controllers. There are other good implementations too. It's important to realize that different projects have different needs, and there's not "One True Implementation" that solves everything for every problem.
Often, you don't need to pass messages to the View, just give the View a pointer/reference to the Model, otherwise you'll be duplicating the same data in two different locations.
I would argue that, in this situation, making 'Game' have separate Model, View, and Controller is overkill. With Player is could be overkill, but might not be. With Board it's often a good idea.