Generally speaking, a turn in Godori is quite simple. You have a hand of cards. On your turn, you play a card. The game board has a collection of cards on it. If the suit of the card you play matches the suit of one of the cards on the board, you capture it. Then a card is played from the draw pile. If that suit matches any on the board, you capture those as well.

From this simple explanation, you can either capture two, four, or zero cards. But there is an exception to this rule. What happens if you made a match on the card you played and then the same suit comes up from the draw pile?

In that situation, you do not capture any cards. All three cards remain on the board until another player or the deck plays the final card in the suit. At that point you capture all four cards.

I have to write programming logic to account for all of these scenarios. Because it’s possible for your cards to get stuck on the board, the way I am approaching this is that I am creating a temporary array of all the cards concerned in a turn.

These are all of the possible numbers of cards in play and how they would be distributed:

• Two Cards: In this case, neither the card you played nor the card from the draw pile matched any suits currently in play. Both cards would be distributed to the game board.
• Three Cards: There are two cases where you get three cards. You either made a match with either the card you played or the card that was drawn and the other card was not a match or all three cards are the same suit and they stay on the board.
• Four Cards: The card you played and the drawn card each found another card on the board to pair with and you get all four cards.
• Five Cards: You captured a set of three with one of your cards or one that was drawn, but the other card did not match.
• Six Cards: Lucky you! You captured a complete suit and picked up another match from the board with the other card.

I can represent this logic in a method with a switch statement:

    func checkForMatch(cards:[Card]) {
        
        let numberOfCards = cards.count
        
        switch numberOfCards {
        case 2:
            cardsInPlay += cards
        case 3:
            let countCards = countSuits(cards: cards)
            players[currentPlayer].capturedCards += countCards.playerCards
            cardsInPlay += countCards.gameCards
        case 4:
            players[currentPlayer].capturedCards += cards
        case 5:
            let countCards = countSuits(cards: cards)
            players[currentPlayer].capturedCards += countCards.playerCards
            cardsInPlay += countCards.gameCards
        case 6:
            players[currentPlayer].capturedCards += cards
        default:
            break
        }
    }

The two, four, and six options are easy. If there are two they go to the board. If there are four or six the player captures all of them.

The hard cases to deal with are the sets of three or five. If there are three, then there is a case where the player gets no cards and a case where the player gets two cards and one goes back to the board. If there are five cards, then the player gets four cards and the board gets one, but which cards go where?

As a person, this is easy to determine. I look at the cards all at once and I pick out the ones that don’t match. Trying to explain this to the computer is difficult.

I have to check the suit property on each card and compare them to find the ones that match.

This is made more difficult by the fact that I don’t know what suit I am dealing with. It’s easy to check to see if all the cards are from the .December suit, but to check a random blob of five cards where four will be one of twelve suits and the last one will be another means that I can’t simply loop through the array of cards checking to see if they’re a specific suit. I have to compare them to one another.

The only think I have available to me to limit the amount of conditional logic is to know the order that the cards are entered into the array. I know that if I have three cards then either the card I played matched or the card from the draw stack matched. There would be no scenario where the first and third card would match without also matching the second card.

A similar pattern exists with the five card option. If you capture a complete suit of cards, then there will be four cards in a row in the array with the same suit. Instead of having to check each card in the array for the mismatching card, I theoretically only have to check the first two cards and the last two cards. If the first two match, the last card will not. If the last two match, then the first one won’t.

This is the current implementation I have:

    func countSuits(cards:[Card]) -> (playerCards:[Card], gameCards:[Card]) {
        
        if cards.count == 3 {
            // I don't think there is a situation where the first and third card would match
            // Either the first and second or second and third cards will match
            if cards[0].cardSuit == cards[1].cardSuit && cards[0].cardSuit == cards[2].cardSuit {
                return ([], cards)
            } else if cards[0].cardSuit == cards[1].cardSuit {
                return([cards[0], cards[1]], [cards[2]])
            } else {
                return([cards[1], cards[2]], [cards[0]])
            }
        } else {
            // Four cards will match and one will not. If arrays work the way I think they're supposed to, 
            // in this case either the first four cards will match or the last four will.
            if cards[0].cardSuit == cards[1].cardSuit {
                return([cards[0], cards[1], cards[2], cards[3]], [cards[4]])
            } else {
                return([cards[1], cards[2], cards[3], cards[4]], [cards[0]])
            }
        }
        
    }

Again, I understand that this implementation is really ugly. Everything is hard coded. There are a lot of if/else statements and array positions. There are a lot of ways this can go wrong.

Conclusions

I know there is probably a better way to deal with this. It’s possible that there is a class in the Gameplay Kit framework that would handle this better.

I am planning to explore better ways to deal with this. I also am planning to write unit tests for this when I move this stuff over to a project where I can include them.

There is simply a lot of state and conditional logic in this application because it’s a game. I saw a bunch of people on Twitter recently talking about how embarrassed we’re going to be in ten years because we use if/else statements. I have not heard any suggestions about how to get around this.

I know writing conditional logic is ugly and there are people reading this who want to completely rewrite my code. This is a question I deal with every day.

