Creating an Interactive Fiction Game with UEFI (Part 2)

In the last blog post, I wrote about the basic structs needed to create an interactive fiction game in UEFI.  This time, I'll talk about the actual game loop and the function that interprets user input.
When writing a game, unless there are only a set number of turns, the game will continue until a player either wins or loses.  In interactive fiction games, there is only one player, so it is fairly simple to keep track of that one player's win or loss status.  The game will continue to loop so long as the player has not lost or won the game.

Now, in my game, there is no way to lose.  You simply continue playing until you quit, or you have figured out how to win.  Therefore, my loop only has one condition: the winning condition.  Because the goal of my game is to escape from a building, I simply made it so that once the player has done so, the room they enter is simply NULL.  That way, the loop will continue so long as the character has not entered that room yet.
Once inside the loop, we have a string (creatively named string) that will store the user input.  At the beginning of the loop, we set it to NULL just to make sure no garbage gets mixed in.  Then we print a little prompt for user input, a simple ">", and then wait for the player to enter a command.  As soon as they enter a carriage return, I use strtok() to get the first word, and store it as the verb.  The user input string will be divided, eventually, into two parts: the verb and the noun.  For now, though, all I need is the verb, to make sure that the user didn't enter an empty string or a set of spaces.  So I check to see if the verb is NULL.  If so, it skips the rest of the loop, and will continue to prompt the player for input until they actually type something.
After something is entered, I then use strtok() again to concatenate the rest of the user input string together and store it into noun.  Once the rest of the input has been properly stored away, I call takeAction(), which uses the user input to determine which functions to call to carry out the appropriate action.  Now, I put it inside an if statement because takeAction() returns a value.  For most commands, or even nonsense, it will simply return 0.  However, if the user enters "quit" or "exit", it will return 1.  After confirming the user's command, the loop will exit.

Now, I will spend a little time on takeAction(), though it is truly a very simple function.  All it does is take the user input and determine which functions to call so the desired action is carried out.  In essence, all it contains is several if statements, comparing the user input to several anticipated strings.  I used strcasecmp() to compare the strings so there is no problem whether or not the player has odd capitalization habits.


The most basic function is move(), and it has the most possible inputs.  This could also be handled by checking to see if the user entered "go," "move," or "walk" and then specified a direction, and pass the direction into move() as well.  Many people who play interactive fiction, however, tend to get lazy and will just type the shortest command possible.  


The rest of the commands are ones that I have found very common and useful in most interactive fiction games.  Some of them, like take and drop are player actions that cause a change in the game state.  Others, like inventory or help, are helper functions to lend a hand to the user.  And then are the "just for fun" commands, like yell, that don't do anything significant, but the game accounts for them.  If the player wants to quit, this function will return 1 instead of 0, and the game loop will account for that.  Finally, if the player enters gibberish or a command that wasn't accounted for, this function will print out a statement, and the game loop will continue.  

Finally, I'll talk a bit about move(), just to show a little real action.  This function takes the character and a string as parameters.  Now, all of these separate functions will take the Character as a parameter because the Character functions as a sort of game state, keeping track of location and objects held.

The first step in this function is to interpret exactly which direction the user wants to go.  So we get the room the character is currently in, determine which direction the player wanted, and then get the corresponding exit.

Now, next is determining whether or not you can go that way. It's simple enough.  Either there is no Room in that direction (exit.room == NULL) or the door is locked (exit.locked).  If you can't go, you print out the exit's pre-defined statement on why you can't go that way and exit the method.  Now, I put a little something in there so that if the door is locked and you have the key in your possession, it prompts you to unlock the door.  I may change it later so that it automatically unlocks the door if you have the key, but for now, it simply prompts the player.

And finally, if there is a way out in the specified direction and it's not locked, it sets the character's current room to the one designated by the exit, prints out the new room name and has the character "look" at the room.

Of course, the basics of a game are pretty straightforward.  The actual hard work is finding an engineer who can write decent interactive fiction.  Next time, I'll focus on a different category of game.

Also, if anyone is interested in the code, I will zip it up and send it to you if you send me a note.

Creating an Interactive Fiction Game with UEFI (Part 1)

Recently, I've been putting together a text-based game using Main as a starting point.  The game is an interactive fiction game, similar to Zork.  Essentially, every room and object is described, and the player simply types in commands such as "take book," "north," "unlock door" and so on.  Imagine it as a more flexible version of a choose your own adventure.  There are plenty of examples at ifdb.tads.org.  I am particularly fond of this type of game because it's like a mix of books and video games.  The creators have to put a lot of thought into what the player would be thinking of doing, and a lot of times, their descriptions of the world are so complete that they might as well be writing a novel.  Also, depending on how the creator decides to make the game, it can lean more towards the puzzle side or the story side.  It could be a one-room game, where your goal is simply to unlock the door, or it could be a fantasy story where you are some knight hunting a dragon.  It's an extremely flexible medium.

