Introduce a ViewModel class

There are properties and functions in the Player class that aren’t really attributes of a player. They’re really properties to hold the current state of the game session.

So, I’ll create a GameSession viewmodel, to hold this information. The viewmodel’s purpose will be to manage communication between the views and the models and between different models (like the player, locations, and monsters).


However, there’s a problem.

Once I start pulling the CurrentMonster and CurrentLocation properties from the Player class, I’ll need to move a lot of code out of the Player class: all the movement functions (MoveNorth, MoveEast, MoveSouth, MoveWest, and MoveTo), the code to check if the player has the required item to move to a location, the code to populate the current monster (when the player moves to a location), and the saved game code (which saves the player’s current location).

So, to start, the only thing I’ll put in the GameSession class is a CurrentPlayer property. We’ll move the rest of the code into the GameSession class in small steps.


Next, I changed the code in SuperAdventure\SuperAdventure.cs and SuperAdventureConsole\Program.cs (the views) to:

  1. Add a class-level _gameSession variable
  2. Instantiate a GameSession object and save it to _gameSession
  3. Delete the existing class-level _player variables
  4. Change all uses of “_player” to “_gameSession.CurrentPlayer”


After making the change, I rebuilt the solution and tested that the game still worked.


This isn’t a big change, as far as lines of code. But, it is the beginning of a significant architectural change. We’ll be able to use this GameSession class for our automated tests.



SuperAdventure\SuperAdventure.cs (Windows form)


SuperAdventureConsole\Program.cs (console class)








SuperAdventureConsole\Program.cs (console class)


Leave a Reply

Your email address will not be published. Required fields are marked *