This past Saturday was ETC Playtest Day, where groups of guests came to try out our project and give us feedback. We had guests from many different demographics—since our target audience is children in middle school and high school, we had a few groups of children with their adult supervisors, as well as some groups of college students and older adults. A few of them had previous BMX biking experience and knew what pump tracks were, but for the most part, we showed some examples of real-life pump tracks and explained how they work before letting the playtesters just try to build a track however they wanted.

We had several stations set up around the room, so multiple people could all be building and riding their tracks at the same time, with one station hooked up to the custom controller for anyone who wanted to try pumping using the actual handlebars.

We recorded observations of all of the sessions and received plenty of feedback, which we synthesized in an affinity diagram on Miro:

For the most part, all of the groups enjoyed building and getting to ride on the tracks that they designed, even without having the same background experience and context as our clients and target audience. It was good to know that people generally find the tasks compelling and want to engage with our application. We noticed a variety of behaviors and player types, as some focused more on making an interesting track (some more extreme and unrealistic than others), while others enjoyed decorating the park area with amenities and creating the community environment. We’re happy that we achieved our goal of supporting those different types of players and emphasizing the various aspects of what goes into designing a pump track and bike park.

Through playtesting, we also found new issues that we weren’t aware of and will need to address before our next milestones. In the building portion, the input system caused many problems because sometimes objects that were placed down could no longer be picked up or interacted with. The terrain was also too sensitive, as it recalculated and was raised up every time a piece was picked up and moved even slightly. This caused pieces to get buried sometimes and for the tracks to have very unrealistic topography, so for the sake of functionality, we had to disable the terrain altogether until we could address those issues. On the riding end, the player character would clip into terrain in some places, causing unwanted movement and rotation. It was also difficult to stay on the tracks, as the controls for movement were pretty sensitive. As a result, the guests would spend more time riding around in the flat terrain and experimenting with what happens when they ride off the edge of the map.

By identifying these issues, as well as hearing from the guests as to what features they would like to see in this experience, we could figure out the priorities for what we needed to implement next in all of our domains, so that we can have the best possible product for Soft Opening in two weeks.

This week, we made some progress on the texture for the pump track pieces, going for a concrete material. Following feedback from halves that the meshes look too much like plastic, we iterated upon the shader to add in roughness.

Additionally, we had to completely redesign how our custom controller would be assembled. For Playtest Day, we had 3D printed a custom shaft and container to hold our load cell sensors, and we attached the top of the shaft to the stem of the BMX handlebars. We needed to 3D print a cap to place at the top of the shaft, since we needed to both be able to fit a spring around the shaft and have it be wide enough to attach to the handlebars. However, this proved to be an extremely weak point, as the controller broke exactly at that connection point without much force even being applied during an early playtest session.

On top of that, our current design still didn’t have a good way to integrate the spatial phidget for rotation, and we struggled to get the spatial phidget to work well for those purposes. For one, a lot of the data for the spatial phidget that is visible in the Phidget Control Panel app is not accessible through the Unity library, meaning we would have to derive it ourselves. But even if we did that, the spatial phidget is best used for acceleration and relative position, rather than absolute, so it would be prone to drifting and inaccurate readings that would not be ideal to ship in a deliverable.

With all of these concerns to address, we sought out help from Dave Purta on the IT team and Vivian Shen, our project consultant. From their advice, we scrapped the spatial phidget altogether and opted instead for a rotary encoder, which is more suited for the task that we want to accomplish. Also, instead of two load cells mounted onto 3D-printed plastic material that we push on with some extruding piece inside of our box, Dave suggested that we only use one load cell that has the flexibility to bend both up and down, as the load cells would provide positive or negative readings depending on the direction.

The new design would have the load cell mounted onto a metal bar and plate, with the rotary encoder on top, connected directly to the shaft of the bike handlebars on top of this.

One uncertainty about this design was finding a shaft coupler to go from the 6mm diameter of the rotary encoder to the 22.2mm diameter of the handlebar shaft, but eventually, we found one from 6mm to 20mm that we could work with. We put in an order for the new materials we would need—the rotary encoder, quadrature encoder, shaft coupler, flange-mounted ball bearing unit to support the shaft, aluminum bar and plate, and clamps. Once these pieces come in, we will be able to start building the improved prototype next week.