Object-oriented dungeon crawler game

Question

I am creating a simple dungeon crawler game. My program runs and does what I want it to do so far, but I am starting to run into difficulty with adding new functionality, and I think one of the main issues is my class design.

I want to refactor my classes according to proper OOP principles, of which I am attempting to understand. I would like to have a better understanding of this now so that I will have an easier time going forward.

I am thinking about restructuring my classes according to the following:

Character:

• id
• name
• currenthp
• maximumhp
• level
• experience
• Room (Character should know its location, correct?)
• Monster (Character should also know its target, correct?)

Monster:

• id
• name
• currenthp
• maximumhp
• level
• Room (like Character, Monster should know its location?)
• Character (like Character, Monster should know its target?)

Room:

• id
• location
• The location of its doors
• Dungeon? (should Room know what Dungeon it is in?)
• Monster(s)? (should Room know what monsters are in it?)
• Character? (should Roomknow what character is in it?)

Dungeon:

• id
• name
• Rooms

Does the above seem like a reasonable design for my classes? My main question is: to what extent should each class know about the other classes?

Character class:

private class Character
{
    public string name { get; set; }
    public int level { get; set; }
    public Tuple<int, int> currentLocation { get; set; }
    public int currentHP { get; set; }
    public int maximumHP { get; set; }
    public Dungeon dungeon { get; set; }
    public Monster target { get; set; }

    public Character(string name, Dungeon dungeon)
    {
        this.name = name;
        level = 1;
        maximumHP = 100;
        currentHP = 100;
        this.dungeon = dungeon;

        switch (dungeon.Value)
        {
            case 1: //Dungeon 1
                currentLocation = new Tuple<int, int>(5, 0);
                break;
            case 2: //Dungeon 2
                currentLocation = new Tuple<int, int>(0, 0);
                break;
            case 3: //Dungeon 3
                currentLocation = new Tuple<int, int>(0, 0);
                break;
        }
    }

    public List<string> lookAroundRoom()
    {
        Room room = dungeon.DungeonLayout[currentLocation];
        List<string> targets = new List<string>();
        foreach (Monster monster in room.monster)
        {
            targets.Add(monster.Name);
        }
        return targets;
    }

    public Monster targetMonster(ListBox lst)
    {
        //I think this should be split into two methods
        //currently it does two things - sets the monster as the target
        //and then returns monster data
        Room room = dungeon.DungeonLayout[currentLocation];
        target = room.monster[lst.SelectedIndex];
        return target;
    }
}

Monster class:

public class Monster
{
    private static int autoIncrementID = 1;
    public int ID
    {
        get { return autoIncrementID; }
    }
    public string Name { get; set; }
    public int level { get; set; }
    public int currentHP { get; set; }
    public int maximumHP { get; set; }

    public Monster()
    {
        Name = $"Monster {autoIncrementID++}";
        currentHP = 20;
        maximumHP = 20;
        level = 1;
    }
}

public void MonsterDie(Room room, Monster monster)
{
    room.monster = null;
}

Room class:

public class Room
{
    public bool MoveNorth { get; set; }
    public bool MoveEast { get; set; }
    public bool MoveSouth { get; set; }
    public bool MoveWest { get; set; }
    public List<Monster> monster { get; set; }

    public Room(bool moveNorth = false, bool moveEast = false, bool moveSouth = false, bool moveWest = false)
    {
        MoveNorth = moveNorth;
        MoveEast = moveEast;
        MoveSouth = moveSouth;
        MoveWest = moveWest;

        monster = new List<Monster>();
        monster.Add(new Monster());
    }
}

Dungeon class:

public class Dungeon
{
    public string Name { get; set; }
    public int Value { get; set; }
    public Dictionary<Tuple<int, int>, Room> DungeonLayout { get; set; }

    public Dungeon(int value)
    {
        DungeonLayout = new Dictionary<Tuple<int, int>, Room>();

        switch (value)
        {
            case 1:
                Name = "Dungeon 1";
                Value = value;
                DungeonLayout.Add(new Tuple<int, int>(5, 0), new Room(false, false, false, true));
                DungeonLayout.Add(new Tuple<int, int>(4, 0), new Room(false, true, true, false));
                //Code truncated. The rest of this code contains 
                //more lines like the above two 
                //to generate the layout of the dungeon. 
        }
    }
}

Answer 1

First off, I wrote a series of articles about some of the problems of class design in this domain, though it really is about class design in general. Wizards and warriors is just the "fun" domain that makes it interesting:

https://ericlippert.com/2015/04/27/wizards-and-warriors-part-one/

You should read the whole series and understand all of it; the takeaway is: it is surprisingly hard to come up with good classes in the wizards and warriors domain, so don't feel bad if you are struggling with this. There are many pitfalls.

