Contents8. North, east, south, west
|
by Ruud Helderman <r.helderman@hccnet.nl>
Licensed under MIT License
Traditional text adventures use compass directions to navigate.
For example, on the map I drew in chapter 6, the player might want to enter go east to move from the field to the cave. We can implement this by giving passage intoCave the tag “east”. However, there are two problems that we need to solve first.
These problems apply to other objects as well, not just passages. In our adventure, we have a silver coin and a gold coin. On the one hand, it would be silly not to accept get coin in a location where only one of the coins is present. On the other hand, it should be possible to use get silver coin instead in case both coins are present at the same location.
This immediately brings us to a third problem with our parser:
All three problems will be solved in this chapter, starting with problem #1. It is resolved by giving each object a list of tags, instead of just a single tag.
Sample output |
---|
Welcome to Little Cave Adventure.
You are in an open field. You see: a silver coin a burly guard a cave entrance to the east dense forest all around --> get coin You pick up a silver coin. --> go west You can't get much closer than this. --> go east OK. You are in a little cave. You see: a gold coin an exit to the west solid rock all around --> go west OK. You are in an open field. You see: a burly guard a cave entrance to the east dense forest all around --> go entrance OK. You are in a little cave. You see: a gold coin an exit to the west solid rock all around --> drop coin You drop a silver coin. --> get coin Please be specific about which coin you mean. --> get gold coin You pick up a gold coin. --> quit Bye! |
object.h |
---|
|
object.c |
---|
|
Explanation:
Of course, for this change to take effect, we also need to adjust function objectHasTag in noun.c.
In the same module, we can also fix problem #2. Partially, this problem was already solved in the previous chapter. The distance check introduced there, already makes it less likely to find more than one matching object. A tag like ‘east’ would always match a passage originating from the current location, and never conflict with eastbound exits in other locations. But the possibility is still there; the silver and gold coin might end up in the same room. So how to choose between them, based on their mutual tag ‘coin’? The answer is, we cannot, and so we should not. So instead of randomly picking either object, we will let functions getVisible and getPossession inform the player he has to be more specific.
noun.h |
---|
|
noun.c |
|
Explanation:
Problem #3 can be fixed by simply removing a single space character from function parseAndExecute (line 10 below). This solution is far from perfect (a double space between ‘silver’ and ‘coin’ is not accepted), but it will do until we make ourselves a better parser in chapter 13.
parsexec.c |
---|
|
Modules main.c, inventory.c, location.c, move.c and misc.c remain unchanged, you can see them in the previous chapters.
Now that the array of objects (object.c) starts to grow in multiple dimensions (in particular with the introduction of multiple tags), we need a way to make it more maintainable. We will do so in the next chapter.
⭳ Download source code 🌀 Run on Repl.it |
Next chapter: 9. Code generation