Playtest #3

Playtest #3 was at ETC’s Soft Open on Wednesday night with about 65 guests at Microsoft’s Reactor space in SF. I set up the game at the far end of the room and let it run itself. I wasn’t monitoring the game the whole time, but I would estimate that at least 15 or 20 people tried it during the two hours it was active. I tried to collect analytics for the whole evening and had a number of conversations with people who tried it out. Two people also filled out a written questionnaire I had available.

My Goals

  • Collect a lot of data to learn more about swing habits so I can refine the timing.
  • See how easy it is for people to play without instruction from me.
  • Refine set up and breakdown procedure.
  • Find out what they are expecting to have happen vs. what does happen.
  • Fish for other suggestions for improvement.

Lessons Learned

Set up and Breakdown

  • The new controller box looked nice but didn’t behave perfectly. The two four-digit displays didn’t work, so there was no speedometer for players to have fun with. I’m pretty sure the wires connecting them to the Mega board are at fault, jiggling them helped for a moment then they ceased working. I’m going to replace them with very large displays that the players and audience can all see, so debugging the wiring further won’t happen.
  • Had more trouble with LEDs not working. I cut off 20 LEDs from one of the strips and resoldered the connector onto the new end (thanks to Tobias for helping me out with equipment there!). Plus one LED at the end of the line stopped working during the first playtest, so I had black electrical tape over it. The game was known at the playtest as “879 LEDs”.
    I’ve now found a source for LED strips on Amazon that’s almost as cheap as ordering them from China, and delivery is a couple days instead of many weeks. Ordered and on the way. The strips are made for flexibility but not durability, so this may be a continuing issue. Luckily the pieces that are cut off can be reused with the extraction of any single failed LEDs.
  • The set up this time was in a giant U shape (see next section). The strips ran along the floor for about 5 meters, then up onto table tops. The prewired power lines made that portion much easier. The cones worked well, but I still need a solution for the strip holders that doesn’t need assembly each time.
  • I put a strip of red duct tape on the floor and wrote “STAND WITH YOUR TOES HERE” on it near each sensor box. The tape was where it seemed the optimum place for new players to stand – close to the plate and about 18″ back towards where a baseball umpire would stand. This position helps people swing through the light beam properly.

Horseshoe Track vs. Straight Line

The Reactor space was a pleasure to be in, but like most indoor spaces, it doesn’t have a 100′ straight line to set up in. This time I set up in a giant U shape, the two players stood about 10′ away from each other. Both players could see the entire loop except for a small portion blocked by a structural column.

Playtest #3 horseshoe configuration
  • Players could communicate while playing, and this was a positive benefit to the experience. I think it’s exciting to see a ball moving in a straight line at 100mph, but I found it’s just as fun to see it arcing around.
  • Easy for the audience. There were usually a few people watching others play. The side-by-side set up made it easy for the audience to know where to stand (behind the players), and allowed them to communicate with each other and the players for a more social experience.

The downside of this layout is that one player (orange in the drawing) had their back to most of the action. Next time I want to try a looping cross version where each player is rotated 45 degrees towards each other. Each player will have a better view of each other and of the whole field.

Loop Cross version to try next time.

Timing and Ball Expectations

This information was gathered from conversations with people who played, and notes were written down much later that evening. I’m sure I forgot some of the information, but that’s what happens when you’re also co-hosting the event.

  • Overall good feedback on hit timing. New and experienced players all felt the timing of the swing felt right. They were also very aware of the difference between a gentle and a hard swing.
  • Players expect the ball to slow down with a bunt or gentle hit. Right now the bat can only add energy to the ball, a perfect bunt acts like a solid wall returning the ball with the same energy it arrived with. A real bat or racket absorbs energy, and a skillful batter can even cause it to go almost dead. The ball does have drag, but that effect is much smaller and not the same as what players are expecting. I’m going to re-calibrate my algorithm to absorb energy with slow swings. This will need some experimentation to figure out, I suspect that the right solution won’t be linear with swing speed.
  • Along the same line, speed accumulating from swings is climbing too fast. Most rallies are over within about five swings due to the ball going too fast for most people’s reactions, and players I talked to wanted to play longer than that. At 100+ mph players need to just swing on faith rather than try to time it right, but few do. Fixing this is part of the same algorithm that I’ll be tuning for the slower bat speeds mentioned above.
  • One other problem players were having can be addressed at the same time as the other timing fixes. About 20% of the serves are accidental. As players move their bats into position to serve they are crossing the light beam and launching the ball with the equivalent of a gentle tap. The ball moves at a few miles per hour before finally dying, much to the great boredom of the players and audience. A simple minimum swing speed on a serve should fix this. I’m going to first try calculating how strong a swing is needed to get the ball to the other end and use that as a minimum necessary swing speed.

