Weapon system.

I’ve seen some people asking around the forum on how to do “real” bullets.
Not the projectile from the 1st person example, and not the instant hit linetrace from the multiplayer shooter example, but “real” bullets with travel time and bullet drop.

So, I’ve gone ahead and made that.

So far, it is just the bullet travel, the drop and some drag applied to the bullet in flight.
The drop is fairly accurate compared to real life, but the drag is a rough calculation for now, a flat 20% drag pr. second.

The slight drop over time. Bullets fired straight up will come straight down again.

The bullet Blueprint right now.

Short demonstration of the current system.

Things I would like to add:

  • Wind effect applied to bullets to make longer shots harder.
  • S-Curve assets for drag.
  • A shooting range to test your weapons.
  • Slow motion shots
  • Recoil(not just animation)

If you like this project, please voice your support for it in the marketplace, I have a link for it below.

Short demo of how to make a weapon

This is awesome! I can send you my SCAR if you need a weapon to test? Since I’m not an animator it doesn’t come with animation. Maybe you can find an animator to keep with that

Here’s my old SCAR(I need to redo it before I can send it to you):

Send me a e-mail if you are interested at naka_256 at hotmail dot com

Sure, I’ll be happy to test you SCAR in my project. I’ve sent you a mail and use this reply as a shameless bump.

I’m curious as to why you are not using the standard projectile movement component?
With a small collision component and a high velocity, it would act the same (minus the air resistance).

I don’t trust Unreal Engine at high speeds. Bullets move very very fast and could potentially move past an object in one tick. A bullet easily moves 1000 units in one tick at 60 FPS. Even further at lower FPS.
I suspect that using PhysX on hundreds of bullets is more taxing on the system than some relatively simple math and line traces.
It’s easier for me to apply drag, wind, altitude and other effects to the bullet if I control everything.

The 2 first reasons are just my own fears, not founded in any testing or insight.

I looked at the documentation, and I found you can enable CCD which is Continuous Collision Detection. This is pretty taxing from what I can read. So my choice not to use seems to be correct. More info is welcome.

Ahh, that is what I was confused me.
You see, the projectile movement component does not PhysX - it uses traces - although they against a component, not a line.
It also devides long ticks into smaller chunks to help create a better curve.

Check out UProjectileMovementComponent::TickComponent() to see what I mean.

Our own bullet movement component is based on UProjectileMovementComponent, with the addition of air resistance and penetration.

I have taken a look at ProjectileMovementComponent and I have chosen not to use it. My “spider sense” is tingling, I think there could be potential performance issues using it with many bullets. I would also lose some control if I chose to switch. I would hand over calculations to the physics engine, and… well, I don’t like that with bullets.

All traces use the physics engine - even tracelines.
As for simulating physics, that isn’t happening.
Look into UProjectileMovementComponent::TickComponent() again:

    if ([UpdatedComponent](>[IsSimulatingPhysics](

If we’re simulating physics, don’t run the code beyond this point.

If you’re talking about MoveUpdatedComponent(), it just calls UpdatedComponent->MoveComponent().
As for MoveComponent(), it uses ComponentSweepMulti().

In the end, aside from a line vs a component trace, your system is essentially the same as this, but done in a Blueprint.
Performance wise, C++ trumps Blueprints and there is nothing stopping you adding air resistance in a Blueprint that uses a ProjectileMovementComponent.

Tomarto/tomeighto :stuck_out_tongue:

What is the performance like with this? Can you do some comparisons between say, 50 instant hits in one tick, 50 projectiles fired at once, and 50 of these at once. Maybe not 50, whatever number makes a difference noticeable. I would love to use an algorithm like this, if its not going to kill frames. Looks great so far, keep up the good work!

I will take a deeper look then.
I thank you for pushing, even if I say no. I want to make the right choice.

I just made a quick test with a minigun type weapon. 6000 shots pr minute. Played in the editor. Unfinished project. Not optimized yet.
Around 1000 bullets in the air before performance began to suffer.

With this test I found a very neat little optimization that I could do, it will make it perform even better after this.

After a small change to the bullet blueprint I can now fire endlessly without having performance issues.
When a bullet goes below 100 meters per second I kill the bullet. At this point the bullets are in an almost vertical drop anyway

It helps us both. It brings to light information we may not have known and makes us question what we’ve already done in the hopes of improving them.

Not a bad thing.

Have the same sort of setup, as well as a limited lifespan.
At the moment, said lifespan always 10 seconds, but I think making it dependant on calibre is better. In this way, low velocity rounds will remove themselves once they are beyond their effective distance, while high velocity rounds will be given ample opportunity to reach their target.

The performance of the standard ProjectileMovementComponent may improve if you replace the MoveComponent() call with single or multi line trace. Not as accurate as giving bullets an actual diameter, but they’re relatively small anyway, so…

So far, our bullets still use MoveComponent(), but we don’t intend to have thousands of rounds flying around in the game :slight_smile:

Are you doing your stuff in C++?
Because that’s sadly not an option for me since I want to put my project on the marketplace.

How do you apply the drag? Do you just multiply the velocity with some smaller factor and then set it again?

Pretty sure you could make it a project like the ShooterGame (which is C++ & Blueprint) or as a C++ plugin.

In the current implementation, drag is applied in C++ function ComputeAcceleration(). This is the same place it applies gravity, so it seemed like the best place for it. A slight velocity change each tick would work and be less expensive, though it would be affected by server frame rates etc. This is why deviding the traces up by a fixed interval over long ticks is a good idea.

It all depends on what is a ‘good enough’ simulation.
This may be something you take into account in your design, by adding options for a fixed or variable rate, depending on whether the user wants accuracy, performance and so on.

Right now they state:
Additional content types such as code plugins will be accepted at a later date, and this document will be updated with additional guidelines to reflect those additions.
So right now it is only pure Blueprint they accept, so I can’t play with C++.

So I am stuck with getting and setting velocity.

Hmm… perhaps using a fixed timer instead of each tick would be warranted then?
Keep it consistent / framerate independent?

Either that or work on a C++ version and hope “a later date” is weeks instead of months :slight_smile:

Shameless bump.

Please vote for this on the Trello Marketplace board

There is a new video, check it out here:

Voted for this to be on the Unreal Market place :smiley:

Thank you, I also have a new update for you.

Please vote for this to see it in the marketplace