You've written a simple game engine but there's no actual "game" yet. There are a great many elements that can go into the design of a game, but let's make it simple for now. Roguelike games are traditionally "fetch quests": go into the dungeon, find the magic amulet, leave with the amulet. If you die along the way, you lose, if you leave without the amulet, you lose. If you leave with the amulet, you win.
- Create two more entity classes,
UpStairway and Amulet.
- When you create the level, also create an amulet and place it at a random location in a room.
- To draw an amulet entity to the display use
".
- Create an up stairway in the same location you generated for the player -- because the player just came down the stairs to enter the dungeon.
- To draw an up stairway use
< (mnemonic: the depth is getting smaller).
- You now have a new problem: it is possible for three entities to all be on the same cell. You could have one cell that contains a stairway, an amulet, and a player. How should that cell be displayed? The order we want is players (and later, monsters) get highest priority, then items like amulets or swords, then "furniture" like doors, stairways, boxes, and so on. Make sure the rendering code correctly handles this situation. Don't forget that writing tests is a good practice.
- Add a new command key for "pick up", and an associated
Action. Traditionally in roguelike games , is "pick up". If the player does a pick up action, work it out like this: the player's parent is the current level. That level's children are things that the player might be trying to pick up. Make a list of all the level's child entities that are (1) on the same cell as the player, and (2) "portable" -- the player cannot pick up themself, and also cannot pick up stairways, doors, and so on. Re-parent all the portable entities from the level to the player.
- Add a new command key and
Action for "climb stairs". Traditionally the < key is for climbing, which makes sense. This time, check the player's parent -- a level -- to see if it has a stairway child at this location. If no, ignore the keypress. If yes, do the logic for going up the exit stairway. That is: if leaving with the amulet, you win, if leaving without the amulet, you lose.
This is a pretty easy game so far. We'll make it harder.
You've written a simple game engine but there's no actual "game" yet. There are a great many elements that can go into the design of a game, but let's make it simple for now. Roguelike games are traditionally "fetch quests": go into the dungeon, find the magic amulet, leave with the amulet. If you die along the way, you lose, if you leave without the amulet, you lose. If you leave with the amulet, you win.
UpStairwayandAmulet.".<(mnemonic: the depth is getting smaller).Action. Traditionally in roguelike games,is "pick up". If the player does a pick up action, work it out like this: the player's parent is the current level. That level's children are things that the player might be trying to pick up. Make a list of all the level's child entities that are (1) on the same cell as the player, and (2) "portable" -- the player cannot pick up themself, and also cannot pick up stairways, doors, and so on. Re-parent all the portable entities from the level to the player.Actionfor "climb stairs". Traditionally the<key is for climbing, which makes sense. This time, check the player's parent -- a level -- to see if it has a stairway child at this location. If no, ignore the keypress. If yes, do the logic for going up the exit stairway. That is: if leaving with the amulet, you win, if leaving without the amulet, you lose.This is a pretty easy game so far. We'll make it harder.