I will do some gun, projectile and general gun play improvements. These aren’t technically needed for a prototype, but these are crucial for the actual experience of the game and to show what the game’s presentation is going for. A lot of my reasoning for adding and polishing up (read: over-complicating) such features is the fact that the game is pretty much all gameplay. There is no story, no amazing art, no premium music, etc. And I have to focus on my own strengths and that’s programming.

Something simple first: I need to limit the distance the projectiles can travel:

This is important mainly because I can’t have the player shoot enemies across the map. I also can’t have enemy bullets follow the player forever. This also makes guns like shotguns not effective at long range, which is the whole point of them — force close quarter combat. I also added a slight randomness to this, as it’s pretty obvious for multi-projectile guns like shotguns that all the projectiles traveled the exact same distance:

Speaking of projectile impacts, I made my projectiles push enemies when they hit them:

(Man, is it hard to capture a GIF of something so arbitrary! Enemy AI wanting to flank and swarm me isn’t making it easy either. And my new moving aim camera isn’t making positioning easy…)

Technically, this is projectiles imparting a requested force onto the mob. This is a “soft force” in that it applies over several frames and loses strength over time. This is similar to movement, which is technically similar “soft movement” applied over multiple frames. This is in contrast to “hard force” which walls exert of entities and is unconditionally performed on the immediate frame. Technically, any entity can receive this force and this paves the way for explosions and such. For now it’s part of projectiles.

For this I have properties — projectile force strength and mob mass. And it’s pretty much what it sounds like. Shotgun pellet would push enemies much more than a pistol bullet. And big enemies get pushed around less.

And it feels really good to close-range shotgun a few enemies and see them scattered.

This was definitively missing from my combat. It’s very satisfying to see your shots have a tangible impact (har har) on the enemies. It makes the weapons feel powerful. It makes the enemies not feel like target practice dummies.

I also want the weapons to have a physical kick, that is, firing a shotgun physically pushes the player back. In other words, if a shotgun blast can send the enemies flying, how come the player stands there fixed to the floor when firing it? While this isn’t something where I need realism, I think it’s something you miss once you first notice the lack of it (like playing another game that does do this). So here we go:

The kick here is pretty subtle unless the player has a gun with a single strong kick, like a shotgun. But it’s another point of feedback that telegraphs that “guns are epic”.

While I’m improving weapons, I should make the projectile actually spawn where the weapon barrel is. This has several gotchas to it. For example, it would help if my projectile sprites were actually centered and pivoted… This also means that that weapon being flipped has to be tracked internally and not just for visual purposes, otherwise this happens:

The weapon is still “facing right”, as there is a small error margin before it flips. My visual weapon barrel/muzzle location is also not the same as the projectile exit world coordinate. And the two do not have a 1:1 proportion either due to the tilted camera and weapon holding vertical offset difference. I have to add an additional vertical-only offset when the angle near vertical:

Which solves the two scenarios (blue: center line; green: expected line):


I mean, the difference here is a few pixels for this particular gun. And it’s a lot of work for something that nobody will notice until it’s broken.

A big question is how many weapons the player can carry. Currently, the number is one, which feels insufficient. It doesn’t provide any emergent gameplay where the player could use a better weapon for a different situation. So I definitely want the player to carry multiple weapons. On the other hand, this is a simple game and I don’t want to complicate it with too many choices and a needing an inventory system or whatnot. So I think I will settle for two weapons: primary active one and secondary stowed one.

So here are the new scenarios given three weapons:

As before, picking up a weapon, will equip it:

Picking a second weapon will stow the current weapon and equip the newly picked-up weapon:

At this point the player can swap weapons (stowed <-> active):

Dropping a weapon with will drop the active weapon and equip the stowed weapon as the active one:

If the player picks up a new weapon while already carrying two weapons, they will replace their active weapon (stowed weapon remains as is):

I think this should be sufficient and familiar enough for a typical two-weapon gameplay setup with a quick-swap button. It looks ugly at the moment with my sprites, but so does everything for now.

I also want the player to drop their weapon somewhat nicer than it happens now. I am also using the same sprites for equipped and dropped weapons, so it can get a bit confusing with many items around. So I want to drop the weapon next to the player and slide it a little bit:

Thankfully, all my items are under the same framework as mobs and stuff, so doing this is easy enough:

Again, it’s subtle, but it adds to the whole “player quickly threw the weapon” feeling of a fairly fast-paced game.

Now is a good time to add proper collision resolution for entities, such that it works well with dropping weapons:

This ensures that dropped weapons don’t overlap and the player can unambiguously pick up the one they are closest to. I am doing a 50/50 split between soft and hard collisions when things overlap. This makes the mob and player/mob collisions more elastic but up to a point. This prevents mobs from just running through other mobs without any sort of resistance.

Now, I am dropping the weapon without rotation and there’s a jarring jump between the held and “normal” rotation. Since these are entities, I can easily specify their angle:

Except.. yeah. The player is holding the item “flipped”, but entities don’t understand this concept yet. In fact, I need to introduce a subclass of movable entities that have a flipped flag, so I can spawn my items (and any other entities like this) with this flag set and the world object can then flip the sprite. And this work fine (I already know when the held weapon is “flipped”):

And now I (accidentally) implemented something I can use for the player and enemies — facing direction (the player text and arrow are flipped):

There is one final thing I want to implement and that is angular momentum, which I will simply call rotation speed. I have the angle I keep for all entities but no way to modify it easily. So then I can do a final touch to dropping weapons:

Basically, the player tries to drop the weapons properly aligned. And it happens “naturally” as the dropped weapon is angled the same as the weapon, but is spun instead in the direction it should face with sufficient force. Of course, explosions or some other stuff could easily re-rotate them, but that’s perfectly fine.

And for completeness sake, let’s add this to the chest opening:

I will likely expand this further when I have chest with more items or just different chest mechanics.

In summary, all of this makes weapon interactions more fluid, provides feedback, and just generally makes the game more alive.

Related Posts

MicroRogue DevDiary #26 – Weapon features
Tagged on:             

Leave a Reply

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