Of course you have to know "all" the instructions to write assembly code (just like you need to know "all" keywords to write C), and for some of them you need to know "all" the side effects, too. What you do not know by heart you have to lookup, and being new to the AVR I spent a lot of time with ^F in the manual.
The writing took about an hour or two, much time spent just thinking and selecting the instructions. That some registers can be set to a value, and others only can copy from another register or SRAM required a little getting used to. Some change the status register falgs, some do not - important for branch instructions.
Originally I had set aside a number of SRAM variables, but I have so few of them I can keep it all in registers. This led to a sidetrack om how to rename registers for convinience. Not sure I'll do that in the final version. Pros and Cons to everything.
I did the writing in a text editor, then cut-n-pasted it to the simulator. A pass or two for minor syntax errors. (Sometimes the Assembly syntax errors may not show in the text window. Open the browser console window (Shift-Ctrl-I for the Chrome browser))
I started it ... and it did not run (surprise! - not)
The BREAK implementation in the simulator, which dumps all registers to the browsers console window, was suffcient to find the few foreheadslapping flaws, taking less than an hour. Although the course did show a lot on using the gdb debugger, it is another large program to learn to handle.
The code is a little too long to display in-line in the log, so see the uploaded file of the working version https://cdn.hackaday.io/files/1779167611958144/Pong.v02.S
The code is a little confusing - no consistency in register allocation (Tmp2/R20 usage), not sure if using register aliases makes it clearer. I alternate between "tense"/"smart" code and clear or obvious code (but less efficient). The symbol/defines to handle different display sizes is non-functional, 8x16 is hardwired in some parts. I could write it cleaner, but not this time.
I have sketched out my basic flow diagram and routinesfor a minimum working game. But first another partial version, where I only have the two bats, one controlled by buttons (the player) the other by a timer (the computer).