An Elegant Shader for a More Civilized Age

It surprises me that I had to go through so much trial and error to find such a shader for such a simple thing.

But here it is!

Imagine, if you can, a game featuring a city setting, populated with cars all around you. It shouldn't be too hard to picture. It would be pretty lame if all of those cars passing you had identical paint jobs, right? But how do those games do it? How do cars procedurally instantiate around the player, each in a different colour? Wait - more importantly - how will I do it?
Easy: MAGIC! ...Or is it math?
Shaders (in a really dumb nutshell) are programs that talk with your computer's GPU, instructing it how to render what you're seeing in the game. They calculate the colour of the thing you're looking at, account for things like lighting, specularity (i.e. shininess), texture (is it rough or smooth?), and emissiveness (does it glow?), and generate a final pixel colour - and it does this for each pixel on your screen!
So the answer, naturally, is to build a shader that can randomly generate colours and patterns to apply to a single 3d model, giving it a varied look. To do this, I used four basic textures:

Colour, Detail, Metallic, Normal

• The colour replace map to determine the basic pattern and colour of the paint job. This doesn't look like much but I'll explain.
• The detail (or diffuse) map shows the car's actual visual texture - metal fixings, rust, dents, and so on.
• The metallic (or specular) map determines specularity - where it's shiny and how shiny it is. Black is dull, while white is very shiny.
• A normal map, referring to the geometric normal of a surface, which determines how "bumpy" or textured the model will look. It will talk with any light sources in the game to simulate high and low spots to give the model a more detailed look.

The Jokermobile never looked so good.

 Most of these things are pretty standard; Unity ships with a bunch of shaders that handle this stuff - except for the colour replace map. Basically, the shader I put together takes the red, green, and blue values of the image, and substitutes each with a new colour, which themselves can be either hand-picked, or generated with a bit of code when the car instantiates in the game world.

The end result is simple, but pretty neat, if I do say so myself.

Get you a cab that can do both.

So now for each car model I end up using, I can add three or four colour replace maps, then replace the colours of those maps to get lots of variety on the mean streets.
Speaking of car models, the model I'm using was not made by me; it's a placeholder I'm using, made by Renafox on Sketchfab. I've made some modifications to the textures - and, of course, removed the wheels. Renafox has tons of car models, and other neat stuff available, and its all amazing. Check it out!
I hope I was able to explain myself well enough here. And for those interested in the shader code itself, check it out here. Any suggestions for improvement? Feel free to post a comment here or on the linked page.
What's next? Camera stuff?

Hover? I Hardly Know 'Er! My First Actual Bit of Content!

Whammo!

Here it is! My first actual project-relevant post!
One of the first things I wanted to try out for this project was a way to design interesting yet realistic handling for the player's car. Obviously, I wanted it to be intuitive and fun for the player, as well as looking "realistic" and cinematic - two things which are often opposed.
The original Quarantine game was no help here, as it actually handles more like a real car. Allegedly, according to Ray Larabie, who worked on the game:

The original demo was done right about the time Wolfenstein 3D came out. There were some flat shaded polygon cars running around the streets but the poly count was limited for forty, Not enough for round wheels.[...] After we switch to sprite cars we were used to the idea of hovercars.

So despite having hovercoils instead of wheels, the car would only turn while moving forward or backward. The main difference was if you got hit, you'd pinball around a bit. I wanted to make a genuine "hovery" feel, and felt like that involved drifting, and even strafing, which would make hovercar combat significantly more fun.
There were three things I could see myself experimenting with:

