crashcourse kids
Engineering Games: Crash Course Kids #29.2
YouTube: | https://youtube.com/watch?v=4TYLXqrdUMw |
Previous: | A Case of "What-Ifs": Crash Course Kids #29.1 |
Next: | Let's Take a Hike: Crash Course Kids #30.1 |
Categories
Statistics
View count: | 256,692 |
Likes: | 1,123 |
Comments: | 0 |
Duration: | 03:18 |
Uploaded: | 2015-10-01 |
Last sync: | 2024-10-31 13:15 |
Citation
Citation formatting is not guaranteed to be accurate. | |
MLA Full: | "Engineering Games: Crash Course Kids #29.2." YouTube, uploaded by Crash Course Kids, 1 October 2015, www.youtube.com/watch?v=4TYLXqrdUMw. |
MLA Inline: | (Crash Course Kids, 2015) |
APA Full: | Crash Course Kids. (2015, October 1). Engineering Games: Crash Course Kids #29.2 [Video]. YouTube. https://youtube.com/watch?v=4TYLXqrdUMw |
APA Inline: | (Crash Course Kids, 2015) |
Chicago Full: |
Crash Course Kids, "Engineering Games: Crash Course Kids #29.2.", October 1, 2015, YouTube, 03:18, https://youtube.com/watch?v=4TYLXqrdUMw. |
///Standards Used in This Video///
3-5-ETS1-3. Plan and carry out fair tests in which variables are controlled and failure points are considered to identify aspects of a model or prototype that can be improved.
Want to find Crash Course elsewhere on the internet?
Crash Course Main Channel: https://www.youtube.com/crashcourse
Facebook - https://www.facebook.com/YouTubeCrashCourse
Twitter - http://www.twitter.com/thecrashcourse
Tumblr - http://thecrashcourse.tumblr.com
Credits...
Producer & Editor: Nicholas Jenkins
Cinematographer & Director: Michael Aranda
Host: Sabrina Cruz
Script Supervisor: Mickie Halpern
Writer: Jen Szymanski
Executive Producers: John & Hank Green
Consultant: Shelby Alinsky
Script Editor: Blake de Pastino
Thought Cafe Team:
Stephanie Bailis
Cody Brown
Suzanna Brusikiewicz
Jonathan Corbiere
Nick Counter
Kelsey Heinrichs
Jack Kenedy
Corey MacDonald
Tyler Sammy
Nikkie Stinchcombe
James Tuer
Adam Winnik
(SciShow Kids intro plays)
(music plays)
Sabrina: Come on bird. Aaaand yes! (bing) Crushed it. I just beat a level that I've been stuck on for like a month. As any good gamer knows, it takes the right move to win. One wrong move, and poof, a possible win can turn into a loss. The same thing is true for engineering.
Last time we were thinking about the moves we could make that would guarantee our solution to our getting across the gorge problem was a success, and that included identifying variables, or the conditions that can be changed. But what's the big deal? Why do engineers identify variables when they're designing and testing solutions to a problem?
(Text: Big question)
Remember we can control some variables, like the height from which we drop a ball to see how high it bounces, but there are variables we can't control, like gravity. Whether a solution to a problem turns out to be successful or not depends on picking the right way to change a variable. The way something turns out, like whether a solution solves the problem or not, is called an outcome. So let's see how changing variable can change the outcome by playing a game.
(text: Investigation)
The goal of this game is to knock down a pile of fluffy pink marshmallows, and to do that we launch cat-bot into the pile using a slingshot. There are two variables here that we can control, we can change the angle of the launch and we can change how far we pull back on the slingshot. If we change either or both of these variables then we can get one of three outcomes: we could knock over all of the fluffy marshmallows, knock over some of the fluffy marshmallows, or miss the pile completely.
Now I don't want to be stuck on this level for another month so I'm going for the complete knockdown outcome. Try number one: and I miss. Completely. Boo. So I'm going to change one variable: the angle of the slingshot, but I want to pull back on the slingshot just as far as last time, otherwise I won't be able to tell if the outcome of the second try is because I changed the angle or if I changed how hard I pulled.
So let's see if changing the angle but pulling just as hard as before give me the result I want. And score! Total knockdown. Now if I wanted to for my second try I could have decided to change how hard I pulled on the slingshot, but if I did that I'd have to keep the angle the same. Bottom line: engineers only change one variable at a time. Otherwise, we can't tell why a solution works or doesn't work.
(text: conclusion)
So engineers don't just identify variables for fun, although it definitely can be. They identify them so they can figure out which ones they can control. That is, either change them or keep them the same. And that's important to know because changing a variable can affect the outcome, or result, of a solution. So engineers change only one variable at a time when they test a solution so they're sure of their connection between the variable and the outcome. Now it's back to my game. I'm coming for you, marshmallows.