I am building a game using Paper2D. During this game a ball (UPaperSpriteComponent ) is launched via a call to AddForce(), this object has simulate physics on to control its movement, the ball sprites collision is reprisented by a circle, at some point this ball will collide with a wall, essentially, a rectangle.
During PIE this all works fine, no matter how much force I give the ball there never seems to be issues, however as soon as I launch a standalone game, either via “Play Standalone Game”, “Launch Windows” or deploying to an android device I have issue with the ball tunneling into the walls at relatively small velocities and getting stuck.
Has anyone experienced this behavior, does anyone have any advice where I should begin looking to fix it?
So I have not looked into it myself, and I am not sure if the AddForce() function is supposed to work with 2D physics. With that said, I will do some testing to get a better understanding of physics in paper 2D can be controlled and return with more information.
In the meantime, I did find some helpful 2D Physics documentation that might give you some hints as to why your ball object could be behaving the way you are reporting.
Applying Paper 2D Physics
I think the main thing to get from this is to make sure you have applied constraints so it does not leave the level. Let me know if you have further questions.
Thanks for the reply, in response I have setup the constraints correctly, and also ensured that all objects are within the correct “y depth” for collision. As I say, all works fine in PIE, these issues are only occurring in standalone.
Would you mind providing me some simple steps to reproduce this issue in a new blank paper 2D project?
If possible, some screenshots of your blueprint and how you are calling the sprite to respond to the ApplyForce() function would be helpful in resolving the issue quickly.
I have made you a simple demo project that shows the issue. If you open this project (Make sure the level is DemoMap), then run the game and press “space bar” the ball will launch upwards. In PIE the ball will always bounce off the ceiling, if you choose play standalone it way take a couple of tries but eventually the ball will either tunnel clean through the ceiling or get stuck in it.
Viewing the issue outside of my game I have noticed one thing, the call to add force on the ball is giving different results in PIE / Standalone, in standalone the same call applies much more force. I tried ramping up the force being applied 10x and the issue is also reproducible in PIE.
Therefore there seems to be two issues:
Add force is providing more force in standalone than PIE, potentially a frame rate issue?
Sprites are able to tunnel through each other quite easily at not massive velocity.
So I took a look at your project and attempted to open up the C++ block of code, since that is where you have established the variable.
After doing some testing, I noticed that not changing the variables value and instead modifying the frame rate via the Project Settings can get the issue to occur.
Since you are using event tick to apply your physical force and defining your variable there within code the force applied on per frame is gong to be different. If your game is not at a fixed frame rate, which the default behavior is using the ‘Smooth Framerate’ option, this is why you are seeing this issue.
Open up your project settings and within the ‘General Settings’ and within the ‘Framerate’ section check the ‘Use Fixed Frame Rate’ and set it to 60. You will either want to keep a set frame rate, or change how you are applying your physics i.e not on tick.
Thanks for pointing out that the frame rate is not clamped by default, however I am not sure what you mean by “change how you are applying your physics i.e not on tick.”
I am calling “AddForce” from an input event, therefore its a one-shot event and should be frame-rate independent? It appears that the effects of the same force being applied to an object differs at different frame-rates, is that what you would expect?
I can lock-framerate and balance it which should solve the issue, however I am interested for future reference.
