Lesson 20.5 – Moving the game logic functions from the UI project to the Engine project

The main goal of this refactoring was to move these functions from SuperAdventure.cs to Player.cs.

• MoveTo – the function that moves the player to a new location
• btnUseWeapon_click – to attack a monster
• btnUsePotion_Click – to use a potion during battle

However, this change could not be done with a few cut-and-pastes.

Those functions contained code for both the game logic and updating the UI. When the code moved to the Player class, it would not have access to the UI controls.

Completing this refactoring required a lot of changes, in a lot of places. This lesson became very long, and very complicated. It was going to take around 30 steps, or more, to include the details for each change.

So, I decided to summarize the changes I made in this lesson.

I suggest you follow this lesson by opening SuperAdventure.cs and Player.cs in Visual Studio, while viewing the updated classes here (GitHub or DropBox).

At the end, you can update your solution with the source code from GitHub or Dropbox.

Moving the code to handle button clicks from the UI to the engine

First, I cut-and-pasted the MoveTo() function from SuperAdventure.cs into Player.cs.

That broke the program in about 60 places.

Now, the UI button click functions need to call the MoveTo method in the Player class. I could have just made Player.MoveTo() public, and still called it from the SuperAdventure Move functions. Instead, I decided to create these new functions in Player.cs, with clearer names.

public void MoveNorth()
{
   if(CurrentLocation.LocationToNorth != null)
   {
       MoveTo(CurrentLocation.LocationToNorth);
   }
}
public void MoveEast()
{
   if(CurrentLocation.LocationToEast != null)
   {
       MoveTo(CurrentLocation.LocationToEast);
   }
}
public void MoveSouth()
{
   if(CurrentLocation.LocationToSouth != null)
   {
       MoveTo(CurrentLocation.LocationToSouth);
   }
}
public void MoveWest()
{
   if(CurrentLocation.LocationToWest != null)
   {
       MoveTo(CurrentLocation.LocationToWest);
   }
}

Then, I changed the SuperAdventure functions to call the new functions in the Player class.

private void btnNorth_Click(object sender, EventArgs e)
{
   _player.MoveNorth();
}
private void btnEast_Click(object sender, EventArgs e)
{
   _player.MoveEast();
}
private void btnSouth_Click(object sender, EventArgs e)
{
   _player.MoveSouth();
}
private void btnWest_Click(object sender, EventArgs e)
{
   _player.MoveWest();
}

For the UseWeapon and UsePotion button click handlers, I created new functions in the Player class. We still need functions in SuperAdventure.cs, to handle the click events. But now, all they will do is get the current weapon or potion from the dropdown and call the new function in the Player class.

This is what they look like now, in SuperAdventure.cs:

private void btnUseWeapon_Click(object sender, EventArgs e)
{
   // Get the currently selected weapon from the cboWeapons ComboBox
   Weapon currentWeapon = (Weapon)cboWeapons.SelectedItem;
   _player.UseWeapon(currentWeapon);
}
private void btnUsePotion_Click(object sender, EventArgs e)
{
   // Get the currently selected potion from the combobox
   HealingPotion potion = (HealingPotion)cboPotions.SelectedItem;
   _player.UsePotion(potion);
}

The new Player functions accept the weapon, or potion, as a parameter, instead of reading it from the combobox – because the Player class cannot read the combobox controls of SuperAdventure.cs.

Fixing the class-level variables

SuperAdventure.cs holds the Player object in the class-level variable “_player”. The MoveTo, UseWeapon, and UsePotion functions all used the methods and properties of the _player object. Now that the code is inside the Player class, we don’t need to do that anymore.

For example, in the old MoveTo function, we had lines like this:

if(!_player.HasRequiredItemToEnterThisLocation(newLocation))

That line is saying, “for the Player object that we are storing in the _player variable, call the HasRequiredItemToEnterThisLocation function”.

After moving the MoveTo function inside the Player class, we change it to this:

if(!HasRequiredItemToEnterThisLocation(newLocation))

The function knows to look for HasRequiredItemToEnterThisLocation on itself, the Player object it is “inside”.

So, we need to remove all the references to “_player”, from the code we copy-pasted into the Player class. When I did that, it eliminated many errors.

We also need to handle the _currentMonster variable that was a class-level variable in SuperAdventure.cs.

We stored the current monster, from the current location, in that variable so we could use it during combat (in the UseWeapon function). But now that the UseWeapon function is in the Player class, we need to make the _currentMonster variable a class-level variable in the Player class.

So, I deleted the _currentMonster declaration that was in SuperAdventure.cs, and added it to Player.cs. That eliminated a few more errors.

Notifying the UI of changes

Just like with the previous refactoring lessons, we’re using events to communicate between the Engine classes and the UI.

We now raise a PropertyChanged event when the player’s CurrentLocation changes, just like we did with CurrentHitPoints.

I changed the CurrentLocation auto-property to use a backing variable, and raise an event when it is changed.

private Location _currentLocation;
public Location CurrentLocation
{
   get { return _currentLocation; }
   set
   {
       _currentLocation = value;
       OnPropertyChanged("CurrentLocation");
   }
}

The UI sees the event and updates the text showing the current location’s name and description and makes the weapon and potion drop-downs and buttons visible (if there is a monster at the location, and the player has weapons or potions). This is done by adding this code to the PlayerOnPropertyChanged function in SuperAdventure.cs.

