OOD ideas wanted
No takers in the "Project Swing" forum, I thought I'd try here. Any advice would be appreciated. I'm not looking for code, just a shove in the right direction.
So I've been taking object oriented analysis and design classes, and learning Java for about a year. During that time I haven't had much time to write any REAL (non-homework) code, but now I do, so I thought I'd write something like a solitaire program for practice.
I figure I'll have a Card class (maybe even make an abstract Card class and then have a StandardCard subclass), and I'll have a Deck class (maybe do the same type of subclass thing, in case I want to add games later that use multiple decks), and I'll have the main frame. Eventually I'll try to add the drag and drop stuff, although initially I might just work off of mouse clicks.
So my (hopefully simple) question about the GUI aspect of the game is: how do I draw the card? When you've got a frame (JFrame) and you want to draw an object, do you add a canvas to the frame and have the object (like Card) extend Component, then override the paint() method? Or is the standard way to do this something completely different?
Thanks for any advice,
Rich
There are a lot of approaches you can take. Probably the best idea is to represent the cards as components and insert these components into the frame, which then acts as the container.
If you want, you can look into using a layout manager to arrange the cards into hands or even into a solitaire layout.
If I were a beginner, I would probably start with a simpler game.
Mitch Goldstein
Author, Hardcore JFC (Cambridge Univ Press)
mdgoldstein@hotmail.com
Some basic consepts of game:
-you probably want to make the game doublebuffered
-you don't want to use components except for one whichs paint-method you override
-instead make your own drawing tree... custom paint method in every card and deck... or maybe deck paints the deck and the cards on the table
-then you create a mainloop in a thread which iterates permanently
These are not rules, so you must not obey them, but maybe could try to work somthing out from those.
hmm... pretty oppisite answers...
to my solution... i think that there's going to be problems with layout managers and such when your dragging your cards over the screen... and since gui is not threadsafe... how will be the cards altered (say flipped) in EventDispatcherThread if they are being drawed in other.
Those are different approaches, but that's okay. I know there are about a dozen different ways to solve any one problem when it comes to programming. I'm just looking for ideas, either from someone who has done a lot of good object-oriented programming, or from someone who has done some sort of similar application.
[[ If I were a beginner, I would probably start with a simpler game. ]]
Well, I'm not thinking of the standard solitaire game (klondike) that comes with Windows PCs. I'm thinking of something called "baker's game," which came on my palm (available from smallware.com). It's fairly difficult to win, but I think it's probably substantially easier from a programming standpoint. The cards are all dealt when the game starts, and the player simply moves them around.
somekinda JFrame housing the cards(components). Maybe gridBag layout manager or a custom one. I would probably use some images in JLabels to start with
JLabel aceOfSpades = new JLabel(new ImageIcon("dir/to/your/aceOfSpades.gif"));
then make use of mouse events and your on your way
do be careful to thread things correctly, you'll pick up on that very quickly
Maybe youd be interested in helping me solidify the design of a project Ive been working on... Im currently revamping the whole thing. Theres quite a lot to it and I couild really use any help I can get on it!!!email james.prisco@verizon.net if interested
Hi Rich
1. choose if you want to use swing or awt ... the first is 'nicer' but doesn't run in browsers without a plugin
2. for the drawing extend a class of graphical component. I'd inherit from JPanel (Swing) and draw the whole thing with all cards in one component.
3. in this class override the paint method to draw what you want.
This so far wasn't much OOD .. it's just how drawing works.
To the OOD:
I see the following classes:
Card (just the color and the value of the card)
CardStack (interface or abstract class representing any stack of cards, including information if a card is upside down, which cards a visible at all (not covered by other classes), which cards can be turned (lying on top of the stack))
Game (the main class containing a bunch of CardStacks and organizing the interaction)
GameView (this class knows the Gama Instance and does all the drawing. In all the other classes mentioned above there shouldn't be a single reference to graphics or output. This way you can switch the representation easily. Actually it is a real good test for you design to implement more then one front end. e.g. one for text, one for swing and one for HTML/JSP)
GameControl (This contains buttons or parses input and tells the Game which moves to make)
The tripple Game, GameView and GameControl make up a MVC (Model-View-Control) which is a standard aproach to seperate the different tasks of implementing some logic, controling the logic and presenting the logic to a user. In a lot of cases View and Control are combined in one class ... which is ok in many cases. See
JTree or JTable as an example
Spieler
Card
Deck implements
I see following classes
MyObject
x,y
Cursor cursor
abstract paint
void mouseClick
void mouseMove
Card extends MyObject
paint
g.drawImage....
mouseClick
whatever...
MyPanel extends myObject
vector objects
paint // paint objects too
void mouseClick // retarget to nessessary children
void mouseMove // --||--
Deck extends MyPanel
CardStack extends MyPanel
gamepanel extends JPanel
paint(Graphcisc g)
mainpanel.paint(doubleg)
g.drawImage(doublebuffer, 0,0,null)
Basiclys this whole mess means that instead of using slow swing recreate simpler component scale to meet the purposes of the game.
Thanks for the great ideas! I'm currently in an OOD class, and I think we're going to go over MVC this week or next.
