ICS 32 Winter 2022
Exercise Set 4
Due date and time: Friday, February 4, 11:59pm
Getting started
First of all, be sure that you've read the Reinforcement Exercises page, which explains everything you'll need to know, generally, about how the reinforcement exercises will work this quarter. Make sure you read that page before you continue with this one.
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.
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, a lot of those parsers were 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 classics of their day, and the genre still exists today, known by more broadly-descriptive name interactive fiction, thanks to its 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
I've written 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:
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:
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:
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.
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.
There are some safe assumptions you'll be able to make:
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.
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, 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, and we won't be able to offer any credit on exercises that you forgot to submit.
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, so it's not a disaster if you miss one of them along the way.