T w e n t y S i d e d

I sort of skipped a bunch of steps at the end of the last entry, because I was in a hurry to get to the point where we could see ships shooting at each other. But now that we’ve made it, let’s back up and talk about how we got here. Specifically, I’d like to respond to this comment…

I really enjoy this kind of content – programming, explaining complex IDE type objects (I’ll probably never try Unity – I’m a back end natural language processing type guy – but it is fun to see someone else struggle with it). Looking at the GIF I’m sad there wasn’t a paragraph or two about how the lasers were added: was that hard? Does Unity have an “Add laser” button? I feel like it might. I also think that each ship must track some sort of hit points value, because I saw one of them get hit (oh to have a discussion about hit boxes, and how to determine if a laser is inside one or not – I remember two decades ago trying to code up hit detection code and there are lots of optimizations in that area) and then flame out and explode. Lots of complexity hiding behind that I suspect!

Unity doesn’t have an “add laser” button, but we can re-use the trick from last time to save ourselves a bit of work. 

In Unity, you create game objects, place them in the scene, and move them around to make gameplay happen. Usually a game object will have some geometry attached to it. Like, I could jump over to Blender and whip up a laser bolt model to use. But instead I create a laser object with no geometry and attach a TrailRenderer to it. 

A TrailRenderer is what we’re using to give the fighter ships glowing exhaust trails. I just need to set the length to a smaller value and it works as a Star Wars style laser bolt.

Hit Detection

I don’t actually need proper hit detection for these space battles. Since none of these things are player-controlled, I don’t need to play fair. Rather than tracking laser trajectories and testing for collisions, I just roll dice in the background. 

When the laser is fired,  I roll to see if it is destined to hit. If it’s a miss, then I have the laser fly past the target. If it’s a hit, then the laser travels directly at the target. Properly leading a target takes extra calculations, so I don’t bother. Instead, the laser just flies itself into the target like a homing missile. If it moved slowly, then you’d be able to see the curve. But since the lasers are moving so fast, this brazen cheating is undetectable. 

However, I do still need collision detection!

See, my camera system is very primitive. I click on an object to begin following it, and then I use the controls to zoom / orbit the object. When you click on the window, Unity casts a ray from the camera origin to the mouse location. If I want to be able to select an object, then I need to give it some sort of ability to be hit.

In Unity, an object needs to have a collider if you want to detect interactions with other objects. Things like objects running into each other, objects running into the environment, objects being hit with rays, etc. If you don’t give an object a collider, then it will ghost through everything else in the scene and will never be available as a target for bullets, mouse-clicks, and the like.

There are a few different types of colliders you can use. As the developer, you need to balance speed with accuracy. You can have flawless per-pixel hit detection on every strand of your protagonist’s hair if you don’t care about framerate, or you can have blazing fast and wildly inaccurate collision checks that treat your protagonist like a big cube. 

Sphere 

This is the simplest collider of them all. You give the sphere a radius and Unity will treat the object like a ball.

Cube 

A bit more accurate than the sphere in many cases, but very slightly more expensive.

Simplified Model 

This is the most common technique. You have one model for the visuals, and another 3D model that’s the same thing with simpler geometry. A great example of this is in Team Fortress 2, where characters are treated as though their limbs are made of boxes for the purposes of hit detection.

This provides a pretty nice tradeoff between speed and accuracy. However, it’s not perfect. In the above image, you can see that everyone effectively has a box over their heads. If you hit anywhere on the box, then it counts as a headshot, even if the bullet would technically miss the head inside. 

If this is still too sloppy for you, then there’s only one option left…

Full Model

If you really need absolute perfection, then just use the same geometry for the visuals and collisions. This might be acceptable if the base model is fairly simple, or if you only have a small number of these things in the scene, or if you’re not going to do a lot of collision checks.

This will quickly turn into a disaster if your game features lots of busy models and lots of collision checks. For example, imagine a battle royale shooter between anime-style characters where the figures have lots of elaborate hair, hanging belts, and fluttering capes. Give everyone a machine gun and watch your framerate drop to single digits.

Sure, the game will be unplayable, but it will finally put to rest arguments over hitboxes.This is a lie. People will argue about hitboxes no matter what you do.

For the purposes of this project, I just need to put a sphere collider over the fighters so they can be clicked on. And since the ships are usually pretty tiny and clicking on fast-moving things is hard, I make the sphere about twice the size of the ship so that clicking on them is easier.

Hitpoints

Initially I started out with a simple system where shots always hit. Each fighter had 4 hitpoints, so ships exploded after 4 hits. However, this made fights incredibly mechanical. Everyone fired at the same rate, and so the resulting dogfight was very rhythmic. Four shots, then an explosion.

