Time to work on some gameplay stuff, so I added a projectile framework following the same logic as tiles, mobs, items and props. I feel like I’m still glossing over this a lot. Here’s the rough schematic of how things relate to each other:

Projectile is the class for these bad boys, doing their own things. Projectiles is where they all live and are controlled from. And World is where everyone (items, props, etc.) lives. Each projectile has its world object that appears in the game scene and is rendered, which used one of the projectile definitions, which is a bunch of properties projectiles can share, such as sprites. All of these derive from Entity parent classes for organization. Similarly, all other entities–tiles, mob, props, items–follow the same pipeline. So it’s all quite modular, reusable and shares common functionality.

Now, let’s make the player “fire” a bullet whenever mouse is clicked (and they have a weapon equipped):

Okay, the bullets don’t actually do anything besides sitting there (I moved the player myself). In fact, before I can point them anywhere, I need to translate the mouse click into the world click to know what angle to shoot the bullet. This would be simple with pure 2D, but my camera is in perspective and slanted, so I will use some raycasting math against a ground plane. Here’s an example 128 degree angle click:

Fascinating! And now that I have fancy math for angles, I can actually spawn a bullet in that direction (at a constant distance) from the player (without moving):

Some regular and some exasperating Unity maths later:

Now I have to fiddle a bit with the movement logic. I want to reuse player’s movement logic with projectiles. It sounds a little funky that I can use the same logic to “walk” the player as to “fly” the projectile, but fundamentally it’s the same “physics”, so why not.

I also have to fiddle with item logic. Different item types (weapon, armor, scroll, whatever) have different properties, act differently, are (if at all) equipped differently, etc. In the immediate logic, I need a projectile spawn distance from the weapon when firing, and that is weapon-specific.

Now, I only need to actually destroy the projectiles when they hit the wall tiles. Unlike the player, they shouldn’t glide along them (which they happily do). Anyway, here is pew pew happening:

This is click->fire each frame. What I need as properties for weapons is manual vs automatic firing mode and firing rate for weapon. So I implemented that. Not sure how the preview would be different much from the above, so just watch the previous GIF and pretend the fire rate is limited and set to automatic.

Finally, the bullets only hit the walls, since that is what the player “hits”. At this point, I worked a bunch on collision detection and experimented, so I will cover that in the next blog post.

For the purposes of projectiles, the collisions now detect when they hit a mob:

Finally, just need to make the enemies take damage when they get hit. And also visually change (to a different sprite for now):

Here the enemy gets hit for lethal damage, and goes through dying into dead state. (At some point, I’ll work on the whole sprite animation framework that I really want.)

Now I can extend and tweak weapons and projectiles to whatever I want. For example, here’s a shotgun that fires multiple projectiles with a slight spread.

Well, this covers the basics of projectile logic. By attempting to move and collide projectiles, I also extended and implemented a whole lot of other systems that I needed. I will be adding weapons and mechanics and various interactions at a later time. And at some point visuals and feedback, hopefully. This is one of the core game parts, so I will be definitely revisiting guns and bullets multiple times.

Related Posts

MicroRogue DevDiary #8 – Projectiles
Tagged on:             

Leave a Reply

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