Projectiles and ranged attacks

14 replies [Last post]
Posts: 135

Is there code for projectile entities being fired from ranged attacks? I thought this was part of fixing Issue #98, but I noticed the pistol doesn't shoot any bullets and it doesn't look like there's any code in the AttackRanged method or any DB structure related to projectiles.

Or am I not looking in the right places?

Posts: 1691

It doesn't show a projectile, but you can attack from a range with the pistol still. You just have to select a target.

Posts: 135

What are the chances of adding projectile rendering in a future update? I realize it's a non-trivial task, but I think it's something that could be considered more than just a "niche" request. Part of the convention of ranged weapons is having them fire some sort of projectile graphic from the attacker to the attacked. Even if it were just implemented client-side, I think that'd be great. Something along the lines of when you attack with a ranged weapon, the server pushes out to the clients a call for some sort of drawing of a grh originating at the attacker's location and then ending once it reaches the target, then applying the attack logic once the projectile rendering is terminated. The speed of projectile travel could just be an additional field in the item table (along with a field for associating a projectile grh with the ranged weapon).

Please Spodi, please? Smile This has gotta be a lot easier than map instancing or SFML 2.0 support. Smile

Posts: 1691

I'll probably add it at some point.

Posts: 135

Okay, yay! I think it's something I could eventually add, once I get more familiar with C# and the engine, but it would likely be messy and inefficient. And since it's something I'd want to share with the rest of the bunch, eh... I don't want to get laughed at. Smile

Posts: 1691

It falls under the "stuff I want for my own game" category, so it will have to be added at some point. I'm just busy with and annoyed by this update to SFML 2.0 right now. Proving to be much more troublesome than expected. :/

Posts: 135

Sounds like a bear! Well, it's not like I'm on the verge of releasing a game and am just waiting on this one feature. I have a loooong ways to go with content development, graphics, etc, before functionality starts being a bottleneck. Wish I could quit my day job. Tongue

I may make an update or two to the new issue you put up on Google code, if that's okay. Just a couple of implementation ideas to throw out there, depending on how you would like to approach projectiles, mainly a client-side rendering only vs. an instanced entity with collision. The first is a lot easier to implement, but the second would allow for some pretty cool flexibility of the engine.

Posts: 458

I know the engine isnt setout for 2d shooters,

but Bows and the sorts dont shoot too fast, dont they?

1 arrow/second or so should be manageable with collision or?

Arrows that fly in an arc would require aiming skill,
while straight forward bolts from a XBow/Gun would be easier to handle.

Posts: 1691

Zanval, projectiles are just fine. That is, the engine can handle the computation. What the engine isn't built for is twitch-based games. The network can't handle that so well, and its intentional. That is, don't expect it to be as accurate as a real-time shooter. If you shoot someone as they run and it looks like you hit them on your screen, don't be surprised if it just missed them. Real-time shooters pay a lot (in computation and scalability) to be able to give the accuracy that they do. However, this also only takes into account "non-targeting" ranged-based attacking. The implementation NetGore uses by default forces a target, so you'll never miss, making the speed of shots irrelevant. Damage is also instant (as it is with melee attacks) so the projectiles simply provide a little animation.

I'm not sure if I'll be adding delayed damage since its a lot of work for very little gain. I think I'll just leave it up to people to implement it however they want (if they want it).

Posts: 135

If you implement collision-based projectiles, though, then you don't have to worry about the damage delay, since the damage wouldn't be applied until the projectile reaches its target anyway, right? I think collision-based projectiles would be so awesome!

Posts: 1691

Yeah, but not all people want that style. That is why I just went with the easiest and cheapest to implement for the default approach.

Posts: 458

well projectiles and instants are 2 things you "need" when you code spells, latest.

Example: a fireball.

it explodes on impact, or where its aimed to.

so this could be an easy to aim spell, or hit someone while its flying.

Also flying fireballs can light up caves. I love that thought ^^

Posts: 135

Spodi wrote:
Yeah, but not all people want that style. That is why I just went with the easiest and cheapest to implement for the default approach.
Well as long as projectile rendering makes it into the engine at some point, like you said. Smile I realize going with collision-based is a much more complex approach, so if you just implement client-side rendering of the graphics, I understand. I am wondering how to "delay" the attack/damage application until after the graphic has hit the target, in that situation, though. Maybe calculating some sort of time it should take for the projectile to reach the target, and then applying the attack after that? Still a bit complicated, I realize...

Posts: 1691

Projectiles should have a known moving rate on both the server and client, so the server can calculate the time it will take to collide with the target by finding the distance and dividing by the speed of movement. Then you can just push structs onto a list of "time-delayed damages" that get updated each frame. Would probably be the easiest approach.

Posts: 135

Ah, makes total sense. Like I said, I'm so happy you've added it to your issues list because I'd do a really botched job of it myself. Smile

I do still like the idea of effect/attack-on-collision entities for other purposes besides projectiles. But my ideas are probably too specialized for the base engine.