pew-pew-pew-pew-BOOM!

pew-pew-pew-pew-BOOM!

pew-pew-pew-pew-BOOM!

And so on. I tried adding a random to-hit chance, but the underlying rhythm of the lasers was still there. I made sure everyone’s lasers were out of phase with each other. That scattered the shots, but the ships still blew up very regularly. It just didn’t feel like the chaos of a real dogfight.

So what I did was assign each ship a random armor class of 18 or less. Ships roll 3d6 to shoot, and they have to roll higher than the AC of the ship they’re attacking in order to hit. This finally broke up the action and made things feel organic. 

Small mistake: The highest AC is 18, and you have to roll higher than the AC to score a hit. So once in a while I’d get a fight that had an AC 18 fighter in it, and that fighter would be an untouchable god. Very high AC values in general were bad, because it made sure the last two fighters would take forever to finish each other off. Capping AC to ~15 or so gave the fight an organic feel without turning the ending into a slog.

There’s one final problem I want to talk about…

Iteration Friction

When you’re making some form of content, you often have to deal with iteration friction. Maybe you’re doing a mural and you have to wait for a layer of paint to dry before you can appraise the work you just did. Maybe you’re making a videogame level and you need to launch the game / load the level to see your changes. Maybe you’re editing a video and your editing software lags and stutters on the 4K footage, so you have to render a section of the video to see if the audio is in sync and the cuts work. Maybe you’re writing a book and you need to get feedback from your editor to know if your revisions are any good.

Friction sucks, and it’s a major reason why giving accurate time estimates on a project is such a nightmare. Five or ten seconds might sound small, but those lost moments add up over the long haul. These intervals are particularly bad for concentration. The chunks of time are large enough to break your concentration, but they’re not big enough that you could use them to accomplish something else. 

Moments of friction can lead to you getting restless, picking up your phone, and suddenly this 15 second wait turns into a 15 minute distraction on social media. 

Friction tends to increase as a project matures. When you’ve just started a new level, you can rebuild the lights and shadows instantly. Once you’ve put a couple of days into it, that same task might take over a minute. The more complicated the level gets, the longer it takes to recalculate the lights and the longer it takes to load it in-game. 

I imagine this is the reason so many games have your character crawl through a narrow gap that breaks line-of-sight.Jedi Fallen Order is the most recent example of this that I’m familiar with. The level can be split into two smaller halves, and then those parts can be stapled together at the end. This saves the level designers from needing to work on the entire area as a single project.

Iteration friction is a thing in coding, too. Your typical compiler can compile a single source file in a fraction of a second. But the project grows over time. One source file becomes a dozen, and then two dozen, and then fifty, and then a hundred. Pretty soon it takes fifteen seconds to compile small changes. If it takes you an hour to chase down a fiddly crash bug, you’ll probably spend ten minutes reading and writing code, and the rest of the hour will be lost to compile times and loading screens.

Unity is actually pretty good about friction under normal conditions. Your project is going to be written in C#, which is a high-ish level languageReminder that high  / low languages are backwards from expectations. High level languages are easy to read. Low-level languages are terse and inscrutable. with a bunch of fancy tools wrapped around it. This sort of thing is prone to debilitating levels of friction. But I would say that Unity fares pretty well for what it offers. It’s going to be higher friction than a project written in vanilla C, but not by much.

However, there’s something wrong with Unity’s HDRP. I don’t know why, but this project has a baseline 10 seconds of friction, right out of the gate. If I change ANYTHING – a source file, a texture map, a model – then when I jump back to Unity it will stall for ten seconds before I can do anything. That’s really sucking the joy out of something that’s supposed to be a no-stakes, low-effort project.

On a whim, I make a duplicate project using Unity’s default render path. With the same code and the same assets, this new project has about one second of friction instead of ten.

That doesn’t make a lot of sense. Yes, I’m sure the HDRP is more complex under the hood. But why does it take so long to integrate simple changes? Even if all I do is rename a single variable, I still have to wait ten seconds instead of one. What’s it doing in those nine extra seconds? Recompiling every shader for every possible render path for no reason? Is this a bug?

Anyway, I think I’m done fiddling with this project for now. I have a list of additional things I want to try,I still want to take another swing at making the spaceship again. but I’m currently posting 5 days a week and I can’t scrape together enough hours for programming with that workload. I hope to get some lead time on my other writing and then pick this up again later. 

Shamus Young is a programmer, an author, and nearly a composer. He works on this site full time. If you'd like to support him, you can do so via Patreon or PayPal.