Magical FX & Crosshair Feedback (DevLog #8) news

Barely missed the weekly post it looks like! Well, it's to be expected; homework is already piling up and I decided to put a little time into some cosmetic things and ease up on logic a tad, so I wanted to wait until I'd finished some of that stuff to make another post.

That being said, never forget that I mentioned in... DevLog #5ish?... that I would not get lost in the eternal dark pit that most indie devs disappear into. This game will release and it will contain magical girls loving each other whilst shooting each other's limbs off because if not me THEN WHO?

*ahem* Now, here's a short video showing the crosshair updates, some of the FX I've created to provide some visual feedback for weapon handling, and the new "Cover Blast" feature (which I'm personally quite excited to keep iterating on):

Crosshair System - Design

My goal for the crosshair system is to accomplish two things and two things only:

1) Give the player clear feedback about what's going on, especially with regards to weapon usage (i.e. how much bloom does the weapon have?, how long does it take to charge my weapon?, am I aiming at an enemy player?, etc.)

2) Be efficient (from a processing standpoint)

Pretty simple. You would think. But look, I'm a programmer, so I really have to lay these things out step-by-step or I just get lost, especially when it comes to pie-in-the-sky stuff like visual feedback. In the end, I decided on the following necessary features for my first draft:

-> Bounding box/circle shows how much bloom the weapon has

-> Animation when shooting to enhance the "feeling" of shooting

-> Status indicator dot/cross that changes colors when moving over an object of interest (OR when an object of interest moves over it... see the implementation section for more on that)

-> A "charging" indicator of some sort that clearly shows how long it will take for a weapon in Magic Firing Mode to charge, as well as when it has finished charging

-> Some effect to show that the player has activated a "Cover Blast"

And so, I set about checking off all those items! For the prototype, I'm using some simple crosshair designs I bought off the UE4 marketplace that looked configurable. What I liked about these is that they put different crosshair elements in different RGBA channels, so it was easy for me to customize materials on a per-channel basis and mock things up quickly. I'll likely be using this same technique for the final designs.

Anyway, here are some screens showing the changing color of different elements in reaction to different objects of interest:

Default White (Aiming at nothing important, or aiming at a friendly player):

Red (Aiming at an enemy player or a destructible object):

Team Color (Bounds changes to team color when in Magic Firing Mode):

Team Color (Status indicator also changes to team color when player is aiming at a piece of cover they can Cover Blast... more on that in the "Cover Blast" section):

In addition to the color changes, I've also added some fancier (and hopefully still subtle enough to not be annoying) effects for shooting and charging a weapon. The GIFs below show me shooting and then charging both the shotgun and handgun, so you can see both effects. It's a bit blurry because I needed to compress for IndieDB, (the video linked at the top of this post shows everything in high detail), but hopefully gets the idea across:

As you can see in both images above, there are a few different crosshair animations happening in quick succession. The shooting animation has the reticle expand and contract, at almost the rate of fire of the weapon. If you then hold down the shoot button, a "charging circle" begins to progress around the status indicator until the weapon is charged, at which point it highlights and sends out a quick "ping" to make it clear that the weapon is charged.

After that, the little spinning circle you see around the status indicator will remain until the weapon is fired. Mind you, the spinning circle is important as well, because it indicates the size of the charged projectile (so if you're trying to hit someone standing behind cover, for example, you'd want to make sure to position the circle above the cover!)

Crosshair System - Implementation

The implementation was a lot more of a pain than you might think, because I'm extremely picky about making sure things are as performant as possible. Not only that, but the crosshair implementation was something I was dreading a little bit for one reason in particular: I have to use Tick.

Yep. Finally have to use the dreaded Tick function. There's no way around it; I can't put the functionality in the functions that calculate the player's Yaw and Pitch, for example (something I'd initially considered), because then it won't update if something moves in front of the reticle while the player isn't moving. It has to be Tick.

Anyway, the way I'm getting it to work is as follows:

-> IF the player starts aiming, enable Tick and run a "CrosshairChecks" function.

-> In the CrosshairChecks function, run 2 line traces at all times: One line trace that detects player characters and destructibles, and another line trace that detects all visible world objects.

-> IF the player is in Magic Firing Mode, run a 3rd line trace that detects CoverBlastPlanes (actors I'm using for the Cover Blast feature. More on that in the section below).

-> Each possible crosshair status has an unsigned integer value associated with it. For example, if the requirements for turning the status indicator "Red" check out, I might set that integer value to "1". Using this value as a "gatekeeper" of sorts, I run a series of checks in code that see whether we should then change the status to something else or not. Here's some psuedo-code to illustrate:

IF (StatusIndicator == RED):

IF (CharacterLineTrace != Blocking AND (CoverBlastLineTrace != Blocking OR DefaultLineTrace.Distance < CoverBlastLineTrace.Distance)):

StatusIndicator = WHITE;

ENDIF

That's obviously WAY simplified, but you get the idea. I do checks like this for each possible status we could change to from each other status.

So the biggest cost I have to pay on any given frame is running 3 line traces and doing some bool checks; not really a big deal. Using the 3 different line traces also means I can avoid a lot of the casting I would have to do otherwise, which I really wanted to limit as much as possible on Tick because it's expensive. There is some casting I have to do, to check to see if the player you're aiming at is an enemy for example. But my understanding from research I've done poking about in forums is that line traces are much less expensive comparatively, so I believe I've made a good choice in avoiding it where possible at the cost of additional traces.

Cover Blast - Design

Ok, I should touch on this next. Cover Blast is a working title for a feature that I came up with on a whim during the past week. Funnily enough, the inspiration for it was me being unnecessarily lazy; I was getting annoyed trying to get the player to be able to shoot all the way over cover (the solution ended up being really simple, btw), and started thinking "man, it'd be nice if I could just shoot through cover!"

...And, well, now you can! Kind of. It's not nearly as OP as you think :P

Basically, Cover Blast is a "generic magic ability", which means all players have it available at the start of a match. If the player is in Magic Firing Mode, and they're willing to spend a little mana, they can send a "Cover Blast" through any flat surface that you can take cover behind (this won't work behind more complex objects like trees, cars, etc.). It's much easier to understand in motion (see video at the top of the article), but here are a couple screens showing the basic idea:

