Roguelike Tutorial, using python3+tdl, part 5
This is part of a series of tutorials; the main page can be found here.
The tutorial uses tdl version 3.1.0 and Python 3.5
Preparing for combat
Populating the dungeon
Can you feel that? It's the sense of anticipation in the air! That's right, from now on we won't rest until our game lets us smite some pitiful minions of evil, for great justice! It'll be a long journey, and the code will become more complicated, but there's no point in tip-toeing around it any more; it's a game and we want to play it. Some sections will be a bit of a drag, but if you survive that, the next part will be much more fun and rewarding.
We're going to be adding more colored items in this section, so we're going to add a file to our project folder to make this easier. It is called colors.py, and it can be found here. I contains a list of color names and their RGB codes. It will allow us to access a color by typing colors.white instead of (255, 255, 255). You can look at here to see all the colors. Note that while the webpage uses camelcase ("desaturatedRed"), colors.py uses underscores ("desaturared_red"). Make sure the file is saved in your project folder, and add it to your imports.
Returning to the game, let's handle monster placement. While this may seem daunting, it's actually pretty simple, thanks to our generic object system! It only requires us to create a new object and append it to the objects list. Therefore, all we need to do is, for each room, create a few monsters in random positions. So we'll create a simple function to populate a room:
The constant MAX_ROOM_MONSTERS = 3 will be defined with the other constants so that it can be easily tweaked.
I decided to create orcs and trolls, but you can choose anything else. In fact, you should change this function as much as you want! This is probably the simplest method. If you want to add more monsters, you'll need to keep the random value in a variable and compare it multiple times, using this pattern:
As an alternative, you could define a number of pre-set squads and choose one of them randomly, each squad being a combination of some monsters (for example, one troll and a few orcs, or 50% orcs and 50% goblin archers). The sky is the limit! You can also place items in the same manner, but we'll get to that later.
Now, for the dungeon generator to place monsters in each room, call this function right before adding the new room to the list, inside make_map:
There! I also removed the dummy NPC from the initial objects list (before the main loop): it won't be needed any more.
Here, we'll add a few bits that are necessary before we can move on. First, blocking objects. We don't want more than one monster standing in the same tile, because only one will show up and the rest will be hidden! Some objects, especially items, don't block (it would be silly if you couldn't stand right next to a healing potion!), so each object will have an extra "blocks" property. We'll also take the opportunity to allow each object to have a name, which will be useful for game messages and the Graphical User Interface (GUI), which we'll go over later. Just add these two properties to the beginning of the GameObject 's __init__ method:
Now, we'll create a function that tests if a tile is blocked, whether due to a wall or an object blocking it. It's very simple, but it will be useful in a lot of places, and will save you a lot of headaches further down the line.
OK, now it's time to give it some use! First of all, in the Object 's move method, change the if condition to:
Anyone, including the player, can't move over a blocking object now! Next, in the place_objects function, we'll see if the tile is unblocked before placing a new monster:
Don't forget to indent the lines after that. This guarantees that monsters don't overlap! And since objects have two more properties, we need to define them whenever we create one, such as the line that creates the player object. Replace the old object initialization code:
And update the code that creates the monsters:
If you added the optional room "numbers" in part 3, you'll need to update the code to include a name.
Last stop before we get to the actual combat system! Our input system has a fatal flaw: player actions (movement, combat) and other keys (fullscreen, other options) are handled the same way. We need to separate them. This way, if the player pauses or dies he can't move or fight, but can press other keys. We also want to know if the player's input means he finished his turn or not; changing to fullscreen shouldn't count as a turn. I know they're just simple details - but the game would be incredibly annoying without them! We only need two global variables, the game state and the player's last action (set before the main loop).
Inside handle_keys, the movement/combat keys can only be used if the game state is "playing":
We'll also change the same function so it returns a string with the type of player action. Instead of returning True to exit the game, return a special string:
And testing for all the movement keys, if the player didn't press any, then he didn't take a turn, so return a special string in that case:
After the call to handle_keys in the main loop, we can check for the special string 'exit' to exit the game. Later we'll do other stuff according to the player_action string.
For the first part of the combat system we have to manage the player and monsters taking combat turns, as well as the player making an attack. To make it simple, the player takes his turn first, in handle_keys. If he took a turn, all the monsters take theirs. This goes after the handle_keys block in the main loop:
That's just a debug message, in the next part we'll call an AI routine to move and attack. Now we'll take care of the player input. Since he can attack now, instead of calling move (inside handle_keys) like this:
...we'll make a function called player_move_or_attack and replace all those 4 blocks with calls like this:
The function itself has a few lines of code but doesn't do anything extraordinary. It has to check if there's an object in the direction the player wants to move. If so, a debug message will be printed (this will later be replaced by an actual attack) If not, the player will just move there.
Alright, the code is ready to test! No damage is done yet but you can see the monsters taking their turns after you (notice when you switch to fullscreen it doesn't count as a turn, yay!), and you can bump into them to heroically but unsuccessfully try to destroy them!
The whole code so far is available here.
Guess what's next?