Okay, I really need to get gunplay going. For that the player needs to be able to aim and shoot. I have the basics, but it still feels rigid and un-fun. So let’s start with a proper weapon aiming reticle on the HUD. First, I got to make a HUD element follow my mouse. Couple hours later…

This is way more complex that it sounds. Unity has way too many options for its stuff. First I have the mouse position based on screen size, which I need to normalize. Then there’s HUD canvas with its pixel size and reference resolution and dimension matching. Furthermore, there is an aspect ratio difference between the screen and the reference resolution. And all the stuff has slightly math-incompatible coordinate origins. And the canvas itself has everything anchored and pivoted, not to mention, as part of hierarchy. And it all has to work in all resolutions and aspect ratios, even if dynamically resized. But I eventually got it to work for my current setup.

For the visuals, I’m going to use a four-part player reticle sprite:

And I can use that in-game so (as rotated images):

Final display thing is to hide the mouse cursor while OS is focused on the game (for testing, I will keep it visible and also capture for screenshots/GIFs in this post when relevant):

This is a software cursor, which means it doesn’t match the actual raw mouse input location perfectly. If the game doesn’t lag and has high FPS, then this is fine. Also the next stuff will make any potential issues less obvious.

Now I can add aiming offset to my camera. This will be part of the same camera system that follows the player. Basically, the camera pans from the player towards wherever the player is aiming:

This is still a static distance from the player, regardless how “far” the player aims. I need it to pan only when the player aims “away”, that is, the cursor is further from the center of the screen:

There is a dead zone when the cursor is right on the player to avoid tiny useless changes. Then it increases half-way towards the screen edge. The actual value should be around where the player is expected to aim at most. The final segment is fully offset and the player can move the mouse further without any additional offset being added. And this works out nice avoiding any jarring jumps:

I have to be careful not to make too much offset and make turning 180 degrees a big camera jump. I also have to be careful not to make it so subtle it’s useless for gameplay. The cursor has to stay smooth enough that the player can reliable place and keep it on enemies with predictable movements. So camera has to pan smoothly. The vertical and horizontal offset amount and dead zone differences are also important, because it takes less mouse movement and there are more world tiles that the mouse travels over. And the player model isn’t actually in the middle of the screen due to the camera tilt. All of this is something I just have to iterate on until it feels right (or at least, doesn’t feel wrong). For example, an extreme example of player moving left while aiming far right:

This is all mouse-centric and I don’t exactly know how this can or should translate for twin-stick controller controls. Though I imagine the aim stick tilt is sort of the same as moving the mouse around, so it shouldn’t be overly problematic.

This is a relatively simple feature compared to some of the other stuff. But at the same time, it is very impactful — the screen movement with the aiming brings player’s immediate input to life, so to speak. It definitely creates a lot of dynamic movement and is much better than a static camera.

Reticle is something the player will be looking at a lot. So it’s important to get it right as well. So I will define my reticle options in separate assets and reference by appropriate weapons:

Then I can specify the basic options:

So, for example, I can have similar but differing reticles for machine gun and pistol:

Now I can also make the reticle do similar “kick” that the weapons do. In the case of reticles, this just increases the spacing distance from center. I can control it per reticle with various options:

It looks like this:

Unlike the weapon, I have to keep the reticle much smoother. That is, the distance change cannot be too sudden or too great. Multiple shots however can accumulate up to a maximum. There is also a short grace period during which the reticle stays expanded. Basically, I’m adding extra “maths” until it looks right.

These values don’t necessarily represent anything about the weapon, although they give a rough estimate. This means I have to configure the weapon bullet spread, the weapon model kick, and the reticle kick separately. But it’s still faster than writing some sort of magical conversion between the values. Also, I don’t actually have increasing weapon inaccuracy. So I might as well add that (exaggerated for demo):

With pretty much similar parameters:

I only want marginal increase though. This isn’t really to punish players for spraying guns. This is more to reward players for tapping and bursting, basically, cheeky sniping if that suits their playstyle.

I also currently have weapon reload in the game, if not ammo count. I don’t even know if I need reload. On one hand, it interrupts what is otherwise player mowing down enemies. On the other hand, it gives the player a small forced timeout to reposition, evaluate what they are shooting and just tunnel-vision a bit less. Reload needs extra weapon data, extra HUD, items to keep track of it, and likely other extras. And replacing reload with just an ammo pool has pretty much all the same requirements, just for empty weapon. If I keep the reload mechanic, then I need to have some sort of better reload indicator, very likely on the reticle as well. For now I’ll leave it alone and deal with reload stuff later.

I think that’s about it for the reticle. I feel like I’m missing something here. But I also don’t want to over-complicate it and nothing else seems necessary.

MicroRogue DevDiary #24 – HUD Reticle
Tagged on:     

Leave a Reply
