I’ll warn you that I’m a relative novice to Blueprint and programming in general so please bear with me if the solution is something obvious, because I’ve done a lot of research and tried every solution that seems to apply to what I’m doing and I’m stumped.
I’m working on a Dodge Ball-inspired arena game and I’m trying to make a ball that will move faster every time it bounces off a wall. Once the player throws it, The ball isn’t affected by gravity, so it’ll only ever need to hit the walls and not the floor. I’ve tried a few different methods for this, and each one has its own issues that I’m not quite sure how to overcome.
The simplest method that got the best initial results was using projectile movement and setting the bounciness to a value higher than 1, but since the game takes place on a rectangular stage, the ball will inevitably get stuck bouncing between two parallel walls. From there, the only thing that affects the ball’s movement at all is altering the projectile movement velocity but that always seems to make the ball come to a complete stop or move perpendicular, which then starts the same problem over, just from a different direction.
I’ve also tried using a physics object and doing the speed up/redirection via impulse. This has had extremely mixed results. Sometimes it seems to be working, but other times it doesn’t speed up on impact at all, and when it does speed up, it will often vanish once it hits a certain speed. I’m not quite sure what it is, but I know it’s much lower than the max speed I had set in the projectile movement version.
I’m assuming in each case that I have a poor grasp on how to alter an object’s velocity in the way that I want, so that might be the best starting point.
hi man, i would suggest you to blueprint it yourself
create an actor with a sphere and move the actor with 2 variables speed and direction.
the arena is simple so you can do the “collision” with the walls using just math.
if the actor location x is too great or low he leaved the “Square” horizontally, location y too great or low, leaved the “Square” vertically
so you can fix his position on the wall, and change his direction and increase the speed
Really great speeds could exit the square in one frame so instead of casting rays every time you can just check
if the vector , direction*speed will result in the leaving of the square and thus fix the position before setting the actor location.
Having it in your hand completely you can script the “Curved” throw too, or the “spinning hit”, that makes the ball bounce differently.
These stuff could be really hard to make in simulated physics
Plus you could deform the ball for giving the speed visual effect, like in a cartoon.
Thanks for the idea. I’m not sure how to make that happen but it sounds a lot better than the thing I actually came up with, so I might try and do that after I finish programming the other necessary gameplay elements.
If anyone stumbles across this and wonders what I did, I basically did some research and tests to confirm how velocity is calculated, then made a rough calculation that basically goes: if Y = 900 and X = 0, subtract a random amount from Y and add it to X. It’s not Great but it usually creates a new velocity that’s close to the original, and once you add the bounciness back in it speeds up either way so it’s not super noticeable. It’s painfully obvious when the ball gets stuck in a parallel and changes direction this way, but the important thing is it redirects and keeps the game moving. And as you can see from the blueprint example yes it uses the projectile movement version.
you’ll always get stuck between parallel walls if using physics.
to prevent it you would have to script something to determine if you are stuck and why (line trace results), and use the values you found to get the object unstuck.
The easier approach would be to bind the object to a fixed cardinality x y or z so that it can only travel on that specific plane.
you vould tie this behaviour to entering a trigger or volume for instance.
… it may get stuck later, though - who knows. Still bouncing here for now. But the physics will fail eventually at very high speeds. At which point you will need to enable CCD and up the solvers in the advanced physics settings.
Yeah this is why I ended up abandoning the physics version pretty quickly. It became clear that there wasn’t a great solution for when things got too fast, and it could never go nearly as fast as the projectile, or even a simple actor being propelled forward with no physics. Right now I’m using the projectile movement one with that rough formula as a placeholder until I find a way to refine said formula or replace it with a simple linear movement that runs my own calculations every time.
The thing with increasing solvers is that not necessarily everyone can. It depends on the target platform and what that CPU can handle…
In my opinion it would be easier to script an FPS independent system with a simple bounce mechanic (newtonian perhaps? Avoiding gravity if possible) if the goal is to get ObjectX to bounce really fast somewhat randomly across the level.
Also, as far as my tests go, even with substep basic overlap events start to fail at the equivalent of around 370KPH
Well the ball isn’t gonna get INFINITELY faster, I’ve got it capped off at something like 6000 right now in the Projectile settings (Fastest it could go where I could still easily visually track it, may make it faster if some Hardcore Gamers TM test it and can handle higher speeds). I’ll have to test Everyone’s solution on my device and then some lower-end ones to see how it holds up, but if it works it works.
Don’t then. I set them back to defaults and it behaves fine. You do need CCD for high velocities, though. You* definitely do not need* it for 6000. And you absolutely do need CCD at velocities MostHost LA mentioned. Or, if you’re crafty enough, reinvent the aforementioned wheel.
[HR][/HR]
I also replaced the *Set Linear Velocity *(what was I thinking!?) with Add Impulse. With the restitution of 1, friction of 0 and no linear damping, there is no energy loss. Admittedly, you still do get an odd angle every now and then. I remember helping someone roll coins *realistically *on various physical surfaces and the key there was to create a much better simplified collision. Although I’m not certain whether that’d make sense with spheres.
I have now made a small game out of this, with many balls in the pit. Sadly, it’s not fun.
Do tell if the suggested method is applicable in your case and/or produces better/worse results. I believe it’s worth looking into at least.
I’m starting to work with this and I just have one question - when you say “Stuck,” you are not referring to the ball getting physically caught inside the wall, unable to move, right? Because I mean that the ball is caught bouncing between the same two points on parallel walls.
I’m trying the solution you presented, and it doesn’t seem to stop that from happening.
I meant the parallel walls, not the intersecting geometry. It does not seem to manifest on my end. I even tested it by launching the ball at a 89 degree angle and had it cover the pit several times, maintaining that angle. I can imagine that it could still happen, I did not observe it though.
After trying several different methods for clamping velocity, I settled for this. Do note that the MapRange is *unclamped *here, velocities below 5000 result in *negative *damping values - they’re accelerated; velocities above 5000 are slowed down. While this system maintains energy (restitution 0) on its own, you may opt to add / remove some via player’s actions or additional impulses.
The above will maintain the 5000 cap quite efficiently and, most importantly, without any sudden changes in velocity. The simulation is allowed to exceed the cap only briefly and is quickly slowed down / brought up to speed. And it can be parametrised for each actor easily.
Yeah, my physics material looks like yours. As far as I can tell I have mine setup the same way yours is in your example (and a speed limit but anyway)
Not sure if I follow. You fire it straight, so it bounces straight back. What else would you expect here? Are you saying the forward vector is not 1,0,0?
That’s been the issue the whole time. It’s the thing I’d like to stop from happening. Honestly, though, putting a clamp on the rough formula I made for the projectile movement version of the ball might just be what it needs to work 100% of the time.
I really do not understand. In your video, it seems to work fine. Why would it bounce in any other way? Fire it at an angle and it will bounce at a mirrored angle… Fire it straight, it bounces straight back. You fire it straight…
Take a ball and drop it on the floor, it will come back up, right? What am I not seeing here?
The issue isn’t with physics not behaving properly, the issue was that I wanted to change the behavior, so that it DOESN’T do what it’s doing in the video I sent you, because in a hypothetically fast-paced dodgeball arena game, nothing would kill the excitement more than clearly seeing that the object that does the damage is no threat to you or your opponent if you can wait it out long enough. If it gets stuck like that in a live game, it’ll immediately grind the action to a halt. I was hoping for advice to edit the physics or projectile movement to redirect it when that happens. MostHostLA was closer to the answer, although I’d already figured out that much. I was more looking for advice on how to handle the redirect than how to determine if I needed it.
But anyway, someone else on my team had a fun idea that I’m working with now, which is to use Projectile Homing to make the bounce redirect to the nearest player for a spit second when it gets stuck. I’ve already started work on that and so far so good. It’s barely noticeable at max speed, which is where it mostly gets stuck anyway, so I think I’m gonna focus on refining that for now. I’ll share a screenshot of my code once I’m happy with it!
I see that I completely misunderstood your issue. I thought you had a problem with the default physics reverting to right angles after hitting a surface - because *it is a major problem *without the physical material.
In this case, I’d just adjust the angle on the bounce by rotating the vector a bit after checking the dot product for an undesired result.
