Final Scratch Project

Part 1:
The purpose of my game is to achieve 30 points and win. To do this, you have to guide the frog to eat 10 bugs in each level. The first level, set at a frog pond, is the easiest. There are no obstacles and the frog should be able to easily get 10 bugs. But, after you eat 10, the scene changes to a lake and you have to try to get to a score of 20 points while additionally avoiding a hungry duck. If you succeed in obtaining 20 points, the scene will change once more and you will again have to avoid the duck, and a fast-moving hippo. If either the duck or hippo eat the frog first, you lose! But, if you achieve 30 points without being eaten, you win!

Part 2:
http://scratch.mit.edu/projects/23666034/

Part 3:
I started this project by thinking about what kind of game I wanted to create and what kind of characters I wanted to incorporate in the game. Once I figured out the basic purpose of the game, all I had to do was put all the blocks together to create it. To work through problems, I did a lot of "try it and test"...meaning I tried a block I thought would work, then hit the green flag to test it. If it worked with my game, I kept that block! I tested this game at multiple different points during the process, and then finally once more at the end. Once everything worked through the entire game, I knew I had finished. 

Debug #2

Debug It! 1
http://scratch.mit.edu/projects/23546031/
Debug It! 2
http://scratch.mit.edu/projects/23546180/
Debug It! 3
http://scratch.mit.edu/projects/23546418/
Debug It! 4
http://scratch.mit.edu/projects/23546513/
Debug It! 5
http://scratch.mit.edu/projects/23546726/

One debugging strategy we used that proved to be effective was to try out different blocks we thought would work and tested them to see if that provided the solution.

We would help someone else learn to debug a project by guiding them through their own remix and tell them the necessary blocks they would need to complete the project. After giving them that hint, they could put the blocks together to fix the remix.

Interactions (Try It)

http://scratch.mit.edu/projects/23441456/

The puzzles I worked on were 'whenever you press the B key, the sprite gets a little bigger. Whenever you press the S key, the sprite gets a little smaller,' 'whenever the sprite is in the top 25% of the screen, it says "I like it up here,"' and 'whenever two sprites collide, one of them says: "Excuse me."'

My strategy for solving the puzzles was inserting blocks that helped the sprite do exactly what would help solve them. For instance, since the sprites needed to talk in two of the puzzles, I knew I would have to use the 'say ___ for 2 secs' block at one point or another. Then I just built off of them until they were successful.

The B-key/S-key puzzle helped me think about my game project because it reminded me of a tool that you could use while your project was "playing"--the keyboard. It is helpful because even while your project is "playing", you can change it and the sprites around.

Scenes

http://scratch.mit.edu/projects/23392877/

The stage is similar to the sprites because they both have the option to change how they move in their individual scripts. Although the stage can't "glide", etc., it has block options to wait a few seconds and then switch to a new backdrop.

In a scene, you can initialize sprites by having them move "when sprite clicked" or "when green flag clicked" or "when backdrop changes to..."

Beyond animations, you could use scene changes in plays, films, and projects that require presentation. Changing the scene switches up the project, and makes it more exciting.

Conversations

My own: http://scratch.mit.edu/projects/23245504/
Penguin Remix: http://scratch.mit.edu/projects/23247339/

I would describe Broadcast as a more simplified way to create conversations if the conversation is a bit longer than usual. Broadcast is a great way to have Sprites immediately reply to one another using one command block.

I would use timing when it is required to create a shorter conversation, maybe with only one or two replies, or when there is only one character saying something. I would use broadcasting between two characters, or when the conversation is lengthier.

Character Block Activity

Character Block Activity:

http://scratch.mit.edu/projects/22978087/

If I were to explain "Make a Block" to someone else, I would show that it is a way to simplify a collection of blocks to make the entire project simpler and laid out in a neater way.

You might use "Make a Block" when there are parts of your project that are extended and you can use the "Make a Block" block to shorten them. Longer projects will be easier to handle if you use the "Make a Block" option.

Debug-It Remixes

1.1 Remix
 http://scratch.mit.edu/projects/22924037/

1.2 Remix
http://scratch.mit.edu/projects/22924246/

1.3 Remix
http://scratch.mit.edu/projects/22924380/


1.4 Remix
http://scratch.mit.edu/projects/22924471/

1.5 Remix
http://scratch.mit.edu/projects/22924747/

One debugging strategy that I used was to test out a bunch of the blocks until one of them worked to solve my issue. If I could help someone else I would suggest to take your time and go through a bunch of blocks that could be possible to work and try/rearrange them until they do.