if(propertyChangedEventArgs.PropertyName == "CurrentLocation")
{
   // Show/hide available movement buttons
   btnNorth.Visible = (_player.CurrentLocation.LocationToNorth != null);
   btnEast.Visible = (_player.CurrentLocation.LocationToEast != null);
   btnSouth.Visible = (_player.CurrentLocation.LocationToSouth != null);
   btnWest.Visible = (_player.CurrentLocation.LocationToWest != null);
   // Display current location name and description
   rtbLocation.Text = _player.CurrentLocation.Name + Environment.NewLine;
   rtbLocation.Text += _player.CurrentLocation.Description + Environment.NewLine;
   if(_player.CurrentLocation.MonsterLivingHere == null)
   {
       cboWeapons.Visible = false;
       cboPotions.Visible = false;
       btnUseWeapon.Visible = false;
       btnUsePotion.Visible = false;
   }
   else
   {
       cboWeapons.Visible = _player.Weapons.Any();
       cboPotions.Visible = _player.Potions.Any();
       btnUseWeapon.Visible = _player.Weapons.Any();
       btnUsePotion.Visible = _player.Potions.Any();
   }
}

That lets us delete any lines in the Player functions that tried to write to rtbLocation, or change the visibility of the buttons. More errors eliminated.

Creating a custom event argument

We also need to use a new notification technique. This one will handle everything we display in rtbMessages.

With the previous notifications, the Player class raised an event, and the UI read the new values from the _player object’s properties. We can’t do that with the messages – there is no “message” property in the Player class, with a value for the UI to read.

For the message events, we want to send the text of the message along with the event notification. To do this, we will use a custom event argument class. This is like saying, “This event happened, and here’s all the information you need to know about it.”

Here’s the new class we need to add to the Engine project, MessageEventArgs.cs:

using System;
namespace Engine
{
   public class MessageEventArgs : EventArgs
   {
       public string Message { get; private set; }
       public bool AddExtraNewLine { get; private set; }
       public MessageEventArgs(string message, bool addExtraNewLine)
       {
           Message = message;
           AddExtraNewLine = addExtraNewLine;
       }
   }
}

The “: EventArgs” is for this class to inherit from the base EventArgs class, a built-in class for event notifications. All custom event argument classes need to inherit from EventArgs.

There are two auto-properties in the class. They hold the Message, and a Boolean for if we want to add a blank line after the message, for spacing.

In the Player class, our eventhandler code will be a little different from what we used before. It looks like this:

public event EventHandler<MessageEventArgs> OnMessage;

The “EventHandler<MessageEventArgs>” signifies that the Player class will send an event notification with a MessageEventArgs object – the object with the message text we want to display.

Then, we add this function in the Player class, to raise the event:

private void RaiseMessage(string message, bool addExtraNewLine = false)
{
   if(OnMessage != null)
   {
       OnMessage(this, new MessageEventArgs(message, addExtraNewLine));
   }
}

When this function raises the event, it passes a MessageEventArgs, with the values the UI code needs.

Inside SuperAdventure.cs, we need to handle these events.

This line is added to SuperAdventure.cs’s constructor, to watch for these events:

_player.OnMessage += DisplayMessage;

And we add this DisplayMessage function to run when the OnMessage event is raised, and we want to add the new message to the UI:

private void DisplayMessage(object sender, MessageEventArgs messageEventArgs)
{
   rtbMessages.Text += messageEventArgs.Message + Environment.NewLine;
   if(messageEventArgs.AddExtraNewLine)
   {
       rtbMessages.Text += Environment.NewLine;
   }
   rtbMessages.SelectionStart = rtbMessages.Text.Length;
   rtbMessages.ScrollToCaret();
}

Notice that I also moved the old ScrollToBottom() code into this function. When the UI receives a message event, it will display the text and automatically scroll to the bottom of the rich text box.

Finally, I changed the code in the MoveTo, UseWeapon, and UsePotion functions to raise this event, instead of trying to write directly to rtbMessage.

Making the changes in your solution

At this point, everything was working again. I ran the program, and ensured it still worked the same – and it did. The refactoring was done, and it was time to check these changes into source control.

In your version of SuperAdventure, add the new MessageEventArgs class to the Engine project, and copy-paste the refactored code into SuperAdventure.cs and Player.cs. Then run your game, to ensure it works.

If you have any problems, please leave a comment and I’ll try to help you.

Summary

Sometimes, when you start refactoring, you need to make a lot of changes to get the program running again. But, if you’re doing refactoring correctly, you end up with much better code.

For example, after these changes, we could probably write a WPF or ASP.Net (web-based) version of the game very quickly. You would only need to create a new UI project (a WPF app, or an ASP.Net web app), add a reference to Engine, and create a simple UI page that does the same type of binding that SuperAdventure.cs does.

Also, by moving all the logic into a class library, we could easily create unit tests to ensure that our classes work correctly.

Source code for this lesson

Source code on GitHub

Source code on Dropbox

Next lesson: Lesson 21.0 – Plans for adding a vendor to locations

Previous lesson: Lesson 20.4 – Binding child list properties to a combobox

All lessons: Learn C# by Building a Simple RPG Index