Sep-19-2023, 06:20 PM
(This post was last modified: Sep-19-2023, 06:20 PM by deanhystad.)
Object oriented programming has become a catchphrase used to describe any good programming practice. OOP is about using objects to organize the data and functions in your software. Minimizing interdependencies is just a good idea regardless of what paradigm you use.
A mino needs to know about the Field. That is where it ends up. That is who it asks if there is an open space. When the tetronimo comes to rest in the field, the minos move from being a tetronimo to being part of the field. Tetronimos really don't need to know about the field. A tetronimo can ask it's minos if a shift or rotation results in a collision.
Logically I think the minos are divided into two groups. I think each time a tetronimo is created, the minos in the tetronimo are a tetronimo batch. When the minos comes to rest the tetronimo is destroyed, and the minos become part of the field batch. Can you add a batch to a batch or move rectangles from one batch to another?
The dependency tree is not too bad. Game needs to know about Field and Tetronimo. Tetronimo needs to know about Shape and Mino. Mino needs to know about Field. Field needs to know about Mino. It's not often there is only one circular dependency to resolve, and it is a weak dependency. The only thing field needs to know about Mino is how to add them to a batch. To Field, a Mino is nothing more than a Rectangle. Might be that the field doesn't have to know about Mino at all. Whan the tetronimo lands, the minos add rectangles to the field (pass grid coordinates) and destroy themselves.
My thoughts:
Field is a grid of cells. Each cell can be empty or contain a rectangle. The grid provides a method that returns the content of the corresponding cell, a method that creates a rectangle in the specified cell, a method that return the coordinates of a cell, and a method or attribute that Mino can use to make an appropriate rectangle (cell_size attribute?).
The game creates the field which is initially empty.
The game creates a random Tetronimo. The Tetronimo creates multiple Minos. When a Minos is created it creates a rectangle. The rectangle is not added to the grid, but rather floats above the grid.
The game requests the Tetronimo move. The tetronimo tries a move and checks the minos for collisions. If there is a collision, and the move was a rotation, the tetronimo can try a wall kick.
The tetronimo returns a status indicating if the move was successful. If the move was not successful, the game destroys the tetronimo. When the tetronimo is destroyed, it returns to it's last successful location and destroys all the minos. When a minos is destroyed, it tells the field to create a rectangle in the mino's grid location.
A mino needs to know about the Field. That is where it ends up. That is who it asks if there is an open space. When the tetronimo comes to rest in the field, the minos move from being a tetronimo to being part of the field. Tetronimos really don't need to know about the field. A tetronimo can ask it's minos if a shift or rotation results in a collision.
Logically I think the minos are divided into two groups. I think each time a tetronimo is created, the minos in the tetronimo are a tetronimo batch. When the minos comes to rest the tetronimo is destroyed, and the minos become part of the field batch. Can you add a batch to a batch or move rectangles from one batch to another?
The dependency tree is not too bad. Game needs to know about Field and Tetronimo. Tetronimo needs to know about Shape and Mino. Mino needs to know about Field. Field needs to know about Mino. It's not often there is only one circular dependency to resolve, and it is a weak dependency. The only thing field needs to know about Mino is how to add them to a batch. To Field, a Mino is nothing more than a Rectangle. Might be that the field doesn't have to know about Mino at all. Whan the tetronimo lands, the minos add rectangles to the field (pass grid coordinates) and destroy themselves.
My thoughts:
Field is a grid of cells. Each cell can be empty or contain a rectangle. The grid provides a method that returns the content of the corresponding cell, a method that creates a rectangle in the specified cell, a method that return the coordinates of a cell, and a method or attribute that Mino can use to make an appropriate rectangle (cell_size attribute?).
The game creates the field which is initially empty.
The game creates a random Tetronimo. The Tetronimo creates multiple Minos. When a Minos is created it creates a rectangle. The rectangle is not added to the grid, but rather floats above the grid.
The game requests the Tetronimo move. The tetronimo tries a move and checks the minos for collisions. If there is a collision, and the move was a rotation, the tetronimo can try a wall kick.
The tetronimo returns a status indicating if the move was successful. If the move was not successful, the game destroys the tetronimo. When the tetronimo is destroyed, it returns to it's last successful location and destroys all the minos. When a minos is destroyed, it tells the field to create a rectangle in the mino's grid location.