Create logic that will allow "en passant" captures

[robstallion]

Create logic that will allow "en passant" captures

[RobStallion]

Notes on logic to check

[RobStallion]

I THINK like to make the state of the Pieces look something like this...

type Piece
    = King KingState
    | Queen PieceState
    | Rook PieceState
    | Knight PieceState
    | Bishop PieceState
    | Pawn PawnState


type alias KingState =
    { team : Team
    , check : Bool
    , doubleCheck : Bool
    }


type alias PieceState =
    { team : Team }


type alias PawnState =
    { team : Team
    , onHomeTile : Bool
    , movedTwoTiles : Bool
    , capableOfEnPassentCap : Bool
    }

I don't know exactly why but this feels like the right approach (or at least a better approach than what I have currently).

At the moment I have a type Piece which is a record that consists of a PieceType(Rook, Queen, etc) and a Team(Black, White).

I have realised that Pieces will need a state of their own. I could probably record this in the overall state, e.g the Model, but this doesn't seem like a good approach.

I think it is easier to reason about each Piece containing its own state.

The problem I am having with this idea is that at the moment I am not sure how to pass Pieces around in the app.

At the moment I am making Tiles that contain a TileStatus and a Maybe Piece...

type alias Tile =
    { status : TileStatus, piece : Maybe Piece }

Before I could easily pass a Piece in as it was a just a record. I am not sure how I would go about passing a Type around the app (especially a Type that has different where the clauses have different types (sorry if this is last part is not clear. Didn't know the correct terms)).

I know that is can be done of course but for some reason it is tripping me up at the moment.

[RobStallion]

https://medium.com/table-xi/union-types-in-elm-fb6a974ec427

[RobStallion]

After thinking about this a little more I think that it is better to just update the overall game state.

One of the things that made me decide to leave this approach was the fact that piece logic will only ever last one move.

For example if a Pawn can be captured en passant it had to have been the last piece to move. There would be no point in recording some logic in all Pawns when one one MAY even have it as an option at any one time.

It's also similar for the King. If a king is in check, then something needs to happen to take it out of check. That check isn't going to follow it around from turn to turn.

Another reason is that having all those 'separate' states increases the chances of error. It could lead to multiple pawns having a state saying that they can be captured en passant for example. Of course I would have tried to minimise errors and could avoid this by 'being thorough' but if there is only the possibility for one pawn to ever have this option then it just completely removes that possibility for error.