In the game I'm writing, you play as a little girl who is living in her uncle's house for the summer.  Her uncle has gone out for the day and locked her inside the house, but she wants to go outside and play.  So, while her uncle is away, she runs around the house trying to find a way outside.

Since UEFI contains the entire C lib, I am writing this game in C.  Unfortunately, I'm used to writing in object-oriented languages, so getting used to using structs was a challenge.  In this style of game, I used four different structs to create the basic world: Character, Object, Room, and Exit.  So in the following sections, I'll describe each struct and its purpose.


Character
A Character is, in essence, the player.  It keeps track of what items are being held in the player's inventory and what room the player is currently in.  Let's walk through each element here.  First is a pointer to a Room.  That's the room that the player is currently "in."  It limits the Objects that the player can interact with to those in the Room, and also limits the Rooms a player can go to.  We will talk more about the Room and its limitations later.  Next is the description.  This is an optional part, but I like to put it here anyways.  It's a description of your character.  So if the player decides to enter "examine self" as a command, there is a description to print out, rather than having to say, "You don't see that here."  After that is an int value that stores the number of objects currently in the player's inventory.  It serves several purposes.  Not only does it provide an easy way to see if your character is carrying too much to pick up another object, it also makes it easier to insert a new object into the inventory, by simply using the number of objects as the index of the next object.  Finally is the actual array of Objects that is the inventory.  These objects move around with the Character so that the Character can interact with them and use them no matter which room they're in.


Object
An Object is something the player can interact with, whether it be simply examining it, picking it up, or opening it.  They all have descriptions and BOOLEAN values for whether or not they can be picked up.  Now, the objects are a little strange.  I have two names for objects, name and checkName. The purpose of checkName is to compare the noun that was entered by the user to the object.  The way the scanner works, it concatenates all parts of the noun together, so if someone were to type in "examine candle holders," the noun that would be passed into the function would be "candleholders."  So the checkName is there to determine which Object the user was referring to.  name, on the other hand, is only there for movable objects, for listing purposes in the inventory.  So when the player decides to check what Objects they are carrying at the moment, it doesn't print "candleholders", but it will instead say "some candle holders."  The description is a more detailed description of the object.  It allows the player to "examine" things and get a better idea of the world the game takes place in.  After that come two booleans, movable and hidden.  Movable determines whether or not an object is static and can be picked up.  Sometimes, it is immovable simply because it would be impractical to pick up an object, like a bed.  Other times, you have an object that provides an additional detail to the world, but it is not needed to complete the game, like a doll.  Hidden determines whether an object is listed in the room description.  Any movable, not hidden objects will be listed at the end of the room description, like "You see a key here.  You see a broom here." If the object is hidden, it will not be listed.  For example, I may have a blanket on the bed, but I don't want to list that because it's unnecessary.  So I mark the object as hidden and it will not be printed.  Finally is a string used when you are unable to pick something up.  If you try and pick up an immovable object, this string will be printed out instead.  It could say something like, "That's too heavy to carry," or "You don't think you will need that."


Room

A Room is a "location" that limits where your character can go and what objects it can interact with.  It contains a description, an array of Objects it contains, and an array of Exits.  First in the struct is the name.  Whenever a player enters a new room, the name is displayed.  It makes it easier on the player when they are making a map of the world which they explore.  Secondly is the description.  This is similar to the object description in that it provides a more detailed view of what the room looks like.  It is also important here to list major static objects (not ones that can be picked up, because those can leave the room) and other things that the player can interact with.  Also, be sure to list in what directions the exits are located.  Next is the number of objects located in the room.  This serves the same purpose as the corresponding value in the Character struct.  Same with the inventory.  Finally comes the array of Exits.  Depending on how your map is set up, you can have your basic four exits (north, south, east, west), or perhaps even ten (all eight compass points plus up and down).  It all depends on how you create your world.   These will keep track of which directions you can go from your current room.  Each position in the array corresponds to a direction (south, northeast, etc).  All positions in the array will always be filled, whether or not the player can go that direction.  I'll discuss Exits further in the next section. 


Exit
Exits keep track of which Rooms a Character can go to from a given Room, and whether or not the "door" is locked.  First in the struct is a boolean value for whether or not the exit is locked.  This will prevent the player from going through this Exit to the next Room.  The next value is a pointer to the Room this Exit leads to.  Once the player is able to go through this exit, they will be in that Room.  Sometimes, though, the exit doesn't lead to a room, because there is no "door" there.  In that case, this will be a NULL pointer.  Next is a string that is printed out when a player cannot go through this exit.  Whether it is locked or there is no Room to to to in that direction, this message will be printed.  It could be something like, "The door seems to be locked," or, "There's a wall in that direction."  Finally is the key.  If the door is locked and you want it to be able to be unlocked using an Object (whether it be an actual key, a pry bar, a duck, whatever), this will keep track of what can be used to unlock the door.  


So those are the basic building blocks of an interactive fiction world.  By putting all these together, you can make a nice little map that your player can explore and interact with.


Next time, I will discuss the game loop itself and its components