VR CONTROL AND GAMEPLAY
An interesting aspect of the VR version of Buggy Allstars was the target audience. Since our game is intended to be showcased at Carnegie Mellon’s Spring Carnival, our target audience was essentially everybody. When discussing the project, Mr. Corbett emphasized a unique challenge that would come with developing such a game: we had to ensure that everybody would be able to complete their experience regardless of their skill level.
What this essentially meant for us is that we had to derive a system that would eventually have the player complete the race (albeit in last place) without touching any controls. In a way, Buggy Allstars would have to act both as a pure VR experience AND a game with meaningful mechanics and features worth playing. Here’s a graphic pulled from our dev blog (which you can read → here ←, thank you Trento!) that specifies some mechanical “rules” pulled from research and the requests of our clients at the Alumni Association:
With this in mind, our first order of business was to set up our roads and environment. Thankfully, we are just focusing on a single replayable map for our experience, so setting up a road system and our main map mesh would give us everything we need to work with to start playtesting as soon as possible. One of our team members, Adrian Biagioli, already had a super helpful road-mesh generator ready to go as Mr. Corbet and the programming lead worked to get a mesh of the Schenley area. At this point, I was finishing up some of the initial UI and HUD demos and started to get the ball rolling on how this system would work.
Since we already had a specified path to follow from the road mesh generator, we wanted to see how it would feel for the buggy to follow this ‘ideal path’ while still allowing the player to turn with their controls. While this was against our intuition, it was a decent place to start since this was the mechanism that was controlling the opponent's buggies that we could potentially try to tweak much further. As apparent in the video, it didn't work at all. Upon further debugging, we found that we were turning somewhat but was completely overpowered by the continuous motion on the rails and our perspective within VR with where the buggy is moving.
Our second approach was simply the much more natural feeling free-drive. This was an immediate improvement, making the experience playable and actually fun. From this point, we needed to fix the wobbling issue with the buggy to prevent our experience from becoming a sickening one. Additionally, to replace the player’s need for rails, I got started making some sort of course correction system. The rail system for the player already provided a pretty decent ‘ideal path’, I wanted to use it in conjunction with free driving as more of an aid when we detect the player would need it.
We can think about using a variety of parameters to determine if a player is on course or not and how to fix it. The two I chose were distance and direction, defined as the distance away from the rail and the angle made by intersection the direction the buggy is facing with the tangent of the ideal path respectively. The basic idea is that if we have simultaneously deviated our direction too much from the ideal path when we are too far from the ideal path, then we should probably course correct. This would also give us good values to work with when determining how much to course correct by.
Since the factors and powers for our angles and distances are public, we are able to display them while playtesting. This also alows us to dynamically change these values in the inspector in real time to help us find the most natural settings. I’d be interested to try other formulas or approaches to this, but this is a quick way to get dynamic profiles for our control schemes.
The video is from the very first implementation of the course correction (just a linear profile and directly changes the buggy’s direction in code) which shows our buggy staying on course through the turns pretty well. We later fixed the bug causing the buggy to bounce around and added our dynamic control scheme inputs. When we pick this up in the spring, we hope to give the player haptic feedback through the controls to encourage them to stay on course.