There is a certain level of necessary complexity. There are a lot of conditions present in the rules of the game that need to be accommodated for. Simon Allardice talked about how when you’re teaching something there is a certain level of necessary complexity. I know myself and lot of people get frustrated when we do a tutorial for something like OpenGL and we have a spinning cube of death. It’s like, this is cool, but I can’t apply this knowledge to anything.

There are certain circumstances that get chosen for teaching purposes because they’re easy and not messy. There is the world as it is and the world as we wish it would be.

I see situations in here where it’s like “Oh this is simple! I can just set this up like this. Except it doesn’t work in this case, or this one, or this one…”

I am trying to avoid setting up a bunch of spaghetti code or putting in a bunch of unnecessary objects to embed other object with even more objects.

Programming is an iterative process. This code will change down the road. I would rather get something done now and go back and change it later when I get a better idea of what I need than spend all my time waxing poetic about how I could do this with a map() if I didn’t have to account for these edge cases. Bad code that actually gets written trumps perfect code that can only live in your head.

One thing I find fulfilling and frustrating about game development is that there are a lot of things we do in real life without thinking too much about it that are somewhat tricky to represent in code.

One of the big challenges with machine learning is figuring out how to explain to a computer that the blob of data it has represents a pug. A person can look at a picture of a pug and know it’s some kind of smush-faced dog. They might mistake it for a bulldog or something similar, but they won’t look at it and say it’s a table.

The thing I am dealing with right now is dealing a hand in my card game. The cards are dealt into five different collections: Three player hands, the cards currently in play on the table, and the cards in the draw pile.

In real life, a deck is basically a mutable array. You deal the top four cards to the first player, then the same to the next two, then deal three more to each collection and what’s left turns into the draw pile.

Swift doesn’t really think that way. Swift likes immutability. The game has a certain amount of state. The players will play their cards until there are no more, which means that the array will by necessity have to be mutable so that the cards that have been played can be removed from the hand and moved to the player’s captured cards.

It’s possible to make this work, but it’s not super pretty. It’s fighting against the way Swift wants to work.

I really did not want to have to go through and assign each card individually in this function. Since it follows a pattern, where the players each get four cards, then the table gets three, then everything gets three, it seems like it should be automatable.

I have some concerns about how to approach this. This is my first attempt:

    func dealCards(shuffledDeck:[Card]) {

        // Deal four cards to the first player and each one after that
        players[currentPlayer].hand[0...3] = shuffledDeck[0...3]
        nextPlayer()
        players[currentPlayer].hand[0...3] = shuffledDeck[4...7]
        nextPlayer()
        players[currentPlayer].hand[0...3] = shuffledDeck[8...11]
        nextPlayer()
        
        // Deal three cards to the table
        cardsInPlay[0...2] = shuffledDeck[12...14]
        
        // Deal three  more cards to each player
        players[currentPlayer].hand[4...6] = shuffledDeck[15...17]
        nextPlayer()
        players[currentPlayer].hand[4...6] = shuffledDeck[18...20]
        nextPlayer()
        players[currentPlayer].hand[4...6] = shuffledDeck[21...23]
        nextPlayer()
        
        
        // deal three cards to the table
        cardsInPlay[3...5] = shuffledDeck[24...26]
        
        // put the rest in the draw pile
        drawPile[0...21] = shuffledDeck[27...47]
    }

Yes, I know. This is reeking of Code Smell. I have two blocks of code that are nearly identical except for the indices on the shuffled deck. This depends on me keeping track of where I am in my array of cards. It also depends upon me knowing how many cards are in my array.

This makes me deeply uncomfortable. I am not entirely certain how to set up conditional logic for this. If this was before, I would use nested For loops, but those seem to be going the way of the dinosaur.

I suspect this is a situation where map() would probably be the best approach, but I feel like it’s complicated to express. I have to keep track of how many elements are being added to each array and where I am at in the shuffled deck. I even just noticed that I put the wrong terminating index at the end of this method that I went back and changed. There are a lot of ways this can go wrong.

I want to leave this here for the time being and try to think through a better approach to this. I don’t want to add a bunch of functional garbage that is less clear and more complicated than what I have now. I know there are better ways to do this, but I also know there are a lot worse ways to do this.

I do not want to over engineer this. Nothing in this function is going to change. There will never be more than 48 cards in the deck. There will always be three players. I know a lot of the reason we don’t hard code stuff is to add flexibility for changing requirements. But I know these requirements won’t change.

Also, I feel comfortable when I read this method about what it is that it does. It follows the same logical structure that you would if you were actually dealing a deck of cards. I know as a programmer this looks terrible, but me as a person it feels logical because this is the process I would go through if I was actually dealing a hand of Godori.

Conclusions

I will probably refactor this based on input from other people.

I think a lot about human versus computer. I know as a programmer there are more efficient ways for me to do things than I have in this code in particular. But I am also a human being. I have my own biases of how I personally process information.

I have to maintain this code. If I look at this in a year not only do I clearly understand how it works, but I also have an understanding of the game logic about how the cards are to be dealt.

