I'm currently working on a pinball game. Some bug reports have come in about the ball going through flippers. It's not an issue foreign to the Unity forums; and while they've been helpful, I still haven't been able to nail the problem to a releasable level of quality.
I think the best approach to fixing this problem is one that can also benefit the Unity community at the same time. I have a sample project up at http://www.gamieon.com/pinballtest/G...inballTest.zip which is a sandbox to diagnose and fix the problem. I think that when it's fully working, it would be a good project for Unity developers who are interested in making pinball games to look at because it's ready to "play" out of the box.
While I'll focus the QA discussion at http://forum.unity3d.com/threads/851...inball+flipper ... what's the best way to go about putting up this kind of project for Unity developers to download and benefit from? And how should it be packaged?
if using physics are you performing changes in the fixedupdate loop? I ask because on different machines you'll get different physics if you don't.
Yes sir. The code is basically laid out like:
Do everything that VelocityLimiter.js does in FixedUpdate
Do everything that DontGoThroughThings.js does in FixedUpdate
If the ball is falling, detect if it's in range of each flipper, and if so, cast a ray from the center of the ball in the backwards direction...if the ray touches the upper edge of the flipper, that means the ball somehow got directly behind it. In that case, the ball velocity is reversed and amplified to go back up and away from the flipper. (This works pretty well 90% of the time)
For what it's worth mentioning, the Fixed Timestep is set to 0.015. On an iPhone 3GS, the average physx time usage in my game when the ball is at rest and eight enemies are bouncing on the screen is about 3.5.
is there a reason you're not simply using continous dynamic options? these remove the need for raycasts and things can't possibly fly past each other due to the fact the physics engine is using a sweep test.
No...I've honestly never used anything outside Discrete. You just made a huge light bulb appear over my head. From the docs:
Use continuous collision detection against objects set to Continuous and Continuous Dynamic Collision. It will also use continuous collision detection against static MeshColliders (without a rigidbody). For all other colliders it uses discreet collision detection. Used for fast moving objects
So...I set the flippers and ball to continuous collision detection and leave all else alone?
I tried to reproduce the problem you described. It appeared once in 10 tries.
After applying Hippocoder's suggestion I tried many times to reproduce it ( over 30 ), in some of which I changed the Max Velocity of the ball to 600. I think it is solved now.
Thanks for the project.
Awesome! I've also observed the same on my iPhone 3GS...and I knew there were moments where it surely would have fallen through in the past.
I need to update the sample project to have continuous dynamic collisions just in case someone links it from elsewhere and no mention of it is made.
Hello, I like pinballs, and I would like to thank you a lot for providing us with this example.
I have been searching for a project like this for months, since I would like to make my own pinball game, and I also want to learn unity3d (I'm starting at it)
Googling I have found some simple unity3d pinball projects, but none as good as this one as a starting point.
This other one looked quite nice and complete, but it seems that the source code became unavailable when the developer's domain expired, and he does not longer participate in the forum.
In my case, activating continuous dynamic collisions has improved collision detection, but mistakes still happen from time to time, specially is ball velocity is increased (for example to 350) to make the ball movement more fast and real.
I don't understand why that does not happen to you when increasing the speed to 600, Ippokratis. With not so high speed I easily get the ball out of bounds since it does not even collide with upper and side playfield walls.
So leaving active the other functions (like the DontGoThroughThings you described previously) is still useful to have less wrong "non collision" events, but they still happen sometimes. The pity is that the fixing function that corrects the ball's speed direction when it is under the flippers without collision having been detected introduces some gaming artifacts for the player, since collision is not detected exactly at the time it should.
I have noticed also that the behaviour of the tips of the flippers is sometimes unreal, I don't know if putting a more accurate collider geometry instead of a box (if it is a box, i'm not sure) could improve that.
Will you upload the updated version with continuous dynamic already activated?
I think I have activated it right, but I would like to test it, specially if you don't suffer collision problems anymore.
Last edited by mokitochan; 07-13-2011 at 04:38 PM.
Have you tweaked this too ?For what it's worth mentioning, the Fixed Timestep is set to 0.015
Thanks for the project!
The present version should have continuous dynamic collisions. To verify, you can select either flipper and look at its rigidbody properties.
The statement about the flipper tip behavior is accurate. The flippers use box colliders. You'll even notice the boxes extend past the tips just a little bit...I did that a long time ago (before continuous collisions) because the ball kept going through the flipper tips. I'm still wary about it.
I tweaked the timestep to 0.015 a couple weeks before I learned about continuous collisions. It may have helped slightly but it's purely anecdotal...I honestly forgot the default value I started with.
Lastly, I discovered an issue where in my game (not this simulation), the ball can be pushed -into- the walls in exactly the right fast-paced conditions! I worked around the problem by adding code into the ball script that detects whether the ball has been stationary above flipper level for more than 8 seconds; and if so, it just destroys the ball and puts a new one back in the launcher.
There are some things regarding physics that are worth to mention. I am not sure if everybody is aware of them, I was not.
1. Gravity is acceleration, not velocity.
2. Non - moving objects with colliders should have rigidbodies.
3. Moving objects should be put in motion via forces, not Transform directly.
4. If any of 2 and 3 is not applied, physics engine gives a performance hit.
5. To have moving objects via Transform with colliders it is reported that one should implement his own collision system. I have no idea how this can be made.
@Gamieon : It seems that now the zip is not available.
The link at http://www.gamieon.com/pinballtest/G...inballTest.zip ? I just tested it and it works for me...
I hope that you have not misinterpreted me. I am not complaining. I just say that for some reason I cannot download the zip or connect to your web site. This is odd, considering that I tried again 47 minutes after your answer. So either it has to do with your site, or with something else I cannot define.
Try this link. I just downloaded the zip and put it in dropbox...I hope that you have not misinterpreted me. I am not complaining. I just say that for some reason I cannot download the zip or connect to your web site. This is odd, considering that I tried again 47 minutes after your answer. So either it has to do with your site, or with something else I cannot define.
Seems I'm late to the party. Can anybody post the sample file or is it off-limits now?
My bad -- I have the zip file back up on http://www.gamieon.com/pinballtest/G...inballTest.zip .
I also mirrored it at http://www.cycles3d.com/GamieonPinballTest.zip
I can't stand it when a thread has a broken link to a file!