This is a good time to think about the "flavour" of your game. The "flavour" is the stuff that does not affect the mechanics of the game -- the game engine doesn't care whether you call the enemies goblins, spiders or terrorists. It doesn't care whether a "dungeon" is a system of caves, a skyscraper, a crashed spaceship, whatever. If you want to stick with "fantasy dungeon with a magic amulet" flavour, that's fine -- pick a kind of monster that works with that flavour.
- Create a new abstract base class
Monster derived from Entity, and a derived class of your choice. Orc or Ghost or whatever.
- Once you've created a subclass, populate the level with some random number of monsters -- they are children of the
Level, just like the player, the staircases, and so on. Make sure monsters do not overlap each other or the player.
- After the player moves, every monster in a level also gets a chance to take an action. For now they can randomly generate a "move" action.
- Resolve each monster's move action the same way you resolve the player's move action: if they've attempted to move to a walkable cell, they do so, otherwise, they do not.
- Add new logic that makes a cell that already contains a monster or player "unwalkable", because we don't want two monsters, or a monster and the player, on the same cell at the same time.
This is a good time to think about the "flavour" of your game. The "flavour" is the stuff that does not affect the mechanics of the game -- the game engine doesn't care whether you call the enemies goblins, spiders or terrorists. It doesn't care whether a "dungeon" is a system of caves, a skyscraper, a crashed spaceship, whatever. If you want to stick with "fantasy dungeon with a magic amulet" flavour, that's fine -- pick a kind of monster that works with that flavour.
Monsterderived fromEntity, and a derived class of your choice.OrcorGhostor whatever.Level, just like the player, the staircases, and so on. Make sure monsters do not overlap each other or the player.