Hovertanks

Warning! This is unfinished and will see no more development!

This project is cursed for reasons I won't get into and so I want nothing to do with it anymore. But! I think there's enough neat things in here that it's worth releasing anyway.

Controls

Some of the controls might seem a bit weird (like the jump being on left bumper) but that's because I was planning on a bunch of stuff that didn't happen.

	Mouse/Keyboard	Gamepad (Xbox)
Move	WASD	Left Stick
Turn/Aim	Arrows / Mouse XY	Right Stick
Target	R	Y
Untarget	R (Hold)	Y (Hold)
Jump	Spacebar	Left Bumper
Switch Vehicles	F	Back

What killed it?

Aside from some personal stuff, part of what killed this is that I got really obsessed with loading/unloaded resources using Addressables. Addressables are a Unity feature that I really want to like. In theory, it gives you a lot more control over when things load and unload, gives you a way to reference prefabs and objects without needing direct references to them, and some really slick asynchronous functions for loading and instantiation.

I'm not sure what game got me on this track, maybe it was Destiny or something, but games with really seamless loads and loading screens have been in the back of my mind for a long time. It's a very difficult thing to do in Unity for many deeply rooted engine related reasons and Addressables are probably the closest you can get to achieving that without some really heinous "writing your own engine underneath Unity" engineering.

Long story short, I only partially succeeded by writing a horribly complex loading screen that didn't even work that well and massively complicated the game's architecture. In the end, I threw out almost all that code because what actually worked best was a simple non-animated black screen where you can't tell there's any pauses actually happening. The loading screen fades in and out before and after loading has completed so it looks freeze-free but it's really not.

Actually Good Lessons Learned!

Thankfully it wasn't all for nothing, as there were some good lessons learned from this, and I'd rather focus on what worked than what didn't.

Not bad hovering vehicles!

This is deceptively difficult to do. At least for me. I've tried many times in the past to make hovering vehicles, but I've never really been happy with any implementation. This is the best one I've done so far, and I think the closest to something actually good. Essentially the vehicles rest on what I call "hoverballs" which are mostly the wheels from this excellent video that I constantly link to people. The main differences being that mine don't apply any friction, and they can't "suck" the hover vehicle down into the ground. (Though I did leave that as an option because it was interesting to experiment with.)

Lateral movement is achieved through thrust and the simple Freelancer formula for drag. 

Animations made in Blender + Blend Trees!

Animations in general are probably my biggest Unity blind spot. I have almost no experience with using them, since for 99% of things I just programmatically animate things. There's been a handful of exceptions, but that's really it. This time I wanted to specifically use animations for the vehicle movements because it's something that I know I can apply to many other things. Plus, it's better to let artists just make something sometimes.

The hardest part of this was honestly the Blender-side of things. Blender's animation is utterly baffling to use on every level and for some operations I just have to keep trying the same thing over and over until eventually it works and I have no idea what I even did differently that time. It's no good!

Global Event Systems Are Very Good!

This isn't the first project where I've done this, but I think this one really cemented it as a design pattern going forwards. For so many reasons including level design, hooking up seemingly disparate things, and just solving lots of little problems you didn't know you had until you have them, having a global event system to keep track of things is immensely helpful.

For example, the HUD needed to keep track of the weapon state on the player vehicle. The easiest way to do this is just poll the player, but that's kind of annoying and can create a lot of waste if you're dumb about it. Instead, just listening to the events for when a weapon is fired or when the player takes control of a new vehicle to initialize the weapons readout is way easier!

Good Mouse and Keyboard + Gamepad UGUI Navigation!

Anybody who has tried to make a Unity game that uses the mouse and gamepad for navigation has probably come across some really annoying quirks that feel just awful to interact with. This is such a problem with UGUI that Genshin Impact solves this (and other UI problems) by literally writing 2 completely separate UIs for the game, one exclusively for mouse, the other for gamepad. (And maybe a third for mobile?) You've almost certainly played an indie Unity game that has these quirks.

It's easier to explain the fixes than the quirks themselves, so I'll do that instead. Going forwards, this is the way to do it. It's actually very easy to do if you do it from the start, but I feel sorry for anybody who wants to retrofit this into a game.

1. On the Input UI module, uncheck the Deselect On Background Click option. This means that no matter what you do with the mouse, you can't unselect something, leaving something always selected. This creates a new problem though, now you have that super annoying "stick buttons" thing that so many Unity games have!

2. On all your buttons or otherwise interactables, implement the IPointerEnterHandler and use that to set the current button as selected whenever the mouse goes over it. This can done with a trivial component (pictured above) and then added to all buttons.

With these two things together, you can have great UGUI navigation with gamepad and mouse. Buttons no longer "stick" and instead it feels it's just showing the last thing you highlighted, not the last thing you clicked. Minor difference, mostly psychological, but it's a big improvement. On top of that, since the mouse is selecting things automatically, you never put the game into a state where no UI element is unselected, effectively getting the gamepad "stuck" in a state where it can't select options

One more thing! If you ever set a button to non-interactable, you must also disable its raycasting! Otherwise Unity will still let you select the button and put the gamepad in a bad state.

It's frustrating, because a lot of these UGUI quirks feel so incredibly fixable on Unity's side, and they would be an improvement across basically every Unity game. To its credit, UI Toolkit (UGUI's replacement) actually does handle all of this extremely well. I think that's one of its greatest strengths. However UGUI is basically dead to Unity, so I doubt they'll ever fix any of these long standing issues that every game is required to work around.