Repository navigation
Day 7 game #14
Description
We need new materials to cover next week. I was originally planning on doing a growing Snake game (https://github.com/BreakoutMentors/GrowingSnake), but realize this will be too hard. After doing well on animations (day 5), many struggled with the paddle game (day 6). So we definitely don't want to do a huge jump into more difficult arrays and functions.
I'm proposing making a non-growing version of snake: http://scratch.mit.edu/projects/2627038/. They would start with a "blank" pygame project (https://github.com/CoderDojoSV/beginner-python/blob/master/Day-7/blank%20pygame%20project.py) and be responsible for creating everything. So it would not be a more difficult project than pong, but they would start with less. Add on features for the advanced kids can be space to replay, high score, etc.
What do you guys think? Does this sound like the right approach?
Activity
wsande commentedon Mar 12, 2014
Brian,I'm at a conference this week, but I will have a look at your proposed Day 7 (actually Day 6, since we covered two in one week). However, it's really up to you since I won't be able to make it again next week ( business travel).- Warren From: bskinny129Sent: Wednesday, March 12, 2014 11:50 AMTo: CoderDojoSV/beginner-pythonReply To: CoderDojoSV/beginner-pythonSubject: [beginner-python] Day 7 game (#14)We need new materials to cover next week. I was originally planning on doing a growing Snake game (https://github.com/BreakoutMentors/GrowingSnake), but realize this will be too hard. After doing well on animations (day 5), many struggled with the paddle game (day 6). So we definitely don't want to do a huge jump into more difficult arrays and functions.
I'm proposing making a non-growing version of snake: http://scratch.mit.edu/projects/2627038/. They would start with a "blank" pygame project (https://github.com/CoderDojoSV/beginner-python/blob/master/Day-7/blank%20pygame%20project.py) and be responsible for creating everything. So it would not be a more difficult project than pong, but they would start with less. Add on features for the advanced kids can be space to replay, high score, etc.
What do you guys think? Does this sound like the right approach?
—Reply to this email directly or view it on GitHub.
PaulBC commentedon Mar 12, 2014
I wonder how much of the difficulty with day 6 is actually the math rather
than the programming.
Not that the math is very hard, but you need to be comfortable with
negative numbers, which might be an issue for the younger kids, and you
need to understand velocity as a vector with x and y components. The latter
may not even be covered in middle school, though many kids will find it
intuitive.
i found myself explaining a few times that to bounce a ball off a wall, you
need to keep the component parallel to the wall unchanged and negate the
component perpendicular to the wall. Several kids didn't think of writing
"ball_speed_x = -ball_speed_x" and instead hardcoded the speed as -5.
Maybe a little advance theory without reference to Python would make it
easier to pick up without spoiling the challenge in the process.
On Wed, Mar 12, 2014 at 11:50 AM, bskinny129 notifications@github.comwrote:
bskinny129 commentedon Mar 12, 2014
Paul, I think that makes sense. Explaining things better either up front or on the GitHub page would help. But, day 5 (animation) had the same math and I was impressed by what they were able to accomplish. I expected them to be able to quickly (say 30 minutes) apply it to day 6 (paddle game) and move on to the next challenge.
davidbeaverpv commentedon Mar 12, 2014
I mentored Day 5 (not last night) and share Paul's feeling.... many of the kids were able to copy the code that was up on the monitor and make their ball move around the screen, but I didn't get a warm fuzzy that they all really understood what was happening. Some of them didn't understand the X-Y coordinate system even though it was the topic of Day 4. I got many questions about why the ball was going off the screen to the right when they set it to "bounce" at 500px, because they didn't know that only one pixel of the ball is its X-Y location and the bulk of the image is to the right of that.
On the other hand, these were the kids who were putting up their red cup for help; maybe the others who didn't need help, "got it".
I think we're just seeing the fundamental (unsolvable?) issue that we just have a wide range of skills in these classes.
I wish that when the kids asked me questions, I could teach them what's going on, rather than simply showing them that if they change their bounce value to 540px it does what they want. But time, and the kids' patience, don't often allow that.
PaulBC commentedon Mar 13, 2014
One another topic, I thought the "unplugged" exercise was a good idea. Will
this be a regular feature?
It fits a thought that I had about teaching kids to program but wasn't able
to nail down before.
First off, it's easy to get kids to be computer users, and you don't have
to teach them anything that can't figure out themselves by playing around
with the latest technology. But setting them on the path to be software
developers or computer scientists (assuming that's what you want) actually
requires removing the distraction of what you know your computer can do
already, and asking what if it couldn't: couldn't connect to the Internet,
couldn't display 3d graphics with realistic rendering models, couldn't
detect collisions between display objects. How would you get it to?
What I liked about the unplugged exercise was that it encouraged the kids
to go from a picture to a symbolic representation. By eliminating the
computer, it also removed any kind of magic from the process.
I think a key element of breaking out of "user" mode is the insight that
all the things you see in the computer including sound and multimedia are
encoded symbolically behind the scenes. This insight was quite easy to
obtain 30 or more years ago when you had to deal with the symbolic encoding
first, before you were rewarded with sound, lights, and pretty colors. The
downside of this was that it discouraged people from thinking at the
appropriate level of abstraction (e.g., if you're developing a 3d game, you
need to think spatially and ignore the byte encoding). Today, it's still
not possible to develop really innovative software without going back to
the symbolic level at some point. Maybe some day it will be and developers
tapping on keyboards will be a thing, but until then, it is really useful
to bridge this conceptual gap. Even if programming as such were to become
obsolete, I think the idea of symbolic representation (and particularly as
strings of bits) is so significant that it's worth understanding whether or
not you really need to think at this level in your job.
--Paul
On Wed, Mar 12, 2014 at 1:49 PM, davidbeaverpv notifications@github.comwrote:
marcyDel commentedon Mar 13, 2014
he unplugged exercise was brought to our attention by Viji. We'd love for a group of parents to come up with more ice breakers and CS unplugged activities. The Computer science unplugged website, http://csunplugged.org/, has a bunch of them. We just need people to lead them.
Marcy