Object Responsibilities

Started by
7 comments, last by starruler 15 years, 10 months ago
Say I had a simple card game. There were classes for a card, a deck, a player, and the game overall that incorporated the logic necessary to play the game. If I wanted to add a user interface that simply showed you your hand and the last card played. When it was your turn you clicked on a card to play it. Where should all of the drawing code and card selecting code be put? For 2d games like asteroids I would pass a pointer to the location to draw, and the object would use it's own internal coordinates to draw itself on the screen. That approach doesn't seem like it would work very well with a card game. Another thing that I would like to be able to do is separate out the graphics backend from the main game logic. That way if I decided to change librarys, or simply wanted to try a new one that would be doable. Any input would be greatly appreciated.
Advertisement




The normal interface would be from the player (who has the hand of card that exist in the deck) and if this is multi player real/computer run then you also need a 'game' object that contains the players and tracks the game turn/phases.


As for seperating the game logic from the rendering that should be straight forward if you used object oriented design. The Player signals (calls methods) the hand to be displayed which signals all its cards to be displayed (positioned to display multiple cards at once, with given offset positions...)

Likewise when the player inputs (clicks on cards to select/activate them the cards send that signal upto the hand and rom there to the player object where the game specific logic decides what should happen (ex - send a signal back down to tell that card to show itself or whatever -- that is after the game mechanics have validated the input... After that the game mechanics would adjust the game state in reaction to the card interaction.
--------------------------------------------[size="1"]Ratings are Opinion, not Fact
So what your suggesting is that the player class essentially becomes the graphical portion of the program. I guess that keeps the game logic away from the gui and it would be pretty simply to let the game sanitize the input rather than the player (the way I have it now in my text based version).

How does one separate out which particular graphics backend (SDL/Allegro), from the drawing code. Or say ever further down the road, I wanted to make it using a 3d library (OpenGL/D3D) how do I design the rendering code to make those transitions as seemless as possible?

Is there any good literature on this subject?
Take a look at some of the articles in the first link in my sig.
Quote:Original post by starruler
So what your suggesting is that the player class essentially becomes the graphical portion of the program. I guess that keeps the game logic away from the gui and it would be pretty simply to let the game sanitize the input rather than the player (the way I have it now in my text based version).

How does one separate out which particular graphics backend (SDL/Allegro), from the drawing code. Or say ever further down the road, I wanted to make it using a 3d library (OpenGL/D3D) how do I design the rendering code to make those transitions as seemless as possible?



You can start by identifying the common operations -- drawing textures/ font text/ standard controls / initializing windows / asset loading / etc and create function calls /state data structures that will go in your game. Then you can create a Library interface that map the required functionality into a particular graphics/input library (and be able to create another similar set for a different library),

--------------------------------------------[size="1"]Ratings are Opinion, not Fact
Another clarifying question on separating game logic and the gui.

I want my gui to be similar the the Hearts game that ships with Windows. You can see your hand, the cards that have been played and the number of cards the rest of the players have. If I'm using my player class to contain all the code, it would have no idea how many cards the rest of the players have. It really wouldn't know much about the state of the game until it is its turn to play.

How do I accomplish this while maintaining separation?
bump
I'd suggest making a "Game" class which contains the players.
I have a game class that contains all the logic and rules required. It contains the players, the deck, and a list of the cards that have already been played. It calls functions of the player class. There are two different players HumanPlayer and AIPlayer. I would like for there to be 1 human player who can see his/her cards and the AIPlayers would simply appear as the backs of cards.

My problem is I'm having difficulty deciding where the code for drawing should be. It's very useful to have the game logic separate from the drawing code in case I were to ever add another Player type such as NetworkedPlayer.

This topic is closed to new replies.

Advertisement