Reputation: 6043
I was having a discussion with my developer mate on following game design.
I have a collection of Move
in the Game
class. my developer mate is asking me to remove the collection and only have the current move information there.
what is your suggestions?
public class Game
{
public String Id { get; set; }
public String CreatorId { get; set; }
public List<Player> Players { get; set; }
public List<Move> Moves { get; set; }
}
public class Player
{
public String Id { get; set; }
public String Name { get; set; }
}
public class Move
{
public String Id { get; set; }
public String PlayerId { get; set; }
public String PlayerName { get; set; }
public String NextMoveId { get; set; }
public String NextPlayerId { get; set; }
public String Position { get; set; }
}
Edit:
my developer mate suggests me to only have a single Move
object in the Game
class.
Upvotes: 4
Views: 377
Reputation: 1567
public class Game
{
public String Id { get; set; }
public String CreatorId { get; set; }
public List<Player> Players { get; set; }
public String PlayerId { get; set; }
}
public class Player
{
public String Id { get; set; }
public String Name { get; set; }
public String Position { get; set; }
public Move(string NewPosition);
public event EventHandler onMoved;
}
This would be my prefered option, although without knowing what type of game it it it's hard to know. Either way, a player should encapsulate its own position, and the Game should know the current player.
As for moves, its game dependant, but move will change the players position, and this may or may not effect other players, so I'd probably implement move on the player and have a onMoved event on the players, which the game is subscribed to..
Upvotes: 1
Reputation: 244772
There's no really correct approach that any of us can provide for your design. It isn't a cut-and-dry situation; there's no "right" or "wrong" answer. And it's especially difficult for us to make suggestions given that we don't know all of the details behind your game's design. For example, as I asked in a comment and several of the other answers have hinted towards, if you have an "Undo" or "Replay" feature, you will need to store a history of all the moves. If not, and you have no desire to implement such a feature, there is no need to store information about all of the moves.
This is the kind of design decision that you need to learn how to make as a programmer. Consider all of the possible benefits of one approach and the benefits of the other approach, then decide which one best suits your application. Make a "T" chart if you find it helpful. Something like:
Keeping List of All Moves | Storing Only Last Move ---------------------------------------|------------------------------------ - Allows you to implement Undo | - Simplifies your game's design or Replay feature | - Consumes more memory | - Saves memory by only storing the | minimum amount of data | | ...etc.
In the end, you (and your colleague) are the ones in the best position to make this decision. Making sure that you've armed yourself with a careful comparison of the advantages and disadvantages is the best way to ensure that you've made the right one.
Upvotes: 7
Reputation: 3679
From my point of view. If you don't want that UNDO
feature then placing list of MOVES is useless because you already mentioned that no we do not have Undo feature, nor we think about having it
. then why having this list here ?
think this as, you have declare lots of variables in your code and not using them. It is good practice that keeping code clean and simple =)
Upvotes: 0
Reputation: 3160
I see nothing wrong with having a collection of moves in there. You can expose the current move with another property, then both, you and your mate are statisfied.
That's all I can say with the information you provided. I do not know your game logic. The Collection of Moves can be an advantage when you need to have a history of moves (e.g. a replay function) or you want to plan several moves ahead. I see nothing wrong there besides the fact that you probably do not necessarily need it.
By the way: List<T>
is meant for implementations, not for ObjectModels. I'd wrap the List in a class called MovesCollection. And Move should implement an interface (an abstract contract) in case you need many different moves implementations (e.g. AttackMove, Fortify-Move, Retreat-Move ...)
Upvotes: 0
Reputation: 26446
A game often consists of a set of moves performed by one or more players. Between each move, the game is in a certain state.
If you have the current state, and no need to playback or undo any moves, you would never access the previous moves. Future moves are not known yet, so with just the information you provided, I'd say Game
should not have any Move
, just a State
and a ProcessMove(Move move)
method to change the Game
's State
. The Move
is generated by one of the Player
s.
Upvotes: 4
Reputation: 824
I think having the collection could be useful in implementing an 'undo move' feature in your game. The list of Move objects could be an implementation of commands, and you could save/restore the state of your game using information in the commands.
Upvotes: 0