|
|
Game/Board
Dave had a few questions about the possible design of a game/board set of objects. I've posted them here, with my responses, slightly edited to remove some of our rambling:
Dave: Now storing the game is something that I'm very interested in. I guess in the abstract it shouldn't be controlling what it looks like exactly because the user-preferences is allowed to affect that. I'd love to work on that, with the only caveat being that I'd like to consult with some group of others about what the structure of the object should be like... what methods are people expecting, etc.
Peter: Imagine a Go board. Imagine that some entity can only communicate via methods on an object and needs to be able to play Go.
Design that.
The Go board itself should be Go-Stupid. It shouldn't know anything about the game of Go, only about its size and what's on it. In fact, if I were clever enough, I should probably be able to use it to play Pente or Othello. You'd probably also want a "game" object that stored game state: players, turns, last move, etc.
Dave: Interesting. Since we're going to want the ability to "replay" the
game do you think the board should be storing the order in which moves
occurred? Or do you think that would eventually be up to the game?
Peter: I was thinking about XP and the design and having a separate board and game object is typical OO design. However, it kinda violates the XP mantra: "As simple as possible to get what you need."
For the history, I'd definitely say, "Don't worry about it." Don't worry about the history, because we aren't doing the history part. We just want a game that stores today's state, and enough other info to present
what we said we'd present for Release 1.
History is complicated, and will certainly involve extensions to the game object and possibly the board object. But we can do that later, when we've had more experience with our objects and we've played with the game a little.
For the board/game objects, having a separate board and game object might theoretically violate the "simple
as possible" mantra, but for me it doesn't. I think it'd actually more difficult for me to program it as one piece, because it feels so wrong to me.
Also, it doesn't cost much (if any) extra time, it's almost certainly going to need to be done, and redoing it later will cost more time than doing it the first time.
History, on the other hand, will cost extra time, may not need to be done (if we never get that far), and the little bit of refactoring that will be needed should not be that expensive, especially if we have tests to make sure we haven't messed anything up.
I think that's the right call, but I'm open to suggestions.
As for game state, all game validation should be done by a "judge" object which we'll tackle later.
Dave: Righto. The Board will presumably enforce some rules though. For instance, that one can't play "off the edge" of the board, and you can't play where a stone already is, eh? I guess in a game like
Othello, you might actually want to change the color of an existing spot on the board. But playing "off the edge", seems undefined, and as such I would expect the object to reject it.
Peter: Yeah, the board needs to enforce the physical rules of the board. We are only programming a Go board, so don't worry about functionality you won't need. ("As simple as possible") So you should assume one piece per square and you should only worry about Go style moves on the board. That is, adding/removing pieces, I think. Not changing colors, not moving a stone from one place to another.
To imagine your interface, the ins/outs, model it after your hand touching a Go
board. What are all the things you might need to do to that board? That's how I usually tackle it.
|
|
|
|
Post a Comment
<< Home