oo tic tac toe
Author
Before you kill me for making yet another tic tac toe thread, let me explain. I've searched through the forums, and I've checked out google, and I can't find anything that answers my question.
I want to make an object oriented tic tac toe game (using java). I'm not completely new to game programming, (I've thrown together Pong, Breakout, and Asteroids) and I'm sure I could make a procedural version of Tic tac toe no problem. I'm basically doing this to get a little practice with object oriented programming. All the exercises that I have done so far involve making a simple class, and then another class that "tests" the class. I've never done anything with several classes communicating with eachother or containing eachother. So AI and stuff aside, how would I make a good design for an object oriented tic tac toe?
I'm thinking of having 3 classes: Square, Grid, and Game. Square would have a variable to store an X, an O, or nothing, and would have methods to alter that variable. Grid would contain an array of Squares, and thats about as far as I got. If anyone could make suggestions on how to continue, or point me to a good tutorial I would really appreciate it.
Oh yes, and I wanted to keep the game separate from the way it is displayed. For now I want to keep it console based and later when I learn GUI, I hope to reuse the classes to make another version.
You might try adding Player. Depending on what you want to do, a PlayingSession (find a better name) managing the Games (doing stuff like 'first to win 3') or stuff could be added.
The only flaw with tictactoe as an OO project is that there isn't much room for inheritance and polymorphism, which are important parts. If it's Java however, deriving your 'square class from a JLabel (or something better suited, my Java is rusty) might be an idea.
The only flaw with tictactoe as an OO project is that there isn't much room for inheritance and polymorphism, which are important parts. If it's Java however, deriving your 'square class from a JLabel (or something better suited, my Java is rusty) might be an idea.
You want a layout of object dependancies? Well, it honestly is all up to you, but this is what I would do:
IMO, you should do what suits you best in these (design) matters. As a hobbiest/n00b, all the fancy stuff really doesn't come in until later.
Game--> 1 Grid------> 9 Squares GraphicsAIetcIMO, you should do what suits you best in these (design) matters. As a hobbiest/n00b, all the fancy stuff really doesn't come in until later.
UntalkativeMonkey,
I'm not sure how familiar you are with OO design so I wanted to take a second and just pass on how I design OO systems. Its important to understand the process, otherwise you could find yourself back on these forums each time you need to design a new system. =)
Ok. When you're in the process of designing a system, you have basically three things to work with. 1. Objects. 2. Actions 3. Attributes. The best way to decide which is which in a system and decide how the system is going to fit together is just describe how you play the game in relative short sentences. For Example:
Tic-Tac-To consists of a game board. The game board has a grid on it. The grid is made up of nine squares. Two players have a pile of game pieces. Each player draws from his pile and places one on the board, into one of the squares.
After you have described the game/process, look back over your description and pick out the nouns. In the above example you might see: "Game Board", "Grid", "Squares", "Players", "Pile", and "Pieces".
Then move on to verbs. "Draws" and "Places"
And finally evaluate relationships such as "is-a" and "has-a"...for example 'the game board has-a grid'.
See where I'm going with this? Each of the noun's are strong candidates for Classes/Objects. Each verb is a possible action on one of those objects. Relationships can help you identify likely attributes or inheritance patters.
There are many different ways to organize the objects/attributes/actions at this point. It gets easier with practice. I suggest you pick your objects and go with it. If you encounter something that doesnt work, re-do it. That's why its called "soft"-ware. When it's all done, you'll have learned something. =)
I'm not sure how familiar you are with OO design so I wanted to take a second and just pass on how I design OO systems. Its important to understand the process, otherwise you could find yourself back on these forums each time you need to design a new system. =)
Ok. When you're in the process of designing a system, you have basically three things to work with. 1. Objects. 2. Actions 3. Attributes. The best way to decide which is which in a system and decide how the system is going to fit together is just describe how you play the game in relative short sentences. For Example:
Tic-Tac-To consists of a game board. The game board has a grid on it. The grid is made up of nine squares. Two players have a pile of game pieces. Each player draws from his pile and places one on the board, into one of the squares.
After you have described the game/process, look back over your description and pick out the nouns. In the above example you might see: "Game Board", "Grid", "Squares", "Players", "Pile", and "Pieces".
Then move on to verbs. "Draws" and "Places"
And finally evaluate relationships such as "is-a" and "has-a"...for example 'the game board has-a grid'.
See where I'm going with this? Each of the noun's are strong candidates for Classes/Objects. Each verb is a possible action on one of those objects. Relationships can help you identify likely attributes or inheritance patters.
There are many different ways to organize the objects/attributes/actions at this point. It gets easier with practice. I suggest you pick your objects and go with it. If you encounter something that doesnt work, re-do it. That's why its called "soft"-ware. When it's all done, you'll have learned something. =)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
