Restructure allowed moves

[philsupertramp]

Current approach is by far not suitable and impossible to maintain. We need to change the strucute how we handle allowed moves to enable a few things. We want to be able to enable

• [ ] #8
• [x] #9
• [x] #10

• [x] #11

  Hence we need to find a simple structure how to represent that.

Ideas

• field mask computed on the fly
• initially pre compute all moves, then compute changed fields on thy fly
  • this won't work, how would we determine passively free'd figures?
• specific lambda callbacks for each figure type

Lets implement for now a simple debugging tool to display the "move" on selection

1. If figure is selected, watch mouse cursor and display distance between origin field and current field underneath cursor.
2. Validate cursor position and highlight text red if move is not allowed
3. On selection display available moves by highlighting available fields
4. Profit?

Hope it's not too small slow tho :shrug:

[philsupertramp]

So once again I hit a road block. It becomes more and more complex to define extraordinary moves like Pawn's en passant, or King's castling.

• [x] From now on moves will be handled with the board state, so we keep this in sync and have it in the same way. Therefor the board needs to tell the game what's going on.

• [x] I will extract move-logic into the subclass Movable in file movable.py to centralise this delicate piece, then inherit in Figure.

  • [x] There will be a more descriptive API to define en-passant and castling

• [ ] Introduction of Move a callback-like to test for allowance

  • [x] Figures can implement their own rules if needed

It sounds overambitious but I'm super positive that this abstraction will improve the readability and maintainability of the code base.

[philsupertramp]

Looks good to me, tbh. Closing. Can be reopened if needed!