1. Physics-based force applied to the four corners of the car, mimicking the actual force that would be generated by the car's hover engines. I knew this would probably give me the most realistic effect, but was worried about the efficiency of using this en masse. More about this later.
2. Wheel colliders, with "slippery" wheels. The nice thing about wheel colliders is that it emulates the shocks absorbing the car's shifting weight. I was hoping to basically make wheel colliders, but with invisible wheels, and give them very little friction to allow the car to slide laterally. This didn't work well, as the car still had to be moving for it to register any forces acting on it. I considered a few tank-type setups, using three wheels on a side, which allowed for turning of a dime but not sliding. Additionally, the more I looked at wheel colliders, the more finicky they seemed - there were a lot of variables involved that I didn't really grok. Additionally, I have the impression they wouldn't have been any more efficient than physics forces, ad they themselves use similar (or more) such forces. It's possible someone with a better understanding could have made this work, but it wasn't the right approach for a laymoron such as myself.
3. Using an invisible, frictionless collider as a sled, with the car interpolating its rotation as the sled slides over uneven ground. I abandoned this idea without even experimenting because it seemed like it would never have worked for many reasons (if you've done this convincingly, change my mind!)

Ultimately I went with the first option. I followed a great tutorial by Claire Blackshaw to get the basics (and the test scene) established, then made a bunch of modifications to fit my needs. The most significant adjustment I made was that I found the car far too flighty, causing it to drift too much, and to flip too easily. I bumped up the car's mass and drag, which tightened the controls significantly, but the drag made it float like a feather when airborne. Since it's already detecting if its grounded or not, I set the car's mass to be basically nothing when the car is not grounded, so at any time, the car is either grounded, draggy, and easily controlled; or airborne and dragless.
I've also lowered the rigidbody's centre of gravity, which makes the car more stable and likely to stay upright. This is a bit of a tricky thing because if it's set too low, the car will try and stay level even when on inclined planes, and if it's not centred to the forces applied by the hovercoils, it'll list or flip very easily. I ultimately just added some code to set it to the average positions between the hovercoils.
As I mentioned, I feared this would be a performance problem if every NPC car used this system as well. My hope is that I can fudge NPC movement while they are idly moving about the city streets, only switching to full physics mode when attacked. That's a way off - stay tuned!

It still need some fine tuning to get things where I want them, but I think it's pretty good overall. One thing I'd like to experiment with is making adjustments to the centre of gravity as the car accelerates to accentuate the feeling of the car's weight shifting.
What does everyone think? Feel free to comment and let me know! Next post will probably be about a shader I made for the car. It probably won't be a terrible read!

What Else is New?

I've decided that I won't just concentrate on what I'm reading, and just kind of quickly chat about whatever comes to mind. This time though is about what I'm reading. I've just started Yoshiko, the third book in the X-Universe series, by Helge Kautz (and translated from German by Nathan Haines). It's based on a series of space trading sims I've been somewhat obsessed with for years, and I'm really glad the novels based on the games is finally being translated. The worldbuilding in the universe is really great, and the story is a lot of fun.

Write a Game Design Document... But Not Right Away

So, I've gone an pulled a sneaky on you. The Quarantine remake I posted about doing is not something I just started the other day. It's been on my mind for a while, and I've been actively working on it for about a little over a month.
"What was your first step?" You ask. If you're familiar with game development, you may snarkily add, "Surely it was drafting a detailed game design document?"
Absolutely not, you fictional know-it-all.
For those who may not know, a game design document (GDD) is a high-level yet detailed write-up of everything you intend to put into your game. Not so much from a technical standpoint - there's a separate document for that - but your game's structure, control schemes, game world details, character bios, monetization/marketing strategies, and so forth would all be outlined here. It's the equivalent to the "production bibles" used by film companies to make sure their fictional world remains consistent and fleshed out.
So why not start with one? Surely, you've started with an idea - why not get that down on paper before you lose it?
Fair point - keep some notes. Have a scratch pad handy to get down those rough, unrefined ideas. But let them stew before you commit them to a more formal document. You may find that, after a week of mulling it over, your talking sandwich sidekick isn't as funny as it initially seemed, or that on reflection, one of your fundamental game mechanics isn't as fun as it sounded while drifting off to sleep three weeks ago.
I'll give you a concrete example related to my Quarantine project:
The original Quarantine had a really neat diegetic ui:

Quarantine screenshot from MobyGames

All the information you need is presented to you in the same way it's given to Drake Edgewater, you player character. Health, ammunition, mission time, and so forth is all presented on your cab's dashboard in a clunky yet artistically appropriate way. Players can look (and shoot) out the side windows, and blood and bullet holes will appear on your windshield as you interact with the game world. I had initially imagined doing something similar but, as I intend to add lateral movement (i.e., strafing) to the car's controls, this up-close first person view isn't as useful. to get the spacial awareness to strafe effectively, I decided a third-person view a la Grand Theft Auto V would be more appropriate, which would make a cab interior-inspired UI no longer diegetic. If I had started with a GDD before giving it enough though, I'd have to go in and edit it.
Which, to be fair, isn't a bad thing. After all, a GDD is meant to be a living document - it should be frequently updated - but the more poorly-thought info that goes into the document means more room for missed corrections.
There's another reason starting with a GDD may be a poor choice for you: Motivation. You could spend so much time planning and detailing your project that you don't actually spend time working on it, and you lose the momentum you need to continue on. That's a big problem for me personally; I start projects strong, and lose steam along the way, eventually being replaced by a new project.

Memes. amirite? From Reddit.

Instead, I flagged a few things that may present a challenge, and dove into prototyping it. In this case, it was the controls for the player's hovercab. Would I need to use Unity's physics forces to keep the car aloft? Could I use wheel colliders, but with invisible wheels? Could I fudge the effect with an invisible "sled" collider? And in what ways would controlling a hovercar differ from a wheeled one? Diving into this discovery and prototyping phase was much more engaging than sitting down in front of a Word document for hours, and I'm glad I started with it.
Of course, your mileage may vary. But in general, my advice would be to find something you look forward to doing and start prototyping. It may end up changing your vision, or details thereof.

Generic Welcome Title!

All in a day's work.
I'm setting this up because my hobby - game development and generally screwing around with game developmentey stuff - involves a lot of work but rarely gives me an outlet to show people the work I'm doing, as many of my projects don't become a marketable product. But I often come up with some neat stuff so I figured I'd share it here. Maybe it'll help someone. Or maybe my crappy code will give someone a laugh.
I currently have a few projects on my table; I'll go into detail on them as I work on them. Currently, my newest project is a recreation/update to an old PC game I used to love as a kid: The 1994 shooter-driving sim Quarantine. Set in a dystopian prison city, you drive a weapon-encrusted hovercab to survive and find a way to freedom - kind of like Grand Theft Auto meets Escape from New York. I had largely forgotten how great - if flawed - this game was until I saw a review for it on Ross's Game Dungeon, a YouTube series I can't recommend highly enough. The game hasn't necessarily aged well, but the concept and visual style gives the game a lot of charm.
Some of the things you'll probably see me blunder around with in this project are:

• Physics-based hover controls.
• Shader design that will BLOW YOUR MIND.
• Context-based ground detection. 
• Designing a "point buy" item system I haven't personally seen before (stay tuned!)
• AI pathfinding for traffic.
• Unity's Entity Component System.
• Dynamic pedestrian behaviour.
• Probably some bewildered crying and/or panicking. I might not post much of that but rest assured that it's happening.

So, if you like post apocalyptic driver/shooters, game development, or mediocre blogs in general, this may be right up your alley!
I also like to read! So, I may finish some of my posts with a segment I like to call

What Am I Reading Now?

Currently, it's Navigators of Dune, by Brian Herbert and Kevin J. Anderson, which is the latest book in the Dune expanded universe. I'm obsessed with Frank Herbert's original Dune series, and I'm committed to reading basically everything Dune adjacent. I reread the series over the summer, and get something new from it each time. Unfortunately, the expanded books lack the depth and artistry of those originals in my opinion. I'll be glad when I'm done, as this is the last one for the time being.