I'm putting together a program to try and recreate a board game. My goal was to keep the rules and actually actions of the game separate from its presentation, so I am creating a library that contains the objects and methods that define what you can do as you play the game. Besides the classes that define the games objects, I was planning to create two classes to "front" the game. The first class GameRunner
was the class that the presentation layer would use to call actions on the game such as AddPlayer
, TakeGems
, BuildCard
etc. Then I wanted a second class to handle the game state, aptly named GameState
, that would keep track of the players and their field, as well as the market for the game. In GameState
I created the methods that would affect the game state to define how players are added and cards are purchased.
What I have noticed is that all of the game logic is being defined in GameState
and GameRunner
now is essentially just turning into a pass through class, in other words, all it does is call the appropriate method in GameState
and return the state object:
public GameState AddPlayer(string name)
{
gameState.AddPlayer(name);
return gameState;
}
This just seems repetitive to me. Does this make sense as a design? A separation of concerns between actions and what they do? Or should I just make GameState
a class that has the objects that make the state of the game, and just have GameRunner
manipulate those state fields from it's methods instead. Example:
public GameState AddPlayer(string name)
{
if(Players.Count < 4)
{
gameState.Players.Add(new Player(name))
gameState.Success = true;
}
else
{
gameState.Success = false;
}
return gameState;
}
AddPlayer
return the gameState object to the caller?? This seems to break encapsulation.GameState
but for now I do that to remind myself that the whole state is being returned.