Beginner's Graphics
Let's say I want to make a board game, for the sake of this question, checkers.
I have an array that represents the CheckerBoard, and Piece objects to represent the Pieces.
What is the best way to visualize this setup so that when a user makes a move (i.e., clicks a valid square to move/jump a piece) the frame updates itself with the new information?
Right now I'm trying to create a Component that takes information from the CheckerBoard then alters its drawing instructions to match the current state of the board. Whenever the user makes a move, the frame will remove and then add the Component, in hopes of drawing a modified board. But right now, this method doesn't seem to work.
Suggestions?
[735 byte] By [
Kousetsua] at [2007-11-27 7:06:15]
I am no graphics guru but I would suggest that for games like checkers, chess etc where you have a static background, just use a static image and instead update where you place the pieces. Updating actual board background is doable but will be much more resource intensive.
For a grid game like checkers, I'd suggest using a GridLayout, and then create a Square class to represent an individual square. The Square would know how to draw itself based on its current state (e.g. whether there's a piece on it).
Each Square would probably have a reference to a Game object which would hold state relevant to the game as a whole (e.g., whose turn it is), and each square might also (depending on the game) have references to surrounding squares. For example, the square might only have references to squares where a valid move can be made to.
400 objects isn't too much.
The interesting thing about the square-as-component solution, is that you could then create a whole hierarchy of Square types. For example in checkers, you could create a "KingRow" subclass, which you'd put on the far rows of the board. They'd have special logic in their "add a piece" method, which would king the checker. You might be able to express much of the game rules as per-square rules, and modularize the logic pretty well.
Each Square would be an object of a class that subclasses java.awt.Component. (It may furthermore subclass JComponent or whatever, if you want to use Swing.)I suppose you could break the squares into components and non-components, but I don't really see the point.
