Ammo Counter; Implementation

Continuing from trying to figure out this problem from the design standpoint, I moved onto implementation. It worked out that there was a good amount of real estate on the gun model for the ammo counter.

This works great, but what happens when you aim down sights?

Obviously we have to remove the number, and that’s where our idea of the segmented progress bar works out.

This is our ‘machine gun’ example, and clearly reading individual ammo counts is difficult on the bar so let’s see how it looks with a lower count

So it’s clear that you have 3 of 4 bullets, and that information easily readable whether you are scoped or not.

Next up, health display..

New Challenge; The Ammo Counter

My latest exercise is to take take a modern FPS and remove the entire HUD from the UI layer without losing any information. The first element to tackle is the ammo counter.

So what information does the ammo counter need to relay to the player? If I have an energy weapon or a minigun with a massive clip, do I need to know exactly how many bullets I have left? Probably not, I’d prefer a progress bar. However, if I had a bolt-action sniper rifle then I would want to know exactly how many bullets I have left. We don’t want to solve this with 2 different solutions and we don’t want to display information we don’t for one or the other. The solution is the best of both worlds, a dynamic segmented progress bar:

Assuming the top bar is our minigun example, I can’t quickly decipher exactly how many bullets I have left but I know it’s roughly 25% and that’s all I need know. The bottom bar is our sniper rifle and even with the bar in my peripheral vision, I can quickly tell I have 2 shots left.

Now, things get tricky when you factor in your extra magazines. I like the idea of keeping it all in one bar to keep simplicity by nesting the segments like so:

Although I like this solution, it doesn’t scale well if you have 3+ mags. It’s at this point I start to question how useful that information is, why do I need to know that I have 17 mags in my bag? The truth is that I probably don’t, at most I need to know if I have another mag after my current one in empty. That’s a binary value, do I have another clip or not. A binary value is a lot easier to display, but I digress, let’s move past that issue for now and move onto actual implementation…

Diegetic Combat Text

Continuing on my quest on getting more traditional UI elements in the game engine, I figured to go with the seemingly simple task of combat text. Having the text in-game not only adds some depth and interactivity, but in this case I gave it physics to interact with the static world.

The first big hurdle was that since the text is a physical actor in the world, it gets really small when far away. A simple solution is a algorithm to scale the actual actor based on it’s distance to the owner’s camera. I think it’s kinda strange but I actually like it.

Lighting was another unforeseen hurdle, typically the UI layer isn’t effected by lighting so is always pristine but once you put it in the game then you have problems seeing it in unlit areas. I had to do some material trickery to have it unaffected and still ‘pop’ from the rest of the world. In these clips you’ll notice the text’s reflection on the ground, another cool side-effect of the diegetic approach.

I don’t know if the result is better than just rendering on the UI layer, but I think the physics interactions are unique and just needs some polish to look awesome.

Simple text in VR

Finally getting around to the Robo Recall Modkit and instantly I see a pet peeve of mine, the ammo text on guns

Looks fine, right? Let’s see it on a light background

Of course, we lose readability. Here’s my seemingly simple solution:

Stroke and a black background? Well, sorta, if you take a closer look you can see there’s depth and layers, and a tinted glass background to mute in every situation.

Layers stacked in Z-space looks great in VR as you get that Parallax effect. I initially wanted to limit the angle of the text so it was always facing the camera but it wasn’t even necessary, the layers make it readable at almost any angle.

The UI layer keeps dying..

While working on the recent Ludum Dare, a few friends asked for a quick component to show a path to a target point. Instinctively I started working on converting 3d points to 2d lines.

It was a complicated translation, but it worked. It was clear that it wasn’t going to hold up with complicated paths with varying depth.

I started ‘fixing’ it to change it’s look based on the distance from the camera and then had a moment of clarity, why not just render the path in the 3d space? It’s a solution that I seem to come about more and more lately.

A lot better, now it can have natural depth, be effected by lighting and match post-processing effects in the game.