Almost a decade after Slipstream’s launch, it’s good to look back through the documentation, re-evaluate what worked, why it worked, when to push it’s limits, and how to use it better.
A lot has changed since then. Going from Unity 3 (at the time of release) to Unity 2018.3 there’s been changes to basically everything. The physics middle has changed to the point that wheel colliders used in slipstream no longer function correctly. The old forward rendering system has been joined by two versions of deferred in Unity 4 and 5, then the two new render pipelines in Unity 2018. The legacy particle system has been replaced by Shuriken, which has gone through numerous changes. Networking, which was a year-long ordeal for our 2 student programmers, is now a unitypackage you download and import ready to use. Most of the game used js, which is gone now. Even the old Unity Skyboxes have been replaced by the Procedural Skybox Shader (but I brought the old one back from the dead!). Basically, the only assets that came across nicely were the meshes and textures. Mostly.
What did stand the test of time, thankfully, is the gameplay. Races are close, competitive, unpredictable and exciting. Strategies and tactics are still as viable and/or risky as they were on launch day, and the pacing (short circuits and low lap counts) keep things interesting and entertaining. Take a few minutes and have a look through this, as an example of my level design work on Slipstream; covering the origins, creation, concepts and limits of the track “Ring of Fire”. Slipstream is a multiplayer game, so if you’d like to give it a race, I highly recommend doing so with a group of friends.
View Ring Of Fire Level Design Document
(pic below is from the public Unity 3 version)
Unfortunately, we haven’t yet gotten around to a complete rebuild of the game using Unity 2018/2019, but from this quick test pictured below (one track, one car, one element) I think it would run brilliantly and look fantastic.
slipstreambrendan 