Everything here happens on screen, over time, and responds to a person. Selection and state, on top of the sequencing from Set 1.
You have motion, decisions, keyboard and mouse input, and collision. That is enough to build a small game, and these four are small games.
Build in stages and run after every one. A version with one working thing beats a version with three broken ones, and it is what you will be doing again at session 25.
Set 1's gaps were usually a missing number. Here they are almost always what the program should do after something happens— which the brief never says, because the person asking has not thought about it either.
A fragment, and what it leaves open:
When I catch it, it should be obvious that I caught it,and it should count.That is a normal way for a person to describe what they want, and it is not enough to write a program from. Here is what should end up in your requirements list:
- What does the ball do after a catch? Carry on, bounce, restart?- What counts as a catch - touching at all, or catching it on top?- Can one throw be caught twice if it stays against the paddle?- What does "obvious" mean? Pick one thing and do it properly- Does the game ever end, or does it just keep going?There is no right answer to any of those. There is only a decision you made or a decision you did not notice. Two programs that answer them differently are both correct; a program whose author never thought about it is the one that goes wrong in front of somebody.
Pick any two.
That is not a warning to avoid the hard two. If you want Paddle and Catch, write its requirements list on night one and build it after session 14. The list is the part you can do without the code, and it is the part being read.
For each of the two: the requirements list and the program folder.
The requirements list is the deliverable that is actually being read. The code is evidence you tried to satisfy your own list.
Worth 10 points, graded on completion.