---

Problem 1 (2 points)

As we discussed when we were learning about URLs and HTTP, HTTPS and HTTP are two protocols that are strongly related to one another, but not quite the same. In particular, HTTPS provides two things that HTTP does not: encryption and authentication. HTTPS only works if both of those things are in place; one or the other is not enough.

Suppose that a new protocol was designed, which we'll call HTTPE. HTTPE is identical to HTTP except that it provides encryption; in other words, it's HTTPS without the authentication.

1. What would be a scenario in which it would be better to use HTTPE?
2. What would be a scenario in which it would be better to use HTTPS?

What to submit

Submit one PDF file named problem1.pdf, which contains your answer to these two questions.

---

Problem 2 (6 points)

Background

Some of the first computer games I ever played were text adventures, in which the only inputs and outputs were text. Rather than seeing a two- or three-dimensional drawing of the current state of the world, you'd read a description of it instead. Rather than using a game controller — with buttons, joysticks, and so on — to interact with that world, you'd type in commands that described what you would want to do. As primitive as that sounds, there were some hugely successful games in this genre, especially in the late 1970s and throughout the 1980s; it's a genre best typified by the text adventures made by a company called Infocom, many of which I played when I was a kid, and many of which you can still find in a playable form online (in various shades of legality) today. (For what it's worth, the Infocom text adventure that I always found the most clever was called Suspended, though I never finished it.)

Of course, we're talking about games that ran on machines with only a tiny fraction of the processing power and memory available today, so there were plenty of limitations. What you could do in the game was limited by what commands you were allowed to type, as well as how well the parser for those commands was able to understand variations of them. With natural language processing still in its infancy in those days, those parsers were generally quite rigid in what they would allow you to say. Still, despite their limitations, some of these text adventures ended up on the pedestal with the gaming classics of their day, and the genre still exists today, known by more broadly descriptive name interactive fiction, thanks to a broader group of writers and a richer set of capabilities offered by decades of development in computer hardware, natural language processing techniques, and so on.

So, how would you write a text adventure? Infocom's approach was to build an "engine" of sorts, which it called the Z-machine, which took special instructions as input and executed them as a playable text adventure game. Essentially, they invented their own programming language, one that was just the right mix of functionality that would be needed for a text adventure, even if it wasn't suited to much else. Once they had done that, every one of their new games was really just a new set of data files that could run in the same implementation of the Z-machine. (These same ideas live on today in a project called Inform 7. Though my general sense is that it's a lot more advanced than the original Z-machine from the late 1970s, one of the things Inform 7 can do is generate a Z-machine version of the games you build with it.)

Constructing an entire text adventure engine is obviously much too large for us to tackle in a reinforcement exercise, but we can certainly nibble around the edges, while weaving some present-day functionality into a 1970s idea. Here's what we're going to do.

A simple text adventure game whose content has been written

Early in the pandemic, I wrote the content for a very simple text adventure game. Given our affiliation with UCI, we're known as Anteaters, so let's call our game Ants. The content is available at various URLs that begin like this:

• https://www.ics.uci.edu/~thornton/ics32a/Exercises/Set5/Ants/

Note that you won't find the content at that URL, specifically. The content is in multiple URLs underneath that one.

How does our game work?

In our game, our user will be in one location at a time. Those locations will have a few properties:

• A name, which is used to identify where its information can be found online. When the game starts, the user should be in a location called start. As the user enters commands, this will move the user from one location in the game to another.
• A title, which is a brief title that we display to the user when they first reach a location.
• A description, which is detailed information that we display to the user when they first reach a location.
• A collection of commands, which specify where the user will be moved as a result of entering various valid commands. Which commands are valid, and where the user goes as a result, is separately determined for each location.
• At least one location is a game over location, which is to say that the game ends when the user reaches that location.

These locations are described in data files that I've stored on the course web site. How you construct a URL for a particular location is to embed the location's name into the following URL:

• https://www.ics.uci.edu/~thornton/ics32a/Exercises/Set5/Ants/name.dat

So, what do the data files look like? Let's take a look at one of them. The game starts with the user in a location named start, so let's take a look at start.dat.

TITLE Hallway
DESCRIPTION
You are in an empty hallway, stretching in both directions, with white
walls, white tile floors, and white ceiling tiles.  It feels vaguely
like a hospital here.

You can go north or south from here.
END DESCRIPTION
COMMANDS
N,NORTH:outside_office
S,SOUTH:elevator
END COMMANDS

You can assume that locations will follow that basic format, which I've described in more detail below.

• The first line begins with TITLE, followed by a space. The rest of the line is the location's title. (Note that locations' titles can contain spaces.) So, this location's title is Hallway.
• The second line is the word DESCRIPTION by itself on a line. After that line, every line is part of the location's description, until a line that contains only END DESCRIPTION. So, this particular location's description is five lines long — and you'd want to show it to the user this way, printing separate lines separately.
• After that, a line containing only the word COMMANDS appears. After that line, every line is a collection of commands, each of which is a comma-separated list of commands (which you can assume will consist only of upper- or lowercase letters, digits, or spaces), followed by a colon, followed by the name of the location where the user will go if they enter that command. A line containing only END COMMANDS means that there are no more valid commands in this location.
• Most data files end after the line containing END COMMANDS, but if there's one more line that says GAME OVER, the location is one in which the game should end when the user reaches it.