I am probably justifying myself too much, but I am really struggling with this. The reason we have the abstraction of programming languages instead of writing everything in assembly language or machine language is to make programming more human friendly. Does writing more verbose code that is more clear to me but breaks best programming practices make me a hack? Or are we making things harder than they have to be in the name of trying to be 10x programmers?

Only time will tell.

Back when I created my Player class, I was trying to figure out how to organize players. I needed to have three players that I would keep in a specific order. My initial idea was to put them in an enum:

enum Players {
    case PlayerA
    case PlayerB
    case PlayerC
}

This was really bothering me. I knew I wanted some way to switch between players and we would always have a current player.

I was trying to figure out how to make this work and I realized I made a grievous error. I was misusing Enumerations.

Enumerations are good for things where you have options that result in you doing something. The example used in the Swift programming book from Apple does a really good job of showing what they mean by that:

enum Direction {
    case North
    case South
    case East
    case West
}

Having these directions in an enum allows you to create conditional logic where you have different actions based on what direction is currently selected.

It is not good at directly affecting and changing any of the case statements in the enum.

I need a data structure that holds three players. I need to know the order the players are in. I have to be able to affect the properties based on things that happen in the code.

I thought about putting these in a dictionary, but I realized that wasn’t really optimal. Dictionaries have orders, but they’re meant to correlate to keys and values. I just need to know what the current player is so I can set its properties and move on to the next one reliably.

I decided I needed an array of players. This array of players has to be initialized in the Game class and passed into the Hand class. The Player needs to be initialized with the initial amount of money that each player starts with.

I created a function that generates an array of players:

func createPlayers(startingMoney:Int) -> [Player] {
    let player = Player(money: startingMoney)
    return Array(repeatElement(player, count: 3))
}

I can then call this function in the Game class and set it to a variable that I can pass to the Hand class. The Hand plays through a round, determines the winner, and returns it to the Game so the Game can determine if another round should be played.

This means that I needed to add a few methods to the Player class to accommodate for these implementation details:

    init(money:Int) {
        currentMoney = money
        numberOfDeferrals = 0
        numberOfPoints = 0
    }
    
    // Reset Players
    mutating func resetPlayer() {
        hand.removeAll()
        capturedCards.removeAll()
        numberOfDeferrals = 0
        numberOfPoints = 0
    }

When the Player is initialized, it is created with the starting amount of money. When a Hand is completed, a Player’s properties need to be reset.

This clarifies a lot of what I need to do in the Hand Class. Now that I know I am using an array of players rather than an enum, I can create all of my properties that I need for a Hand:

    /*
      1. Players
      2. Current Player
      3. Shuffled Deck
      4. Cards on Board
      5. Draw Pile
    */

    var players:[Player]
    var currentPlayer:Player
    let shuffledDeck = shuffleDeck(deck: deck)
    var cardsInPlay = [Card]()
    var drawPile = [Card]()

As per my work in my previous post on figuring out what components I need, I have been able to figure out what type each of my properties are.

I made a mistake when creating my initializer. At first I made the current player a Player object. My initializer looked like this:

    init(playerArray:[Player], firstPlayer:Player) {
        players = playerArray
        currentPlayer = players[firstPlayer]
        dealCards(shuffledDeck: shuffledDeck)
    }

I thought that made a lot of sense, to make the currentPlayer an instance of the Player struct, but I realized that doing this divorced it from the player array.

The game logic basically requires a player to complete their turn and for the process to continue with the next player. By pulling out the current player from the array and making a copy of it in the current player, I have no way of knowing if that player is the first player or the hundredth. I need to persist where I am in my cycle of players because the current player keeps changing.

So I changed my currentPlayer property to:

var currentPlayer:Int = 0

and my initializer to:

    init(playerArray:[Player], firstPlayer:Int) {
        players = playerArray
        currentPlayer = firstPlayer
        dealCards(shuffledDeck: shuffledDeck)
    }

Now being able to go to the next player is fairly simple. I created a method to move to the next player in the array:

   func nextPlayer() {
        if currentPlayer == 2 {
            currentPlayer = 0
        } else {
            currentPlayer += 1
        }
    }

I made this a method on the Hand class. I had hoped to make this into a standalone function so it would be easier to test and be reusable within the application, but I decided against that for two reasons:

• It makes the function a lot messier. I have to pass in the current index and pass back the return function. I would much rather just call nextPlayer() and not worry about it.
• I don’t think I actually need this anywhere else in the code. There is no point in over engineering the app adding a bunch of stuff you won’t need.

Conclusions

I am in the process of building out the dealCards() method. I have to deal four cards to each player, then deal three to the table, then three more to each player, and then three to the table. I have to switch players several times and organize all the arrays properly.

I would like to be able to pinch off the first few elements of one array and give them to another array. I know I need to copy those elements and probably remove them from the shuffled deck array.

I can think of some really inefficient ways of doing this. I might write that method out inefficiently first so I can see where all the repeated code is. Writing bad code is an underestimated way to find your way to good code. Embrace bad code!!