T w e n t y S i d e d

You may remember that last week I made a spaceship model. I think I could do better if I were to have another go at it, but this model is good enough for now:

I didn’t mention it last time, but this isn’t a single ship model. Instead it’s built from modular pieces, and those pieces only cover the starboard side of the ship. I can then flip the pieces around if I want to put them on the port side. This means I can make the ship asymmetrical if I like. Also, I could make it arbitrarily longer by copying sections.

Before we scrub this model and start over, I want to see it in motion. Now, if I was building physical models, then I could hold this thing in my hand and run around the room while making spaceship noises. 

But since this model is just data, we’re going to have to settle for animating it on the computer. I could use Blender for this, but I’m more comfortable with Unity. So let’s import my model there. 

First I have to create a new Unity project:

Let’s talk about these options:

1. 2D – I don’t make 2D games, so I never use this. 
2. 3D – This is the default I use for most unity projects. If you’ve ever looked at a game and thought, “This looks like it was made with Unity”, then it was probably built using this template. The lighting model is designed to be mostly idiot-proof, which has the downside of looking a bit bland.
3. 3D With Extras – Same as above, but with some example assets to show new users how things work.
4. High Definition RP – This is the fancy-pants Unity setup for projects that want to use cutting-edge rendering techniques and are going for a more AAA look. 
5. Universal Render Pipeline – This template sets the graphics to work almost anywhere, including mobiles and ancient PCs. Good if you’re doing mobile development. Bad if you’re picky about visuals.

I usually go for #2, but what the heck? Let’s shove this model into the fancy-pants HDRP and see what it looks like…

Oh hey. Bloom lighting? That’s cool. I guess that’s enabled by default here. In my projects I normally have to jump through a bunch of hoops to add bloom.

This looks cool, but I’d like to see it in a proper space setting. Let me take two minutes and whip up a cheap space-backdrop…

(Almost an hour passes.)

Wow. The HDRPHigh Definition Render Pipeline. The “fancy pants” graphics. looks better, but it’s also almost an order of magnitude more complex to set up. The various lighting systems are all interlinked: Ambient light, atmospheric scattering, reflections, post-processing / color grading, global directional light, and background image. This is probably really handy when you’re trying to set up a terrestrial scene, but it’s a huge pain in the ass when you want to turn off half of these features. Like, it took me twenty minutes to find the settings to get it to stop drawing a horizon.

Anyway, once I have the settings wrangled I toss a 3D skybox over the scene.

Okay, there’s still some sort of horizon being drawn. I have no idea why or how. There are a dozen different dialog boxes that control this stuff, and they all have a dozen or so settings, and I’m pretty sure I’ve tried everything. 

This was supposed to be the mega-easy part, so it’s mildly infuriating that I can’t get it to render this very simple thing the way I want. I feel like this entire sky / fog / ambient / sky system is way more spread out than it needs to be. There are a couple of dialogs that don’t seem to do anything, and from reading the docs I get the sense that I’m seeing some middle-point between the “old way” and some yet-incomplete “new way” of setting up your scene in the HDRP. 

Whatever. I just wanted some stars behind my spaceship for the next step. I’m content to live with this goofy space-horizon for now. 

I want some smaller ships around. I jump back to Blender and model something that might generously be called a flying triangle. It looks like it was drawn by a child, but I don’t really care. I just want some small fighters to fly around and I don’t plan on looking at them up close.

I whip up some code for a fighter. Now, this ship would just be a speck moving around the scene and that probably wouldn’t be very interesting. But I remember that way back in early aughts, the game Homeworld helped you visualize the motion of all the ships by having them leave glowing trails. 

As luck would have it, Unity has a built-in “Trail Renderer”. I just attach it to the back of my fighter and tell it how long (in seconds) I want the trail to be. That’s it. Unity does everything else. If the ship moves faster, the trail will naturally get longer. 

I add a handful of these ships to the scene and let them swoop around randomly.

That’s pretty fun!

This is giving the ship the sense of scale I was hoping for. The ship feels more like a carrier now, and less like a space bus.

So… since I made these fighters. Why not make them fight?

I add the concept of “teams”, and I make two squads of fighters: Red Team and Blue Team. 

Now, in any of my pre-Unity projects, making dogfighting AI would have been a massive pain in the ass. Not difficult per se, just long and tedious. There’s a ton of code you need for moving and “thinking” in 3D space. 

But with Unity, all of that work is already done. Pages and pages of code can be expressed in one or two lines. For example…

 
    transform.forward = Vector3.Lerp (transform.forward, ai_desired_heading, 0.02f);
 
    transform.position += transform.forward * speed;

Every single object in Unity has a “transform”. This structure keeps track of the object’s local orientation: The “forward” value always contains the vector of where the fighter’s nose is pointing, regardless of the fighter’s position in space. It also has an “up” vector, which would point out of the cockpit. It would be “up” according to the pilot, ignoring what’s going on outside. The transform also keeps track of where the object is and some other key facts about its behavior in the world.

All of that work is done for me. All of those numbers are already calculated and ready for me to use when I need them, so I don’t have to write code for tracking that stuff myself.

The first line of the code above takes two vectors: The way I’m pointingtransform.forward, and the direction the nose of the fighter would be pointing if I was aiming directly at my enemy.ai_desired_heading It then calculates a vector between these values. The final value – 0.02 – tells it how far between these values to go. 

This line boils down to: “Turn 2% of the way towards my target.”

Two percent doesn’t sound like much, but keep in mind that this is done per frame. It’s going to do this at least 30 times per second, which can result in some pretty sharp turns. A value like ten percent will result in ships doing near-instant turns, which looks not awesome.

Now, if I was trying to make a game, then I’d want something a little more sensible and balanced. Maybe I’d put an upper limit on how many degrees you can turn per second or whatever. But I just want the fighters to put on a show, so I don’t mind if they make lots of wide looping turns.

The second line of code just shoves the ship forward according to its current speed.

In my old C++ projects, this would be pages of code. But here in Unity land, I’m doing all of this complicated movement stuff with just 2 lines.

I give the fighters the ability to fire lasers at each other. The result:

Now, at this point in the project I decide to take a break. So I alt-tab over to YouTube and randomly stumble on the announcement for Homeworld 3.

The series has been dormant for years. I’m doing a project that roughly copies the superficial look of Homeworld, and suddenly I hear that a sequel is coming. 

I realize it’s a small, inconsequential coincidence. But it was still quite a shock for me in the moment. 

I should do a project to recreate the look of Half-Life and see if anything happens.

EDIT: As requested, here’s an animated GIF of the action…

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.