Thanks for all the advice. I'll give you a simple overview of how the game works thus far.
The game type contains a list of shapes in play, as well as a 2d grid of the game board. The grid contains the information whether there is a block here, and what colour it is. It doesn't know which blocks belong to which shape.
The shape type contains a list of ie 4 points. (Point itself being a simple type with x, y.) It contains fields to know whether it is the active (player-moving) shape and the x/y position of its centre-block on the board. There are no fields of game type.
The shape's methods, such as rotate and place, takes game as a parameter so that it can access the grid. After looking at my code perhaps it should be the grid I'm passing rather than the actual game. The shape needs to know what's on the grid so that a. it can see if it can rotate/go there and b. it can update the block information on the grid if the action is ok.
As for the manager and broker objects, they sound really complicated for such a simple game. The system I have now works, so I don't want to make fundamental changes that might introduce bugs due to my lack of skill, just to make it more "elegant" a program without any other advantages.
In that case I don't see how else to do it, other than move all the grid-needing rotate/place/etc methods from the shape type to the game type, so shape type is now simply a list of points and a few fields and no methods. Is that what you are suggesting?
The game type contains a list of shapes in play, as well as a 2d grid of the game board. The grid contains the information whether there is a block here, and what colour it is. It doesn't know which blocks belong to which shape.
The shape type contains a list of ie 4 points. (Point itself being a simple type with x, y.) It contains fields to know whether it is the active (player-moving) shape and the x/y position of its centre-block on the board. There are no fields of game type.
The shape's methods, such as rotate and place, takes game as a parameter so that it can access the grid. After looking at my code perhaps it should be the grid I'm passing rather than the actual game. The shape needs to know what's on the grid so that a. it can see if it can rotate/go there and b. it can update the block information on the grid if the action is ok.
As for the manager and broker objects, they sound really complicated for such a simple game. The system I have now works, so I don't want to make fundamental changes that might introduce bugs due to my lack of skill, just to make it more "elegant" a program without any other advantages.
the shape type shouldnt modify anything other than the shapes, it shouldnt even be aware of what its drawing the shapes to.
In that case I don't see how else to do it, other than move all the grid-needing rotate/place/etc methods from the shape type to the game type, so shape type is now simply a list of points and a few fields and no methods. Is that what you are suggesting?