Programming Class Week 5
This week was programming an implementation of Memory (the card game) and a big lesson on lists and dictionaries. There was also a lecture that was mostly devoted to the concept of iterative improvement and how important it is to programming.
The name does basically say it all, but I'll describe it anyway to avoid any confusion--don't do everything at once. Unless you are The One, destined to obtain power over the Matrix and defeat the machines, the programs you write will have errors. Some of them will be obvious because the program won't work at all, and modern languages tend to be reasonably good at telling you where a program breaks if the syntax is wrong. Sometimes the program works but it just provides a bad output, and if the entire program is all crafted at the same time, it's incredibly difficult to figure out exactly where the point of failure is. Much better to do step 1, make sure it works, do step 2, make sure that works with step 1, etc., until the entire thing works together.
Though as a story, sometimes syntax errors just screw things up. I was reading a forum thread where someone was trying to add a Coptic culture to Crusader Kings II and ended up with most of England filled with Noculture kingdoms speaking Noculturian. A later post in the thread suggested an unmatched parenthesis as the most probable cause. Oops.
I still have 100% in the course, though some feedback I got on last week's project was enlightening. I wrote Pong, and there were variables for the width of the paddle, the radius of the ball, the height of the paddle, and so on. When I calculated when score should be counted and when the ball should bounce back, I tended to calculate it in absolute distance by eyeballing it and adjusting the pixel count, and in the end, the program worked, so I submitted it. The feedback suggested I use the variables and that my code was hard to read because I hadn't used them, and until I saw that sentence, calculating the point where a score would be granted as if ball_pos[0] < PAD_WIDTH + BALL_RADIUS: instead of using the direct numerical values, because while it didn't matter here, it's best practices in the future to make sure that if the size of the playing field gets changed, then everything still works properly.
I also relearned the importance of math. For Memory, it's obviously important to know which card the player clicks on, and in the beginning all I could think of was needing a giant if statement--like, if click[0] > 0 and click[0] < 50:, and so on for every group of 50 for each of the cards, but I knew that there had to be an easier way, so I headed to the class forums. Someone there had the same problem, and a comment mentioned integer division, after which the light bloomed in my head and the rest of the coding was pretty easy. Since the cards are a standard width, just divide the X coordinate of the mouseclick by that width using integer division and the whole number left will tell me what card was clicked on. 382 // 50 = 7, so that's the 8th card, because 31 // 50 = 0, so the first card is the 0th card when checking the list of cards.
Incidentally, I think I've learned why Python list indices start at 0 instead of 1.
The name does basically say it all, but I'll describe it anyway to avoid any confusion--don't do everything at once. Unless you are The One, destined to obtain power over the Matrix and defeat the machines, the programs you write will have errors. Some of them will be obvious because the program won't work at all, and modern languages tend to be reasonably good at telling you where a program breaks if the syntax is wrong. Sometimes the program works but it just provides a bad output, and if the entire program is all crafted at the same time, it's incredibly difficult to figure out exactly where the point of failure is. Much better to do step 1, make sure it works, do step 2, make sure that works with step 1, etc., until the entire thing works together.
Though as a story, sometimes syntax errors just screw things up. I was reading a forum thread where someone was trying to add a Coptic culture to Crusader Kings II and ended up with most of England filled with Noculture kingdoms speaking Noculturian. A later post in the thread suggested an unmatched parenthesis as the most probable cause. Oops.
I still have 100% in the course, though some feedback I got on last week's project was enlightening. I wrote Pong, and there were variables for the width of the paddle, the radius of the ball, the height of the paddle, and so on. When I calculated when score should be counted and when the ball should bounce back, I tended to calculate it in absolute distance by eyeballing it and adjusting the pixel count, and in the end, the program worked, so I submitted it. The feedback suggested I use the variables and that my code was hard to read because I hadn't used them, and until I saw that sentence, calculating the point where a score would be granted as if ball_pos[0] < PAD_WIDTH + BALL_RADIUS: instead of using the direct numerical values, because while it didn't matter here, it's best practices in the future to make sure that if the size of the playing field gets changed, then everything still works properly.
I also relearned the importance of math. For Memory, it's obviously important to know which card the player clicks on, and in the beginning all I could think of was needing a giant if statement--like, if click[0] > 0 and click[0] < 50:, and so on for every group of 50 for each of the cards, but I knew that there had to be an easier way, so I headed to the class forums. Someone there had the same problem, and a comment mentioned integer division, after which the light bloomed in my head and the rest of the coding was pretty easy. Since the cards are a standard width, just divide the X coordinate of the mouseclick by that width using integer division and the whole number left will tell me what card was clicked on. 382 // 50 = 7, so that's the 8th card, because 31 // 50 = 0, so the first card is the 0th card when checking the list of cards.
Incidentally, I think I've learned why Python list indices start at 0 instead of 1.