Due date and time: Tuesday, February 22, 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)
When presented with the instructions that guide them toward creating virtual environments in the context of our discussion of Third-Party Libraries, I've found that many students over the years have ignored them altogether, or have asked me, in so many words, "Why do I have to do this?" And, of course, I can understand that impulse; when working amongst a lot of complexity, it's healthy to want to skip some of it, thinking instead "I'll figure this out later."
Yet, despite its requirement that you wade into the waters of the command line and issue commands like python -m venv . or pip3 install pygame, I'm asking you to do it, but it's not a gratuitous thing. It solves a problem, albeit one that you might not notice that you have right away. (That's the thing about tools like these; it's not always clear initially why some of their complexity is there, which is why it's important to stop and think about it early.)
Let's assume that you never use a virtual environment. What problem might you be susceptible to, which wouldn't have affected you if you had used virtual environments instead? Two or three sentences is enough here, and if you think there are multiple problems that virtual environments solve, you don't need to list all of them; describing one of them in a little bit of depth is better than scratching the surface of more than one of them.
What to submit
Submit one PDF file named problem1.pdf, which contains your answer to this question.
Problem 2 (2 points)
We started learning this week about the basics of a library called PyGame. Like most libraries, PyGame solves a lot of problems for us, but requires us to adopt its point of view on how best to solve those problems. What we get when we use a library is the right to take a lot of work off of our plates; what we give up is for that work to be done the way we would have preferred it. That doesn't mean it's not often worth the trade, but it's wise to be cognizant that there's a tradeoff there.
Let's explore some of the design choices that PyGame made by answering a couple of questions about them.
- Why do we need to "flip" the display in order to see what we've drawn? Of course, the short answer is "So we can see what we drew!", but that's not really the interesting question. The interesting question is this: Why was PyGame designed so that we have to flip the display before we see what was drawn?
- What is the purpose of using PyGame's Clock class? We saw that we can call tick on a Clock object to, for example, establish a frame rate of 30 frames per second. But what is a practical benefit of doing that, when we could instead run at a much higher rate?
What to submit
Submit one PDF file named problem2.pdf, which contains your answers to these two questions.
Problem 3 (2 points)
One of the new techniques we used in the Spots example was what we might call model-view separation, which is to say that we separated the code that manipulated our program's model from the code that manipulated our program's view. This is a fairly common technique in programs that have user interfaces, not just in games written using PyGame, so it's worth stopping to make sure you understand why we did it. Let's explore that by considering some questions about it.
- What problem does a model focus on?
- What problem does a view focus on?
- In no more than a sentence or two each, what are at least two benefits of separating the code that manipulates the model from the code that manipulates the view?
What to submit
Submit one PDF file named problem3.pdf, which contains your answers to these three questions.
Problem 4 (4 points)
When we built the Spots example in lecture, we used two different coordinate systems to represent points in two-dimensional space: fractional coordinates and pixel coordinates. Fractional and pixel coordinates, though, aren't the only way to represent two-dimensional space, so let's explore another. Mathematics gives us a mechanism called polar coordinates, which represent a point in two dimensional space in terms of two values: a radius (i.e., the distance of that point from the origin) and an angle (i.e., in what direction we'd travel from the origin to get to that point). We can think of the angles as being measured in degrees, with 0° meaning that we'd travel directly to the right, 90° meaning that we'd travel directly upward, and so on. Lots more details on polar coordinates can be found at the Wikipedia link below, though you won't need too much of that detail for our purposes here.
Below is a Python script with an almost complete program written, but with one key piece missing.
When complete, it draws a collection of blips, which are yellow circles that travel around the display in a spiral pattern, beginning from the center. A new blip appears once per second, but each blip moves a little bit every 1/30th of a second. After you've done your work and the program has been running for a while, this is what it would look like.
The problem is that, as provided, the program draws all of the blips in the same place — in the top-left corner of the display — no matter how much time has passed. How you'll solve this problem is to rewrite the function _determine_blip_center, which has been provided with an incorrect implementation. Replace its implementation with a correct one — one that performs the appropriate coordination conversion to allow PyGame to know where to draw the blips.
We'll need to agree on one convention for what our polar coordinates mean. We'll say that a radius of 1 means the distance from the center of the display to the edge of the display, so that a point with a radius of 1 and an angle of 0° would be along the rightmost edge of the display (halfway up), a point with a radius of 1 and an angle of 90° would be along the topmost edge of the display (halfway across), and so on. The display is resizable, but this rule applies no matter what the size of the display is.
(Note, too, that this particular program doesn't separate model and view implementations into separate modules, and it has one monolithic run() function that does almost everything in one long loop, and that's fine; our goal here is to explore the one technique you're implementing, but this is hardly a paragon of software design otherwise.)
What to submit
Submit the one Python script named problem4.py that we provided, with your updated _determine_blip_center function, which will be enough to solve the problem.
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.