Racing Drift

I have released the successor to this game in an early-access mode (it's way better) : https://gamejolt.com/games/Powerslide/805966

# Racing-Drift Postmortem

Development on a successor to this game has started. And in Unity, because I simply don't have the time to work on a new game engine or anything like that at the moment. There are currently a lot of problems with the current game that I plan on fixing in the next iteration (referred to as V2 from here):

• Cars are too fast. I basically spent way to much time testing the game, and I had gotten used to how the car handled so I made it faster each time. I now have some experience in level design by creating levels in another game, so the unbalanced difficulty progression should be fixed in V2. (and yes, the way the car plays is actually a level design element. I didn't know that before)

  • Rereading this postmortem two years after I wrote it (4 years later in total I think), this is absolutely true. I have tried playing it again, and this game is kinda unplayable, for exactly this reason. The straights are too fast, and the drifts are too slow. I am surprised I was able to get any good laps on any of these tracks with any of these cars at all. Maybe I should have been in the Air Force piloting F-22s...

• Drifts don't have enough angle, and the cars aren't sliding out enough. This has been fixed in V2 by completely changing the car model. Currently, there are no 'wheels' per-se. The car is simply modelled by a single box collider with a ice-cube-like physic material that has 0 bounce and 0 friction. This has the issue that if there is a slight bump in the track mesh, the level becomes completely unplayable. Although there are 4 raycasts at each wheel, they only exist to check if the car is connected to the track or not. In V2, the wheel model will actually be using wheelcolider-like physics, where the raycasts will be used to simulate suspension and friction (this will be a custom script of course, since Unity's wheelcolider implementation is not something I want this game to be depending on) .The drifting force also comes completely from a forward force, so the car ends up being 90+degrees most of the time, which is very cool looking. The new raycasting suspension system also fixes another problem that I had, where whenever there were two meshes that were perfectly lined up, the car would be bumped at where they met, due to the nature of the physics engine. Now that the car is basically 'hovering' above the ground, this simply isn't a problem anymore and it makes it much easier to implement a level editor, as I don't have to make the entire track 1 seamless mesh anymore

• UI doesn't give sound feedback, and is quite clunky. Not yet fixed in V2

  • 4 years later: I still haven't added sound to the UI lol. In fact, the UI in this game at least looks better, despite actually being better

• Track editor is extremely underwhelming. V2 will place heavy emphasis on the level editor, and I will ensure that every single track in the game can be made inside of it. I have also seen the track editor in Distance, and I want to make something that isn't as overwhelming as that. At the cost of functionality of course, but worth it imo.

  • 4 years later: This goal has been accomplished, I think

• Most tracks are boring and are not that interesting. One of the tracks is a semi-clone of the nurburgring. This is completely random. In fact, most level design choices were completely random and ignored progression, introduction of concepts, theme, variation, etc and mainly revolved around random gimmics that have nothing to do with anything.

• Codebase itself is horrific. The main reason is because the dependency chain between lot of scripts was backwards. This is because I was using philosophy and some vague notion of "what was real" to design objects rather than software development principles.

  • For example, for the UI readout of the car's speed and other info, rather than giving the readout script a reference to the car controller script and reading values off of it in the Update() function to decouple these two, the Car controller itself had a reference to the UI readout and was setting values on the readout in it's update function, creating a god object in the process. Philosophically, a car "has" a speedo on it's console that it is updating using it's battery. But emulating this design with code results in a terrible codebase.

  • A similar blunder was made for the race management system that stopped and ended races. Rather than using events to invoke a RaceStart and RaceFinish event, it became another god-object that had references to all of the things that needed to be triggered when a race started and finished.

  • 4 years later: TBH, a lot of these things aren't always mistakes. Most of the time it is really nice to see all of the race initialization logic in one single place rather than scattered around the codebase on various objects that have subscribed to an OnStart event, which is usually not ideal. Even the speedo one isn't really a mistake. For example, a car has four wheels. So for the sake of clean code, it makes sense to put the wheel physics logic in the wheel's FixedUpdate for cleaner code, right? It is mostly right, but, it turns out, the order in which unity will run each monobehaviour's physics script is not deterministic, and if you want deterministic physics (at least on the same computer), you need to call the wheel's FixedUpdate function manually within the car's FixedUpdate (and yeah the FixedUpdate on the wheel would be renamed so it isn't called by Unity).

• The code for serialization and deserialization of objects was also written in a really unscalable way. I would manually be adding code to wrie and read each variable from a file I wanted to save and load. V2 is using a JSON-like serializer that can automatically load and save various objects with fine control over how the fields are loaded and saved, but with next to no code needed to be added/removed to save different kinds of objects.

  • 4 years later: Done. Although I think I would just use someone else's JSON serializer next time rather than roll my own

• I had also used AnimationCurve excessively as a way to influence the way that the cars would behave. For those of you who don't know what that is, an AninmationCurve is a mathematical function composed of several bezier/whatever curves (Animation curves?). A script can have multiple animation curves, and the easiest way to view and edit them is in a popup window from the unity inspector. While this gave nearly infinite flexibility and customizability, and was good for prototyping, it also means that the implementation of my game's logic now depends on the implementation of Unity's AnimationCurve component. I no longer have the option to port this game to another engine, without rewriting the AnimationCurve component as well as a UI-based editor for that component from scratch - easily something that can take a week or two I think (at my skill/knowledge level anyway). This isn't a particularly bad mistake, especially since there aren't any plans to move away from unity any time soon. But it does put somewhat arbitrary restrictions on the game logic itself. A Physics engine is a somewhat commonplace in game engines, so having your game logic depend on 'rigidbody' for instance is different in that sense since most other gameengines will have an equivelant to this, but the same doesn't apply to AnimationCurve.

At least I've learned from the mistakes (hopefully). Tbh, if I hadn't come back to this game 2 years later, I probably wouldn't have known just how bad the codebase was. I was only able to spot these mistakes because of 2 years of doing other stuff.

If you actually read up to here, thanks.

Anyway, here's the orignal game description:

"It's not how fast your car goes, but rather, how fast you're willing to drive it."

- Jezza Clark, car expert

After a long hiatus, the world-renowned* game Racing Drift is finally back!

Delicately maneuver a nearly 1-tonne block of iron and rubber around curvy and unforgiving ribbons of tarmac to ultimately crash into a wall at 400km/h in the attempt of setting the best time on the leaderboard! It will take some getting used to at first, but your practice will be rewarded once you set the perfect lap! The ghost-replay of which, can then be raced against, or shared with other players.

The game currently features 2 cars and 7 tracks, with more being added in future builds!

Getting bored of setting times? Why not make the track instead! The game currently features a unique and flexible (albeit rather limited) level editor that will allow you to make any track at all given enough time**!

Controls

[W][A][S][D] to accelerate, steer, and brake/reverse the car
[/] to use nitro
[RShift] to drift

Credit where credit is due

Game engine: Unity3D
3D software: Blender
Text editor: Notepad++
Image editor: Paint.NET

At the moment there's some bug that is stopping gamepad controllers from working, will hopefully fix that at some point

*game is not actually world-renowned. in fact, you are one of the 5 people that have probably seen it

Future plans

**At the moment there is a Unity-imposed limit of the tracks only having 65535 vertices in any physics collider. I can however split up the track into multiple colliders, but I don't think there is much benefit in doing this. The next build will focus on improving the level editor to a point where objects created from external tools like Blender, 3DSMax, etc can be imported, thus allowing even the main tracks to be remade from within the level editor, and support for multiple instances of the circle-tangent curves (the current level editor consists of just 1 circle-tangent curve). This will give anyone the ability to make any track at all. Builds after that will allow for customizing the actual cars themselves. Once I have made a game where anyone can make any track on which they can race any car then I have finished the game, and future builds from my end will be unlikely. There is the potential of open-sourcing the game if I get to that point

#arcaderacing #arcade #racing #drifting