Playtest #2

Time to test the changes from last time. Playtest on Friday 4/14 during the afternoon in a hallway at work.

My Goals

• Try out next rev on setting up and breaking down the system.
• Compare bat vs. tennis racket. Does one feel better than the other? Does the racket change the way people play?
• Test the software fix that allows players to swing late.
• Collect analytics and explore them for insights.
• Fishing for other feedback.

I would’ve liked to test sound effects, but haven’t made any meaningful progress on them. I didn’t set up audio this time.

Lessons Learned

Setup/Breakdown

The whole system fits into one overflowing box now, plus the mic stands for the lights.

This time all the power lines were pre-made, I brought a full set of tools, and I had new LED strip holders.

Set up still took a long time. Without hitches it probably would have taken about 45 minutes. Most of that time is walking up and down the hall laying cable and hooking up LED strips. It took much longer this time due to problems with the LED strips.

The strips are fragile and some had trouble communicating downstream. Swapping the strips around somehow made the whole system work. This remains a big mystery. I spent about an hour getting the strips to work properly.

The mic stands worked beautifully. One had a 5v laser plugged into a power supply, the other had a small hand focus-able flashlight that I changed the AA batteries in once. The laser is easier for players to understand – there’s something about a laser that says “Break the beam!”

Time to make a new box for the display and main Arduino system. This one is ugly, has its guts exposed, and was subjected to multiple whacks from the tennis racket.

There needs to be a long connector between the Arduino controller and the LED strips. Right now it’s only about 6″ long and means the main controller box needs to be right next to the sensor box.

Bat vs. Racket

Bottom line: the bat works better.

• Swing style didn’t appear to be affected by which controller the players used.
• The bat is lighter, and players didn’t get fatigued as fast.
• The width of the racket caused more things to get hit.
• The thin racket didn’t seem as reliable for breaking the beam, though the electronics should be fast enough to catch it.

Another lesson: players are creative!

• One player tried swinging with her hand instead of the racket after a rally had started. The timing mattered, but there wasn’t any velocity from the racket, so it was equivalent to a well timed bunt. This was fun enough that both players started doing it. The only downside is that the ball continues to slow down due to drag so the rally isn’t sustainable and you can’t serve this way. A handball version of the game might be fun.
• Another player figured out how to cheat the system. By putting her foot over the light sensor she was simulating a bunt, but then swung the bat around while the ball was coming down. This guaranteed that she would hit the ball and add momentum to it. This technique is sustainable and would force a win or crash the system. (I haven’t tested, or even contemplated, what happens if the ball is moving at supersonic speeds, but I imagine the shockwave would reset the Arduino.)

Software Updates to Fix Late Swing

• Allowing late swings had a bug that could crash the system. In one set of analytics, it crashed 44 out of 72 times the player swung late. The good news is that a crash reset the Mega Arduino, and it booted up instantly with a new game – there was a quick green flash on the LEDs and no “home run” celebratory explosion for the winning player, but it didn’t stop game play. The bug has been found – a returned hit could create a situation where it was trying to light LEDs outside of the array’s range. I thought I had designed that out originally, but whoops.
• Players who have played before reported that the game felt much more responsive now due to the late swing change.

Analytics

• I gathered information about each hit of the ball. A game would look like the table below.
  • swingTime is microseconds since the Arduino started.
  • ballPosition is where the ball was when the player swung the bat. If it’s <0 or >899 the batter swung late.
  • hitTime is when the player swung, and deltaTime was how long before the ball was counted as hit. ~3800 means it was hit instantly (player was late) otherwise it’s how far ahead of the ball the player swung.
  • ballSpeed is in miles per hour.

newGame	13
serve	HC0	time	160704392	ballSpeed	23.6
swingTime	162150452	ballPosition	889.67	hitTime	162182516	deltaTime	32600	ballSpeed	39.42
swingTime	163154976	ballPosition	43.34	hitTime	163215136	deltaTime	60704	ballSpeed	-58.97
swingTime	164493464	ballPosition	918.95	hitTime	164496792	deltaTime	3860	ballSpeed	46.32
swingTime	165298708	ballPosition	58.72	hitTime	165373212	deltaTime	75040	ballSpeed	-72.54
swingTime	166411000	ballPosition	935.88	hitTime	166414424	deltaTime	3952	ballSpeed	59.99
swingTime	167059752	ballPosition	94.37	hitTime	167148636	deltaTime	89416	ballSpeed	-89.23
swingTime	167973048	ballPosition	935.54	hitTime	167976456	deltaTime	3944	ballSpeed	76.65
swingTime	168593564	ballPosition	-12.94	hitTime	168596916	deltaTime	3884	ballSpeed	-105.26
swingTime	169192984	ballPosition	815.04	hitTime	169268768	deltaTime	76324	ballSpeed	94.56
swingTime	169815640	ballPosition	-19.87	hitTime	169818996	deltaTime	3896	ballSpeed	-116.27
swingTime	170372572	ballPosition	839.66	hitTime	170419568	deltaTime	47528	ballSpeed	105.94
homeRun	172447484

• My plan was to analyze how early or late the players are swinging, which I can do with this info. But there was a bug that showed up as a system reset sometimes when Player 0 swung late. I was able to use the data to track down the bug. (When it tried to draw a ball that was crossing the zero point in the first frame after the player hit it it underflowed an array.) Because of that crash my early vs. late data isn’t accurate.

Other Lessons

• I didn’t set up sound this time, and players suggested sound would add a lot to the game. Yep.