Great solution! Many other solutions seem to return -0 but not this one.

While an interesting demonstration of SOLID, your stated goal to "make it more understandable, flexible, and maintainable" is exactly the opposite of what you mananged to accomplish. Classic case of over-engineering, and OOP run amok. But, I'm sure you know that.

good lord why is it so long @_@

This has nothing to do with "Best Practices"!

"Short"? Definitely, but only because this game is not very complex.
"Understandable"? Sure, but again only because this game is not very complex.
"Clever"? Maybe, if you need to programm it on a whiteboard with limited space.

This is just a tiny game with a few rules, but lets imagine you are at work and this should be the base to further development on that game.

1. What if you want to add one or even many more new rules?
   It doesn't matter what the new rule is.
   At first a new rule is maybe somewhat easy to add, but with more and complex rules this will evolve into a nightmare.
   And don't even think about adding stuff like another player.

2. What if you want to monitor aspects of the game?
   I. e. you want to log the position of the player every time she makes a move. Maybe before and after. Or just if someone steps on a ladder.
   Maybe you can already imagine how much code would be needed in this single method ONLY for logging. This would very fast become very complex and confusing (and fragil).

I am very aware that this is just a solution for a kata.
And this sulotion is NOT BAD. It works after all. This is not a critic about the solution!
I just can not see why this is the solution with the most "Best Practices" upvotes, essentially learning (new) programmers that short and clever(?) is the best way for any solution.

I would not want to work with someone who genuinely thinks that something like this is best practice.