...Probably should have used the same team color for both screenshots, but hey, it'll do. The first screenshot is of the area of cover about to be blasted "lighting up". Once it fully lights up (over about 1 to 1.5 seconds), a "blast" is sent out the other side of cover, as seen in the second screenshot, and any enemy players standing within the blast radius will be damaged.

If you still don't believe me when I say I'm going to make sure cover is not OP in this game, well, there's no helping you, mate. You can literally blast campers behind cover now. Naturally, balance is a core concern here, so I'll be looking at things like how much mana it costs, cool-downs on using it, the speed at which it occurs, the damage caused, etc. But I'm very keen on this feature and will definitely enjoy further iterating on and improving it.

I think this adds a pretty big layer of depth to gameplay all by itself too (I haven't even started with the core magical abilities yet!) and I've certainly never seen anything else like it in other multiplayer cover-based TPS games. Let me know if you have, though, I'd be really interested in seeing it in a released game if so.

Visual FX

I also got around to getting some visual FX in the game that need to be there so the player knows what the heck is going on. Probably nobody has noticed, but in some of my previous videos, I would activate Magic Firing Mode and some cheap little text pops up in the top left saying "MAGIC FIRING MODE TOGGLE 1" or something like that.

Admittedly, it breaks my heart to take out the charming little debug messages, but it's not exactly an effective way of telling whether you've changed modes or not. So, instead...

...can you tell you're in Magic Firing Mode yet? Wait, you're colorblind? No worries, there's a sound effect too LMAO.

So yes, I added an effect to show the transition between default and magic firing modes. I'm actually kind of proud of it for a quick prototype; it was one of those things where you just derp around with the material editor adding scalar parameters everywhere until you find one that you can crank up to 500 and it looks cool.

You can switch pretty much any time... idle, vaulting, moving out of cover, rolling, aiming... the only time you can't toggle modes is while switching weapons. And vice versa, you can't switch weapons while toggling modes. I might still change my mind on that design choice depending on how things seem to balance out in the end, though.

I also added an effect that I've been wanting to make since the dawn of being able to switch weapons, because it annoyed the crap out of me when I switched weapons and the gun just kind of disappeared and then reappeared in the holster. This effect was made with some help from the fine fellow who runs the "UnrealCG" Youtube channel, so a shout-out to him. Basically exactly what I needed for a prototype:

In case you hadn't already noticed, the character never unequips her weapon. That was a design decision made loooong before I ever started coding anything; quick weapon-switching was something I wanted, so rather than awkwardly have the character unequip and then equip another weapon at mach speed, I figured, "Hey, this game revolves around magical girls, right... why not just use magic?"

And there you have it. The logic flow is basically: Detach the equipped weapon from the character -> use the material to "dissolve" it -> play the appropriate "equip" animation -> attach the detached weapon to the holster -> use the material to "undissolve" it.

Here's an example of it while the character is in motion as well:

So much better, man. I'm just glad the weapons aren't popping in and out of existence anymore...

Shooting Over Cover

Last week, I mentioned that one of the things I wanted to get working was shooting over cover more, so I've done that as well. The solution was much simpler than I'd anticipated; the initial problem was just that my low cover was not low enough. I literally just lowered the default height and adjusted the cover animations to match, and the results are as you can see below...

Much better than before! In addition, I also changed the shooting logic so that projectiles always fire from center-screen while in cover. That way there will never be a situation where a player hits the top of cover while the crosshair is aiming over it :)

Conclusion

I'm actually glad I tackled some of these more "cosmetic" things, because they play such a huge role in the rest of the game. It forces you to think about things like...

-> "How long does it take to switch firing modes?"

-> "Is the player being given enough visual feedback to react to things in a fast-paced game?"

-> "How do cosmetic appearances affect gameplay? For example, if a player switches to Magic Firing Mode, and the weapon texture is really bright and emissive, maybe other players can spot you behind cover simply because of your glowing weapons!"

And so on. Now, looking to next week, I'm going to avoid trying to write specific plans for the upcoming weeks (something I tried to do for the first time in the previous DevLog) and instead I'll just give myself some general pointers. I'm in a good place right now to jump right into a whole host of different areas, from networking, to menus, to dialing in movement, to developing other weapons. But there are two major things I'd like to get started before anything else: The Magic System and Networking (not replication, just getting multiple players connected via the Internet to a match).

For the next week, I think my main focus will be the Magic System... I'd really like to get a basic structure in code for how I'm going to store magic abilities, what information will be needed to execute different abilities in-game, and how the replication will be handled. This one could take a while to get going since I want to spend a lot of time just sitting down with a piece of paper (you know, REAL PAPER you can SMELL) and writing out ideas, so I'm going to give myself a little leeway and say my next DevLog could be a week or two weeks from now.

Don't worry, I won't fall into the indie developer black hole, I promise. This game is basically an existential necessity for me.

- Flash <3