Analytics

My laptop was connected to the controller box and was getting data for each serve and swing of the bats. Unfortunately the system crashed once and I lost most of the data. I did get 18 minutes of playtime recorded with 435 serves and about 600 swings of a bat/racket. I was recording via the Arduino serial monitor in the IDE and the crash wiped out the history. Naïve on my part. From now on I will use a terminal emulator and record straight to disk.

The game was running at about 14 mSec per loop, or about 72 frames per second.

Here are the results from 377 swings that were not serves or bunts. The distribution of swing times is interesting. The histogram below uses buckets 15 mSec wide, or about one average frame time representing the minimum accuracy of the data. 72% were within one frame time of perfect timing. 7% swung early and 21% swung late. The early swingers are close to right on, while the late swingers spread out more. The general shape of the curve doesn’t surprise me at all – when I watch people play many more feel late than early. I don’t trust the high spike in the middle, though. I combed the data and made sure bunts aren’t included (which are recorded as perfect timing). I’m looking forward to collecting a lot more data – this may have been collected primarily from people who are experienced with the game and have dialed in their timing.

Other Issues and Lessons

  • Light beam alignment was an issue. The lights were held in place with mic boom stands over the sensor boxes. The stands would move a little over the course of the evening, and the sensor boxes would get knocked about a bit either by feet, the bat, or even the cable from the bat.
    • I was trying two different light sources, one was a small red laser, and the other was a incandescent Mini Maglite. The red laser has a spot that is very bright, but even with its lens defocused the spot was too small to stay aligned. The Mini Maglite has a broader beam but too dim (14 lumens according to their website). New LED focusable mini flashlights will be my next attempt for a bright but wide spot light.
    • The sensor box needs to be tied down somehow. I tried duct taping it to the floor on one side. Two sides may work. A better solution would be a larger plate that the sensor box is attached to.
    • The mic stand would move a bit. One person suggested sand bags (too bulky and non-portable). I’m going to explore solutions where the mic stands are attached to a platform with the sensor box. This solution may not be portable either. Hmm…
    • My office at home has recessed spot lighting. This worked wonderfully well even with a moving sensor box. Some locations may have built in solutions.
  • Another issue with the light beam is that the hand controller cable would occasionally break the beam. I think this mostly happened on serves, and my slow serve fix (see above) may address this issue. I’ll also make sure the cables are long enough to stay out of the way.
  • Players don’t always understand that they need to break the beam with their swing. Unclear if the duct tape “STAND HERE” marker helped or not. I’ll have to keep iterating on how to make this more obvious.
  • No one reads directions. I knew this already, but put up a one pager with a description of the game and directions to play anyway. As far as I could tell, 2 people read it. This just reinforces the need to make the game really obvious. Other than having to swing through the light beam, people understood what to do.
  • If there’s a knob, someone will turn it. The one system crash occurred when a curious player tuned the Game Select knob. This should have just moved between the two player mode, two different single player modes and an attract mode. Instead it crashed. I have no idea what happened. I don’t fault the player at all, knobs are there to be turned. Don’t know yet how to deal with this one.

Requests from Players

  • Sound effects please! (Working on it.)
  • Some way to manipulate the ball after you hit it. Examples included putting spin or English on the ball or being able to change up the speed. I’m filing this one for now, we’ll see what affect the new swing speed algorithm has first.
  • Players want feedback.
    • The speedometer readout was not functioning (though of course worked fine as soon as I plugged it in back at home). Players specifically asked how fast the ball was going.
    • Scoring. Came up a few times.
    • I’m building new large four-digit displays that will support speed and scoring, AND they will be visible to both players and observers.
  • Kill slow balls faster. Boring to watch it die! Need to fix this one, it’s come up before.
  • The track was bumpy over the LED strip holders and tables. One player suggested the ball speed should be affected by hills. I like that idea, especially when used with:
  • Mini Golf! A putting game to get the ball only a certain distance.

One More Thing

My son Kevin and I had a record setting rally, only I don’t have video or analytics to prove it. The ball was going as fast as I’ve ever seen it go without cheating, and the rally lasted until I gave up because I thought it must be broken. I lost the rally. At a high enough speed we were both just shaking our bats under the beam and it was always counting as a bunt or a hit. I think it’s a feature, not a bug. I only lost because I gave up… seems like a fair game to me.