The situation: Programming is (or can be) fun! You can do SO MUCH and feel SO SMART when you accomplish your programming goals
The problem(s): Programming is can be HARD, because the type of problem solving required for programming isn't one that we are typically very familiar with. For example,
Planning ahead is one of the best ways to keep your projects manageable and time-efficient.
It's typically very beneficial to think through your program on paper before trying to translate it to code.
What are your goals? What are you going to need to do to accomplish those goals? To compare programming to, for instance, writing: programming tends to
go more smoothly when you start with an outline instead of just writing stream of consciousness on the page
Programming requires future-oriented thinking. You're programming not just actions but trying to anticipate what WILL happen and how your program will
respond to various situations. Speculation is very hard! It often feels like a guessing game. You need to learn to think of all possible scenarios and
decide what will happen when one of those potential scenarioes comes true. This is also a reason that PLANNING is useful; to document all possible outcomes.
Once you figure out your goals and you figure out what possibilities you need your program to account for, you're probably going to have to do research
in order to figure out how to turn these ideas into proper, workable code. THIS IS NORMAL! Rarely does someone have all the syntax and possibilities of a
program memorized. Google is your friend. StackOverflow is your friend. YouTube is your friend. That being said, trial and error are also going to happen a lot!
And when something doesn't work, you'll need to do even more research, or go into the dreaded "debugging" mode (trying to figure out where a mistake is in your
code) in order to fix it. Looking up tips, strategies, and trying things over and over again until something works is NORMAL in programming. This can throw students
off a lot of the time!
You tend to be rewarded in programming not for coming up with some new and grand way of solving a problem, but an efficient, easily understandable, and novel way of
solving a problem. Just like I say with your reflection essays: you are not required to come up with some argument that no one in the world has ever thought of before.
To compare programming again to writing, the best papers often come not from making a groundbreaking discovery, but from taking evidence and information and arranging
it so that it offers an exciting or novel way of thinking about a subject. Programming is the same way! Playing it safe is almost always fine, especially if you play it
safe WELL. But the best assignments, the most exciting ones, come from taking small risks and showing me that you're thinking outside of the box. It is a HARD skill to
teach, but practice always helps.
What does this process, these ways of thinking, actually look like? Instead of continuing to talk in these really abstract, esoteric ways, let's
walk through an example of a game I created in scratch for the purposes of showcasing not
only the various capabilities of scratch, but how to think through game design and programming more generally
So, here's the scenario: I'm here trying to generally learn how to program in Scratch and make a simple game. To do that, I'll need to do some brainstorming! I'll brainstorm in the form of a
numbered list below. Note that this is brainstorming ONLY at this point; I'll flesh out the details, how I'll actually realize these goals in the next section.
- I want the basic game objective to be getting a pumpkin sprite from one end of the stage to another
- I want the basic game mechanic to be moving the pumpkin using arrow keys to avoid obstacles on the way to the end of the stage
- I want another mechanic to be GRAVITY. The goal can be to use the arrow keys to navigate the pumpkin through openings and towards the ground, using gravity as a global variable
- If the pumpkin I'm controlling hits an obstacle, I want it to look like it burst open, and the game to end
- If the pumpkin reaches the end, I want it to display a nice "win" message
- Whether the pumpkin bursts or reaches the end, I want the game to restart from the beginning after a brief amount of time
- I want the game to be at least somewhat aesthetically pleasing, even if simple
The next step in my process would be to take all of these basic ideas and try to figure out how I can actualize them. When I talk about goal-oriented thinking,
this is probably what I am referring to. I am treating each of these different ideas as a goal, and my task is to figure out the exact right combination of blocks in Scratch with which to achieve those
goals. So, I would tackle all of these goals in the order that I was most important:
- If I want a pumpkin to get from one end of the stage to another, I will need BOTH a sprite (the pumpkin, the "player" object that I control) and a backdrop that serves as the stage. These are
visual problems, not programming ones, but that doesn't mean you don't need to think them through! My solution was to create very a simple pixel art pumpkin and a very simple pixel art background.
When I completed these tasks, I uploaded them into Scratch.
- I want the pumpkin to be movable with arrow keys back and forth, so I will need to figure out a way for my program to know that when I touch the arrow keys, the pumpkin should move. This may
seem like a really obvious sentence, but breaking down the components of programming into their most basic units is usually very helpful!
- I chose to accomplish this goal by using a variable called "x velocity". Essentially, I created a variable, then set that variable to "0" right at the beginning of the script. This way the starting value whenever I run the script will ALWAYS be zero.
- I then programmed the "right" and "left" arrow keys using an "if-then" block:
if the right key is pressed, set x velocity to 2, and if left key is pressed, set x velocity to -2. Notice that I used SET and not CHANGE: setting the velocity means no matter how many times I press an
arrow key, the velocity will only ever be 2 or -2. If I used CHANGE, every single time I pressed an arrow key, the velocity would continually increase (2, 4, 6... and so on...). That could be interesting!
But it's not what I wanted.
- There is one more step I had to do; after these if-then statements, I included a block to change "x" by "x velocity". This way, the pumpkin is sitting still until you press an
arrow key (because x velocity is initially set to 0) and then will be continuously moving at either -2 or +2 x depending on what arrow key is pressed.
- Okay, cool! I can move the pumpkin back and forth. But the program currently has no way of understanding that when the pumpkin arrives at a hole in the ground, I would like it to "fall" as if being
pulled by gravity. For me, gravity and x velocity are two separate problems. X velocity represents the player input, but gravity is something I just want to exist in the game world without a player having
to manipulate it. So, to do this...
- I again created a "gravity" variable. The first step here was to change the gravity variable to "-5", similar to how I set x velocity to 0 initially. I wanted to make sure I always had a constant, reliable starting value.
- I then had to figure out how to trigger the gravity variable into running. When would the computer know that the gravity variable should be activated? I chose to do this using the "sensing" options in Scratch; based on how I drew
my stage backdrop, the pumpkin sprite would always be touching either green, brown, blue background, or purple the "win" area. I decided to gravity activate whenever the sprite was NOT touching the green background, and set the if-then
statements accordingly. This way, whenever the pumpkin is not touching green, gravity will activate.
- Finally, once again, I have to tell the computer what to actually do once the gravity variable is triggered.
- Cool, now I have movement pretty much solved! Moving on to the next problem: I need to program in a way to lose the game. I wanted some sort of "obstacles" at first, but it would be just as challenging to simply program a sensing block
for the the pumpkin touches the brown areas of the stage backdrop.
- First, similar to the last sensing block I used with gravity, I'll make an if-then statement that tells the program to check if the sprite is touching the color brown
- Next, I realized that I'd have to create a new "costume" for my pumpkin to look like it burst on the thorny brown patches of the level. So, I made a new pumpkin sprite, uploaded, and designated it a
costume.
- I then declared that if the sprite is touching the brown color of the backdrop, the costume will change and the pumpkin will declare a short "game over" message
- Cool, that last one seemed pretty easy! I'll do the same for the "winning" parameters and game message; sensing blocks, if-then statements, and a short winning message for when my sprite reaches the purple color.
- Here's a tricky one, though; I want there to be a way for the game to restart after I win or lose! This means that if I win, I need the pumpkin to reposition itself and start at x velocity=0 again. If I lose, I need
to change the costume back to the original pumpkin and have it reposition itself. Hmmm.
- I ended up solving this in a way that was NOT particularly efficient and probably not the "best" way in terms of good programming, but sometimes those are the tradeoffs you experience for making something work. Essentially,
I used the "broadcast message" and "when I receive message" feature to signal the "end" of the game (the broadcast message 2 block activates only when I have reached the end of the game) and to restart the game again
- The game "restarts" itself by waiting a couple seconds after the message, broadcasting message two, stopping script one (the big block on the left in my code) and moving to script 2 (the big block to the right.) The "message 2"
that the first script block broadcasts is received by the 2nd block, which immediately resets the pumpkin to the correct coordinates, puts it in the correct costume, and sets the game up to run again.
- I then allow this to loop forever, giving me infinite playthroughs
- And that's it! At that point, I had all the basics of this game programmed. I spent some more time tweaking visuals (adding the nice rainbow, making a pumpkin patch to start in) but these were purely cosmetic shifts.
And here you'll see how this looks in practice. Please feel tree to play it, look inside of it, borrow concepts from it if you life. It's a simple game and not particularly rigorous in design or aesthetics, but that's all we're
asking of you in this assignment: learn to think through programming, code, how to evaluate trade-offs in programming, how to problem solve.
Instructions: use the arrow keys to set the pumpkin moving in either the left or right direction. Fall through the level until you reach the happy rainbow area at the end. Don't
touch the icky brown thorny parts of the stage or the pumpkin will burst!
What about the reflection paper, you might ask? I'm going to keep this section brief because I do think you will have tons to work with for this. What I will say is to continue speculating
and thinking about different scenarios in which some features of "good" programming might be more important than others. Context will matter for this, so speculating about context is okay. I've compared programming
to writing a couple times already on this help page, so don't be afraid to apply some of the same principles to your reflection paper.