Introduction

Cone Dodgers is a revisit of an autocross simulator that started out as AX-GO which was primarily scripted using Hutong Games’ Playmaker visual scripting tool.  That initial prototype was done to see how far I could push Playmaker.  As it turned out, I could push it pretty far, but mathematics is definitely not one of Playmaker’s strong suits.  Cone Dodgers seeks to re-envision the autocross simulator idea, but using proper C# scripting exclusively, better vehicle physics than the vehicle controller in the Unity Standard Assets package, and in a framework that can be expanded into a full game in the future.

For the vehicle physics, I considered writing my own vehicle controller, but decided instead to use the well-established Edy’s Vehicle Physics.  This provides a more realistic behavior than the standard vehicle controller, but it is still very arcade-like.  Future work will include a mix of my own physics scripting as well as an evolved tool from Edy.

AX-GO was also specifically targeted to the Kansas City Region SCCA and to a specific course.  The Cone Dodgers prototype is designed to be the basis of a more general game featuring uniquely created settings that not only enable broader appeal in the marketplace, but also avoids licensing issues with specific venues.  This current prototype offers a singular car and four different courses.  A medal system rewards the player for their performance and serves as a progression limiter.  Players must be able to score a threshold time on a course in order to unlock the next more challenging course.

What Went Right

Edy’s Vehicle Physics

Physics is hard.  Vehicle physics is REALLY hard.  While I do want to take a stab at writing my own vehicle controller, for this prototype, I saw no sense in reinventing the wheel.  I’ve read many positive reviews of Edy’s Vehicle Physics for Unity and decided to use these tools.  The code and external documentation could certainly be improved, but the set of scripts were still reasonably straightforward in their application.  

The feature that saved me a lot of time as compared to configuring vehicles in AX-GO was the automatic fitting of the wheel colliders to the wheel meshes.  One caveat is that this only works with wheel meshes that are aligned such that z-axis is directed forward and the x-axis is directed to the driver’s side.  The model I chose for this prototype met these conditions, but other models for other cars I have tried since have not and require more set-up work.

Timing and Scoring

A core game mechanic that absolutely must be done correctly is the timing and scoring.  It is common for these to be viewed as the same process, but they are different.  Timing is simply the measurement of the elapsed time for a competition run through the course.  Scoring is the recording of that time along with any assessed penalties for striking cones or not correctly following the course, and the assessment of the quickest scored time among a given set of runs.  The timing aspect of this prototype was simple enough.  Begin incrementing the time when the player’s car passes through a trigger collider between the starting gate cones and stops when the player’s car passes through a trigger collider between the finish gate cones.

Recording cones required more consideration and careful logic.  Simply keeping track of struck cones is easy, but it is also insufficient.  A driver may brush a cone, but if it remains upright and at least partially within its initial footprint, then no penalty is assessed.  If an upright cone is knocked over, even if it is still within its initial footprint, or it is moved outside of its initial footprint, then a penalty should be assessed.  No penalty is assessed for striking a pointer cone.  Additionally, cone penalties are assessed both before the starting gate and after the finish gate, independent of whether the timer is active.  At the end of each run, two seconds are added to the elapsed time for each cone struck and recorded as the scored time for that run.  At the end of three runs, the best scored time is reported.

The last element of timing and scoring is verifying that the driver correctly followed the course and did not maneuver the incorrect way around elements or attempt to short-cut the course.  Trigger colliders were placed throughout the courses that would only be struck if the player did not follow the course correctly.  When one of these colliders is struck, the timing stops, the lights turn red, and “DNF” is displayed as the elapsed and scored times.  Internally, a DNF time is stored at 999.999 seconds so that it is still simple to return the lowest scored time among the set of recorded scores.

Medal Progression System

Certainly, I’m not inventing anything new or groundbreaking here.  I’m stealing a mechanic from other games that works well.  Achieve a minimal level of competence on a particular task, earn a badge, and be permitted to move to the next challenge has been a common mechanic for driving games and puzzle games.  It’s a common mechanic for a reason, though; it works!  The trick is to set the threshold for each tier of reward appropriately.  Set the threshold too low, and there is no challenge to the game, but set it too high and you frustrate your players. 

