The game has a solid foundation and now we start building on it. There are still a lot of features to finish and bugs to work out along the way, especially the individual inventory items that will help the player survive in the dungeons.

After cleaning up from the program refactoring, I decided to complete the programming on the player stats. Then things got real when the monsters started fighting back.

Evolution is often a difficult process and our program is definitely evolving. In this chapter, we bring the monsters to life and deal with a major refactoring of code as the need to store data increases.

Now that we have some requirements for the monsters, it’s time to build the class and add a few new guests to the dungeon. As always, building the class requires some serious attention to detail.

It’s a bit lonely in this dungeon game so it’s time to add some monsters and there’s a lot more to it than you’d think. In this chapter, I detail some of what’s involved in adding opponents to our roguelike.

Before we can introduce monsters and fights to the game, the player needs some items such as weapons in inventory. It’s time to test some of the theory the Inventory class is built on.

Fast Play mode lets the player zip around the map without having to press the direction keys for every space but each space still equals one turn. In this chapter, we code for that and a couple other odds and ends.

Food is one of the most important items that you look for on the map so it’s appropriate that food be the first inventory item that we implement in our roguelike game. In this chapter, I’ll demonstrate how the player’s level of hunger can be managed and write the function that will allow the player to consume food and keep going.

In addition to collecting inventory, the player needs to be able to view their inventory and manage its contents so they can have the specific items they need. We also need a way to display other screens and come back to the map when needed.

The inventory items have a complete cycle throughout this game, depending on the item, and each step has to be coded so that the inventory exists and is managed just like inventory items would be in real life. Every part of the program will be affected in some way.