So, in this case, we'd start out game in a hallway. The title and description would be displayed, then the user would be asked to enter a command. If the command was N or NORTH, the location would be changed to outside_office. If the command was S or SOUTH, the location would be changed to elevator. If the commands was anything else, the command would be invalid.

In deference to the puzzle-like nature of text adventures, we won't tell the user what commands are invalid. We'll let them figure it out. However, it's best to treat commands as case-insensitive, which is to say that it's fine for users to type north instead of NORTH or Open Door instead of OPEN DOOR.

What to build

Write a Python program that asks the user for the base URL for a text adventure game, then lets the user play it. So, for example, if the user specified the base URL below, they'd be able to play our Ants game. But if there were other games at other URLs that obeyed this format, they would be playable, too; what you're building is a "Z-machine," so to speak, not a particular text adventure game.

• https://www.ics.uci.edu/~thornton/ics32a/Exercises/Set5/Ants/

There are some safe assumptions you'll be able to make:

• The "start" location of every game will be in a data file named start.dat.
• All of the data files necessary for a game exist (i.e., no data file will specify that a command will take the user to a location for which the data file is missing).
• All of the data files are in the format described above. It's not important to us what happens when your program encounters a data file that's invalid in some way; we'll only test your submission with complete games in proper formats.

How to test your program

You can test your program in any way you'd like. We aren't requiring assert-based tests (or any other test automation, for that matter), but you can certainly write them if you'd like.

What to submit

Submit one Python script named problem2.py, which contains the implementation of your simplified text adventure engine.

---

Problem 3 (1 point)

Suppose that the data files describing the simplified text engine described in Problem 2 had been written in JavaScript Object Notation (JSON), as opposed to the bespoke format that I designed specifically for that particular problem. In your view, would that have made Problem 2 easier or more difficult to solve? In no more than a couple of sentences, justify why you think so.

What to submit

Submit one PDF file named problem3.pdf, which answers this question.

---

Problem 4 (1 point)

When we wrote programs to interact with Web APIs and expected to receive text, we explicitly specified an encoding called UTF-8.

1. Why was it important for us to specify an encoding?
2. How do you think, in a practical circumstance, we would be able to find out what the appropriate encoding would be, if we weren't blindly assuming that UTF-8 was the correct encoding?

What to submit

Submit one PDF file named problem4.pdf, which contains your answers to these two questions.

---

Deliverables

In Canvas, you'll find a separate submission area for each problem. Submit your solution to each problem into the appropriate submission area. Be sure that you're submitting the correct file into the correct area (i.e., submitting your Problem 1 solution to the area for Problem 1, and so on). Under no circumstances will we offer credit for files submitted in the incorrect area.

Submit each file as-is, without putting it into a Zip file or arranging it in any other way. If we asked for a PDF, for example, all we want is a PDF; no more, no less. If you submit something other than what we asked for (e.g., a text file when we asked for a PDF, even if its filename ends in .pdf), we will not be offering you any credit on the submission. There are no exceptions to this rule.

Of course, you should also be aware that you're responsible for submitting precisely the version of your work that you want graded. We won't regrade an exercise simply because you submitted the wrong version accidentally.

Can I submit after the deadline?

Unlike some of the projects in this course, the reinforcement exercises cannot be submitted after the deadline; there is no late policy for these. Each is worth only 3% of your grade, with the lowest score dropped — see the Reinforcement Exercises page for details — so it's not a disaster if you miss one of them along the way.

You're responsible for making a submission in order to receive credit, which means you'll want to be sure that you've remembered to submit your work and verify in Canvas that it's been received. A later claim of having forgotten to submit your work or having misremembered the due date will not be grounds for a resubmission under any circumstances.

What do I do if Canvas adjusts my filename?

Canvas will sometimes modify your filenames when you submit them (e.g., by adding a numbering scheme like -1 or a long sequence of hexadecimal digits to its name). In general, this is fine; as long as the file you submitted has the correct name prior to submission, we'll be able to obtain it with that same name, even if Canvas adjusts it.