After much playtesting and tweaking, I think the medal thresholds for bronze (easiest), silver, and gold (hardest), work well.  The gold tier is very challenging to achieve and can only be achieved through a clean run, no cone penalties, but I verified that it is attainable for all courses.

What Went Wrong

Didn’t Allow for Auto-unpause

QA testing is important, and checklist testing in addition to ad-hoc testing is a key part of that.  I failed to execute proper checklist testing relying instead on playtesting and trying to break things on an impulsive basis.  One issue that resulted from this insufficient testing was a bug with the pause feature in the game.  Pressing the pause button while driving does pause the game and brings up the appropriate UI panel.  Pressing the pause button again while unpauses the game and hides the Settings UI panel.  However, if you return to the main menu while the game is paused and then return to any of the courses.  The game is still in a pause state, although the Settings UI will not display.  This leads the player to believe that something is amiss with their controller since everything appears normal, but the car does not respond to any player input until the player presses the pause button twice.  The error is that when transitioning from the course scene to the main menu scene, Time.timeScale is never changed.  If it has a value of zero in the course scene, as it would when paused, then it will still be zero in the main menu scene and when the player returns to the course scene.  Fixing this would be as simple as resetting Time.timeScale to be 1.0 in the Start function

Keybindings are too Device Dependent

The Horizontal and Vertical axes are standard for most controllers, but many of the special controls for a driving game don’t rely on just these axes. Each game controller and steering wheel controller have differences in their button assignments which can cause some odd button combinations for players.  It’s also impossible to hard-code the button assignments for every single type of controller and wheel on the market.  In order for the player then to enjoy a controller interface that makes sense to them, there must be an ability for the player to alter the key binding scheme.  This is also required for accessibility reasons.  If a player does not have use of their legs, but still wishes the fine control offered by a wheel controller, the brake and throttle controls must be reassignable to buttons on the wheel rather than the default pedals. This feature is not in the current prototype but will be one of the first features developed as the game enters the alpha phase of development.

Need better Tutorial Sequence

Cone Dodgers has a tutorial page and an easy course to help a player understand the timing and scoring mechanics.  This is insufficient, however.  The page is helpful for the player that will actually read it, but most players are going to jump straight into trying to race without the benefit of the Autocross 101 tutorial.  If the player has autocrossed before, then this is not a problem.  Most players will not have, however, and it can be frustrating to keep seeing “DNF” recorded as your score and not understanding why or how to avoid it.

Lessons Learned

Develop an Actual Training Sequence

As mentioned above, this prototype as it evolves into a proper game must include not just a tutorial page, but a genuine sequence of training missions.  Work has already begun on this process.  What is needed is a first lesson in the meaning and function of the staging, starting, and finish lines combined with how to read a simple upright cone with a pointer and how that indicates the proper direction.  From there, include a gate element showing the player how to negotiate between two uprights.  Lastly, there needs to be training on how to negotiate a slalom section.  These training sequences will teach the mechanics of reading the course, but not necessarily the driving techniques required to negotiate them in the quickest possible fashion.  That may need to be a second level of training missions.

Course Design Matters

Whether in the real world or in the simulated world of a video game, good design is good design.  While I’m still not completely satisfied with the Regional course, it’s much better than what it was initially.  On paper, all of the courses looked amazing.  Once constructed in Unity and testing was done to make sure there were no issues with the DNF zone triggers or with the cone behavior, it became apparent that the flow of the course was impeded by some design decisions.  Flow is one of the most important aspects of a course to maintain.  A good course designer learns how to ensure good flow from one element to another.  There are a couple of spots in the Regional course where I feel the flow is impeded and could be improved.  The other three courses flow very well and offer the right level of challenge for each of their respective levels.

Slow-in Fast-out Works in Games too

Another aspect of racing that works in this prototype as it does in real life is the notion “slow in, fast out” meaning that the most efficient way through a corner is to approach slow and accelerate through the apex of the corner maximizing your exit speed.  Another technique from autocross that applies in game is “late apexing” or “backsiding” a cone.  This is a technique of advancing your apex point deeper into the corner and is crucial for fast negotiation of slalom sections.  In order to achieve a gold medal time on any of the four courses, one must utilize these techniques.