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:247,178
Likes:1,118
Comments:0
Duration:03:18
Uploaded:2015-10-01
Last sync:2024-03-17 17: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.
So how can a game teach us about engineering? Pretty easily! When you're trying to solve a game, or a puzzle, or whatever, you will have a bunch of variables. The trick is knowing how to change one variable at a time to see what changes. In this episode of Crash Course Kids, Sabrina plays a game with Catbot to show us how!

///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.