Time to add some more new weapons… or work towards it. My rocket launcher was supposed to be one of many and it took way too long to implement all the details. So how about a simple minigun:

I will talk about weapon (archtype) design later. First, there a bunch of inevitable extras I need to do.

My weapon visual properties are getting out of hand. There is one big problem with projectiles and effects in that they don’t match their “elevation”. That is, all sprites are on the ground and when I spawn things in relation to other things, they will either be on the ground, or I need to “cheat” and manually move their world coordinate up/down. But I am changing their coordinate, not their elevation, which makes all sorts of weird misalignments happen. This is what happens with weapons firing — since the weapon barrel is not the same level as the player is, the projectile needs to be offset vertically. And changing such one specified value just breaks all the others. I don’t like this, so I am just going to add an elevation value to all my entities. This way I can spawn a projectile that is on the same “ground” as the player, but elevated, similar to effects.

A mob carrying a weapon then needs to have 2 offset or 4 values (green — weapon horizontal carry offset and vertical hold offset; blue — projectile horizontal spawn offset and vertical spawn elevation):

This seems like a much cleaner way to do things. Then my weapon properties for aligning everything are also simpler:

This works both for projectile and muzzle flash and I don’t need another offset for muzzle flash.

This is simpler, but not that simple. Currently, setting up weapon visual stuff is one of the finickiest things I will need to do. I need to change properties, like projectile offset, by a tiny amount and then fire the weapon in-game, hoping I didn’t mess up my test scenario. This is so annoying, that I made an editor preview for my values:

And to preview fire kick distance:

This makes my iteration and adjustments super-fast, especially when I change the sprite.

Okay, time for another gruelingly complicated problem. It’s a similar kind of problem as with effects in that I fire more than one bullet per frame. So something like this:

is actually multiple bullets spawned right on top of each other. And, depending on the framerate, they will appear differently spaced-out. This is definitely not acceptable. So I need to space them out further from the barrel as if I had fired them earlier. Unlike the effects which spawn behind the effect bundle, projectiles have to travel forwards, and I can’t just teleport them forward — I need to request an additional time simulated when they next run, so they can move further while properly checking collisions. Not a simple task and this took me way, way too long to do, but it now works fine for the most part. Another issue is that projectiles want to immediately travel on their frame, which causes a visual gap when they are fired:

I can fix that easily though and move on to the bigger visual problem of having projectiles spaced out when the player changes their aim:

And this does makes sense in terms of how it is implemented and timed. For example, during frame #1 the player was facing 5° and during frame #2 they were facing 6°. Technically, at no point was the player facing anything between 5° and 6°, no matter how much extra time each bullet simulated. So I also need to interpolate the angle between the frames:

And this solves it nicely. But yet another issue is that the player’s movement is not accounted for. If they, for example, move back, then small gaps corresponding to player’s movement appear:

This is because I assume all my projectiles are fired from the same location (weapon’s barrel), which isn’t visually true if the player was supposedly moving between the frames. So I need to interpolate the player’s movement between the frames and add that to the bullet spawning offset as well:

And finally this works. This example is a very extreme one with values set stupid-high just so I can test how it handles. And, if it handles this even remotely well, then it will do for normal weapons just fine.

The last problem is that the bullet spread is a bit too random — the “recoil” is completely random within its acceptable arc. It looks dumb. And speaking of recoil, it’s just a little bit too finicky adjusting so many variables. And since I don’t really have any good visual debug to see how my smaller numbers affect things, I don’t want too many of them. So may be I can change how it works and solve both these issues.

The player perceives such weapon fire properties via time. The biggest problem designing is “converting” various numbers to time. So I will just specify the actual time instead for bullet spread “timed” values:

This makes the code slightly more complex as I need to track time across different firing states instead of just multiplying a couple values. But it’s worth it in order to express the options much clearer.

Anyway, my “add another weapon” task extended into “fix 20 other issues” again. I’m getting anxious spending so much time on these, but oh well.

MicroRogue DevDiary #44 – Weapon improvements
Tagged on:     

Leave a Reply

Your email address will not be published. Required fields are marked *