(feat) Realistic ball spin calculation

[yusitnikov]

Hello :)

This PR contains a feature of realistic ball spin (aka angular velocity) re-calculation on ball-blob collision.

The following factors are being taken into consideration:

• The difference of the ball speed before and after the collision (so, if the ball speed changed, then this energy transfers into the spin).
• The blob speed (friction of the blob against the ball translates into the spin).

The following factors are not being taken into consideration:

• Ball spin before the collision.
• Ball collisions with other surfaces (walls, net, ground).

Known issues:

• When watching replay files that were recorded in the previous versions of the app, the ball spin is weird (I'm not sure how to get over this issue without overcomplicating the code with things like engine versions).

You can see the result in action in slow motion here: https://www.youtube.com/watch?v=J5xxgm7GFIg

[danielknobe]

Hello yusitnikov, thank you very much for this really cool feature pull request with this detailed description. I have tested it and it works quite nice, but it is not yet ready for a merge into master. The known issue you described and the strange look and feel when the ball hits the ground (not the wall/net) are the show stoppers.

[yusitnikov]

Ground collision - fixed. Try experimenting with BALL_GROUND_COLLISION_SPIN_COEFFICIENT constant if you think that it still looks bad.

Old replays - fixed. That's how it goes:

• I introduced versioning for DuelMatch and PhysicWorld classes.
• Replay file format was extended with "engine_version" var - it's the version of the DuelMatch class to play this game.
• All other places in the code are always using the last DuelMatch version.
• DuelMatch initializer is responsible to load proper version of the PhysicWorld class.

I'm not that happy for this code overcomplication, but I hope that it could be useful in the future if you would want to modify the game engine further and keep old replays under control - just declare the code that you're going to change as virtual, create new class versions and override the behavior in the new version without affecting the previous engine.

[yusitnikov]

@danielknobe , did you have a chance to review the fixes?

[danielknobe]

Thank you for the latest changes. I will review the patches as soon as possible. Unfortunately I have very little time at the moment.

[danielknobe]

@yusitnikov: Many thanks for the current pull request! I finally looked at the code. I think it is very good, but I think that dfbf17b, as you said before, is not good for the code readability. I also couldn't reproduce the problem with the old replays. What exactly is the technical reason for the ball spin is weird when using old files in the new engine? Maybe it makes sense to accept this in doubt, since the current replay format is new and has never been used in a release.

[yusitnikov]

The technical reason for the weird ball spin in replays in that the replays have many "savepoints" of the game state (which includes ball rotation and angular speed). So, in the beginning of the match the ball spin is OK since it's just calculated to the new rules. But, starting from the first savepoint, the angular spin from the spin overrides the "realistic" ball spin and all further spin is calculated wrong because of the initial value.

[danielknobe]

Thanks for the hint. Blobby Volley 1.0 still had a pure binary format for the replays. So at least for the first use of the XML format a versioning can be omitted. If you could remove the commit dfbf17b from the PR, I would do the merge. dfbf17b can then be used if necessary for a later change. If you wish, you can include the small refactoring changes (eg resetBallAngularVelocity), except for versioning, in the PR.

Thank you very much for this feature.