The other answer has some good advice, and some that is questionable. (There is a small dungeon class and a dark dungeon class, so what class do you use if you want a small, dark dungeon? Don't use the "inheritance pivot" on properties that are orthogonal. Just make a property "size" and a property "light" in the base class.)

Here's more good advice.

Several of your parenthetical questions are about location awareness:

Character should know its location, correct?

The classic way to solve this problem is to make every object that exists in the dungeon inherit from a common base class: GameObject, say. Every GameObject has:

• A parent, which is another GameObject; all game objects have a parent except the root, which is typically the dungeon. The parent of the key is the bag, the parent of the bag is the player, the parent of the player is the jail cell, the parent of the jail cell is the dungeon, which has no parent.
• A list, possibly empty, of child GameObjects.

And, most important:

• We require that the parent-child relationship be consistent! If the parent of the key is the bag, then the key must be a child of the bag.

Moving around the dungeon is now just a special case of the general problem of moving objects. When the dragon moves from the drawbridge to the moat, the dragon stops being a child of the drawbridge and starts being a child of the moat.

Getting these relationships coded correctly is of vital importance; you don't want "put the bag inside the bag" to produce an infinite regress, and you certainly don't want "put the library in the bag" to work. Think of all the ways things can go terribly wrong, and figure out a way to prevent them.

Looking at your class design: I notice that Character and Monster are almost exactly identical. This should tell you something. Characters and Monsters are the same thing. The difference between a character and a monster is that the characters actions are determined by the player, and the monsters actions are determined by an AI. But from the point of view of the game engine, they're the same. So make them the same.

Notice that in your proposed design you have silently baked limitations of the game into the type system. A monster can have only one location; OK, that seems reasonable. That location is a room -- too restrictive. You should be able to put the dragon in a cage, and the cage in a room. A monster can only target characters? Too restrictive; a dragon should be able to attack a werewolf. (Again, we see that characters and monsters are really the same thing.) A monster can only target one opponent? Too restrictive; what if the dragon wants to claw one character and fire breathe on another?

Think about what limitations you are baking in when you design your class hierarchies, and make sure you are only baking in things that really have to be invariants, like having a single location.

Finally, as I note in my series: use good OO design for more than just the game objects. There are lots of coding concepts in a game other than the objects manipulated by the player in the game; there are players and rules and commands and actions and many other concepts. Those are actually the core of your game engine; design them carefully too.

Answer 2

My main question is to what extent should each class know about the other classes?

At best nothing - they should know only about abstractions. (Further reading: The Dependency Inversion Principle)

I am starting to run into difficulty with adding new functionality,

Because your models are tigthly coupled. You need to loosen them by introducing some abstraction - either an interface or an abstract class.

All your model names sound like base classes. What is a Character? What is a Room? What is a Dungeon? Those are very general concepts and you alredy try to differenciate between them by setting a Value of a Dungeon - whatever the value means. You should find a better name for it - or a different Name.

(Further reading: The Open/Closed Principle)

So instead of creating a switch for each dungeon inside of a Dungeon constructor consider this design:

make the dungeon abstract:

abstract class Dungeon 
{
    protected Dungeon(string name, IReadonlyDictionary<...> layout)
    {
        Name = name;
        Layout = layout;
    }
    public string Name { get; }
    public IReadOnlyDictionary<Tuple<int, int>, Room> Layout { get; }
}

and derive from it other dungeons:

class SmallDungeon : Dungeon
{
    public Dungeon() : base("Small Dungeon", CreateLayout())
    {
    }

    private static IReadOnlyDictionary<...> CreateLayout()
    {
        return new Dictionary<...>
        {
             [new Tuple<int, int>(5, 0)] = new Room(false, false, false, true),
             [new Tuple<int, int>(4, 0)] = new Room(false, true, true, false)
        }
    }
}

and others:

class LargeDungeon : Dungeon { ... }
class DarkDungeon : Dungeon { ... }

You can/should apply the same technique to the characters, monsters and rooms.

abstract class Character { ... }
class Magician : Character { ... }
class Elf : Character { ... }

This way you'll be able to construct any combination of anything and I will be easy to add a new character or dungeon because you won't have to modify any of the existing classes but create a new one. Then you just register is somewhere and you're done.

---

This is only a good start. There are many more possibilities. You could for example create a dungeon factory or a layout factory but you can decide on this later when you need it.

---

You should also follow the PascalCase naming convention for public members.

---

Room

Why does the room have such properties like MoveX? Can a room move? They are not easy to understand. Consider a different name.

---

Tracking character location:

class CharacterLocationMap : IEnumerable<KeyValuePair<Character, Location>>
{
    // Could also be the ObservableCallection to get location updates
    private readonly IDictionary<Character, Location> _locations = new...

    public Location this[Character character]
    {
        // I assume a character must be somewhere - otherwise TryGetValue
        get { return _locations[character]; }
        set{ _locations[character] = value; }
    }    

    // IEnumerable<...> implementation return _locations.GetEnumerator();
}

now you need to derive the Room and Dungeon classes from an abstract class Location that will provide both locations some general properties like Name or maybe coordinates etc.