Bonus feature! Check out this crazy oscillator device I made with contraption cubes of different masses. It’s pretty mesmerizing. The cubes get heavier from left to right but the strength of each aerial faith plate is the same.

Here’s a quick high school physics lesson.

My oscillator reminds me of the wave pendulum in the video below because both systems show repeating patterns. The swinging billiard balls form a wave with varying frequency. My oscillator also appears to be demonstrating wave-like properties.

The billiard ball pendula are oscillating on strings of varying lengths but are pulled to the same angle. The period (time of one oscillation) of a pendulum pulled back to a small angle is

Period = 2Π√(length/strength of gravity)

So, if you increase the length of the pendulum, you increase the period. Each progressively longer pendulum takes a bit more time to make one period in the same way that each progressively lighter companion cube stays in the air a bit longer. Of course, the game’s oscillations aren’t perfect. I’ll take another look at the differences between the way the cubes are bouncing and how they should bounce to determine the exact variations between the physics of aerial faith plates in the game and similar launchers in real life.

Here are three student made levels from the first week of playing Portal 2 in physics. You’ll see they’re simple with extraneous objects and obvious objectives, which isn’t surprising given that they had only played about two hours of Portal 2 before making these. To be clear, these weren’t for any particular experiment in class. Students made these as first attempts at making puzzles.

It’ll be interesting to compare these novice levels to what they make after they familiarize themselves with Portal 2. I’m excited to see how they progress.

Overall, I’ve seen some interesting reactions from the kids. For the most part, they seem pretty enthused. They’ve been explicit about how they appreciate applying what we learn in lecture to what they can do in the game. I even had a student tell me that she enjoyed using math for the first time when she used data from her own experiments to calculate the strength of gravity. Students have made comments about how engaging physics lessons are with the puzzle maker, and I’ve had numerous kids tell me they’re looking forward to physics class, which makes me feel pretty good!

So far we’ve run through a few labs where they’re building really simple experiments in the puzzle maker.

In this lab, students are measuring the distance and time of a fall to calculate the strength of gravity in-game. The students who fell the farthest measured the most accurate measurements so far. Without an in-game timer, students have to use a regular stopwatch to calculate the time of their falls. Unfortunately, they aren’t the most careful bunch and tend to be off by a sizable fraction of a second each measurement. That kind of error wreaks havoc on measurements when the fall time is only about half a second anyway. They need a long fall time to minimalize issues from their reaction times.

In this lab, students are calculating terminal velocity by measuring time and distance as they fall in an infinite loop. They then repeat their experiment with a cube. When I originally wrote this lab, I hadn’t considered the idea that portals could impact velocity. Since then, I’ve found that portals slow objects down, which almost makes this lab pointless. However, I still taught it as practice for data collection and to identify that cubes are subject to a bit more friction than players (I think). Either way, this lab easily led into a useful discussion about the effects of friction and air resistance.

Hello everyone coming from Singularity Hub! Check out my demonstration videos for a good overview of what I’m trying to do. And for the educators out there, take a look at my lesson plans and let me know what you think!

After my last post about the effect of portals on cube velocity, I was asked about the actual velocity limit for cubes moving through portals. It’s easy to calculate. Looking at my Portal Velocity Limit Spreadsheet, it’s clear that any cubes dropped farther than about 8 panels were slowed to the same velocity as they passed through the portals. To get an idea about the portal velocity limit, we’ll start with the equation:

From the spreadsheet, we’ll be using and , which gives us .

Of course, that doesn’t take air resistance into account, so we really just found an average velocity. To find the instantaneous velocity of a cube as it passes through the portals, we’ll be using the console command, “physics_debug_entity.” Check out the video below.

It looks like our results make sense. We would expect the instantaneous velocity of a cube when it first leaves the portal to be higher than its average velocity after being slowed down by air resistance.

Do mass and velocity play a role in the outcome of collisions? Let’s find out.

We’ll be colliding three objects: a cube, a sphere, and a turret. A cube has a mass of 40 kg, a sphere has a mass of 75 kg, and a turret has a mass of 100 kg (found by using the console command physics_debug_entity while looking at an object). If all goes well, the object with the larger momentum due to its larger mass or greater velocity should send the other object flying backwards as the result of their collision.

Test 1: Two cubes of the same mass hitting at the same velocity.

Their identical momenta cancel out.

Test 2: A sphere striking a lighter cube at the same velocity.

The sphere’s larger momentum causes the cube to fly backwards.

Test 3: A cube striking a turret.

The turret has a larger mass and its momentum causes the cube to fly backwards.

Test 4: A sphere striking a turret.

The turret has a slightly larger mass and its momentum causes the cube to fly backwards.

Test 5: A fast cube strikes a slower cube.

The fast cube’s greater momentum knocks the slower cube backwards.

It looks like mass and velocity are significant factors in collisions and handled correctly (at least superficially) by the Source engine.

In about 5 minutes, one of my students figured out a clever way to make an in-game timer using linked buttons and cube droppers.

Interestingly, the student who made it has poor communication skills. I had trouble following his explanation of what he had in mind, yet he clearly knew what he was talking about. The Puzzle Maker gives students like him the opportunity to show what they know in a totally unique way, that is, for some students, more natural than traditional communication.