Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create logic that will allow "en passant" captures #26

Open
RobStallion opened this issue Mar 20, 2019 · 4 comments
Open

Create logic that will allow "en passant" captures #26

RobStallion opened this issue Mar 20, 2019 · 4 comments
Assignees
Labels

Comments

@RobStallion
Copy link
Owner

Need to create the logic that will allow "en passant" captures.

For this I will need to have something in the state that stores whether or if a pawns last move was a "two tile move" (I don't think that there is a name for this. If there is please comment with it 👍)

This will probably be best stored in each pawn.

At the moment the a piece is made up of the following...

type alias Piece =
    { pieceType : PieceType
    , team : Team
    , status : PieceStatus
    }


type PieceType
    = King
    | Queen
    | Rook
    | Bishop
    | Knight
    | Pawn

The PieceType type is currently fairly simple. If I am going to store if a pawn is able to be captured "en passant" in each pawn I am likely going to have to update the PieceType Pawn.

@RobStallion
Copy link
Owner Author

Notes on logic to check

en passant notes

@RobStallion
Copy link
Owner Author

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
Copy link
Owner Author

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

@RobStallion
Copy link
Owner Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant