3.) A. The names of the two sprites are "cat" and "wall".
B. Only the cat has a script; it has one script.
4.) Pseudocode:
When Green Flag clicked
Set MOVE_INCREMENT to 5
Set direction to 1
forever
change x by direction * MOVE_INCREMENT
if touching wall then
set direction to -1
if x position < -239 then
set direction to 1
5.) A programmer would want to use a variable like MOVE_INCREMENT instead of just putting 5 in the relevant code because that way the result is consistent; even if the variable is not at the set speed of 5, it will still be able to perform the same function. You can change it around easily.
6.) The variable direction controls which way the sprite is moving. The value 1 means the sprite will go forward (to the right), and the value -1 means the sprite will go backward (to the left).
8.) When the direction is set to 0, the sprite does not move.
9.) The variable direction is best described as the "most recent" role because the most recent value is unpredictable as it is affected by the user input. All variables store the value most recently assigned to them.
10.)
11.)
13.) The new variable is the accumulator.
14.) The variable accumulator makes it so that every time you click the cat, the number of your x position is added to the number on the accumulator monitor.
15.) The purpose of the variable accumulator in this code is to add up each x position you click the cat on and to keep score of it for as long as you're playing.
17.) Sums up all the points in the current context. It is a running list.
Conclusion
1.) With a fixed variable, you only have to set it once and it will keep running throughout the program. You can also change the variable value easily and it adjusts everything accordingly.
2.) Move forward for 1s
Read the price from the next jar
Place the box back on the shelf
3A.) Calculators and games that show scores use an accumulator.
3B.) Games that show the score changes as you collect "points"- the game always remembers how many points you earned in one level so that it may be added to the points collected in the next level, and adding it on to the next level, and so on. The score (number of points you gain) accumulate.
4.) The accumulator is a running total, it adds up the points or inputs you give it; the aggregator is a running list, it remembers every input it is given (and displays them as individuals- they are separate from each other).
Hello! Hannah Creations is a website that I'm going to be using to publish any projects I make for school in the next couple weeks. I hope you check some stuff out and that you like what you see! I'm very proud of my work. :)
Monday, September 22, 2014
Thursday, September 11, 2014
The Penguin Game!
http://scratch.mit.edu/projects/26615210/
Hannah wrote all the dialogue and the basic coding for the sprites to have a conversation. She also figured out how to ask a question and wait for an answer (if it's correct, move on; if not, repeat 3 times). The sound effects were also added in by her.
Max controlled all the movement that the sprites did, along with the background changes and the costumes that each sprite had. He also duplicated the basic coding and made sure that it was repeated in every scene. The end screen was also created by him.
One challenge we as a group overcame was getting the sprites to ask a question and wait for a response. We got over it by using the "ask () and wait" block paired with the "answer" variable (which we figured out by googling). Basically this coding gets the script to tell the sprite to ask a question, wait for an answer, detect if it is right or wrong, then do something else (sound, dialogue, etc.) depending on the outcome. Thanks ScratchWiki!
Hannah wrote all the dialogue and the basic coding for the sprites to have a conversation. She also figured out how to ask a question and wait for an answer (if it's correct, move on; if not, repeat 3 times). The sound effects were also added in by her.
Max controlled all the movement that the sprites did, along with the background changes and the costumes that each sprite had. He also duplicated the basic coding and made sure that it was repeated in every scene. The end screen was also created by him.
One challenge we as a group overcame was getting the sprites to ask a question and wait for a response. We got over it by using the "ask () and wait" block paired with the "answer" variable (which we figured out by googling). Basically this coding gets the script to tell the sprite to ask a question, wait for an answer, detect if it is right or wrong, then do something else (sound, dialogue, etc.) depending on the outcome. Thanks ScratchWiki!
Sunday, September 7, 2014
Light-bot Project (Part 2)
When computers become smart enough that we cannot tell humans and computers apart (the Turing test), do you think that computers will experience consciousness the way we do? Should they have rights?
I don't think (or would like to think) that computers will ever experience things the way humans do. No matter how advanced technology may be, you can't program "feelings" into a computer. One might be able to program the five senses into a robot, but that robot still wouldn't be able to have the same reactions as a human would with those five senses. A robot will not cry when it is hurt, or get angry if you ignore it. They might be able to stimulate an intelligent conversation with you, but it could never feel as genuine as a human connection. Robots do have their glitches.
Because of this, computers should not be given any "rights". Lots of living things experience consciousness the way humans do, but they don't have the same "rights" as humans. Computers are not human beings, nor living things (by definition), so they shouldn't be entitled to any rights. They don't need it. Computers are created, controlled and owned by humans for their convenience and that's how it should remain. A computer's rights should not be able to be contested in court.
I don't think (or would like to think) that computers will ever experience things the way humans do. No matter how advanced technology may be, you can't program "feelings" into a computer. One might be able to program the five senses into a robot, but that robot still wouldn't be able to have the same reactions as a human would with those five senses. A robot will not cry when it is hurt, or get angry if you ignore it. They might be able to stimulate an intelligent conversation with you, but it could never feel as genuine as a human connection. Robots do have their glitches.
Because of this, computers should not be given any "rights". Lots of living things experience consciousness the way humans do, but they don't have the same "rights" as humans. Computers are not human beings, nor living things (by definition), so they shouldn't be entitled to any rights. They don't need it. Computers are created, controlled and owned by humans for their convenience and that's how it should remain. A computer's rights should not be able to be contested in court.
Light-bot Project (Part 1)
1. How is Light-bot like a computer?
Light-bot is like a computer in the sense that it processes one command at a time, as a computer processor core does as well.
2. How is Light-bot different than a computer?
Light-bot is different from a computer because the output of the computer is based only on its input and its state (including its memory). However, for a Light-bot, the state is described by the tile that it is standing on and which direction it is facing.
3. Given your experience with Light-bot, do you think there could be starting points for Light-bot that would not connect to other parts of the full state diagram? Explain.
I think that there aren't any points that wouldn't be able to connect to other parts of the full state diagram because it can jump and walk in any direction that you instruct it to (or in a pattern that you choose) so eventually you would be able to reach any part of the diagram. The only reason why you wouldn't be able to is if they made it impossible, such as putting up a 3-story wall without a 2-story or 1-story step for you to go to.
Subscribe to:
Posts (Atom)