Pair Programming Power — Activate!
A concept central to coding effectively is pair programming. It takes the old maxim of “two minds are better than one” and makes it real, uniting two programmers with a singular problem to solve. When pair programming, one person is a navigator (the person thinking about the problem and instructing the other to try certain solutions) and the other is a driver (the one coding).
During my time during the Flatiron School, pair programming was a huge boon to my development. Not only did I get the chance to work on my communication skills but also glimpsed into someone else’s thought process, which usually led me to understand new concepts or code.
One of my biggest breakthrough moments at Flatiron School was my time spent pair programming with instructor Caryn McCarthy. Together, we arrived at a solution for a problem I’m pretty sure I would have never have solved by myself.
The Trickiness of Triple Triad
“Games are really hard”, they said.
“I don’t know, games are really complex,” they said.
So what did I do? I attempted to make a full card game in three weeks — that I’m still working on 3 months later!
When we were assigned our final project at Flatiron School, I let nostalgia inspire me and decided to create Triple Triad, a card-based mini-game created for the Playstation classic Final Fantasy 8.
In this game, each player begins with a five-card hand inspired by the characters and creatures of that game’s world. Each of those cards has four values arranged in a diamond arrangement corresponding to each side of the card (top, left, right, bottom) and a background color signifying which player has possession of that card (A blue background for player 1 and red for player 2).
Here’s the rub: when a card (let’s call this card A) is played onto the board next to another card in the opponent’s possession (this’ll be card B), the two card’s adjacent values are compared.
If card A’s value is higher than card B’s value, card B is captured and flips to the opposite color as a result (red to blue, or vice-versa) to signify possession. Play continues until the 3x3 grid is filled, at which point the player with the highest point total is declared the winner.
Sounds straightforward enough, right? If you know about games, you’ll know to say no. However, as I didn’t, I charged forth with nothing but 15 weeks of code experience and blind courage.
So, that part about comparing card values? That was a major stumbling block for me at that point in my coding education. The good news is that I already created the 3x3 board with the following code in the Game component’s state:
I quickly learned that boards in games can be tricky in and of themselves to program but decided to create an array of objects to represent the board and the cards in each space. As seen above, each object in the array has two keys, position and card, set to the position number on the 3x3 grid starting from the top left and going left to right and null value for card. With this set up, I’m able to change the value of the card to whatever card is played while maintaining the position number for later reference.
Comparison, Comparison
Still, when confronted with the challenge of comparing card values, I was at a loss. I know a lot of other developers, seasoned or not, can relate: I felt like the more I thought about the problem, the more it unraveled and the more complex it became. Needing a hand, I tapped Caryn to help me navigate what were conceptually uncharted waters.
As the navigator, the way Caryn asked me the right questions helped me get closer to a starting point of a solution, something that two programmers at any level can help each other by doing.
After a few questions and a light discussion, Caryn became the driver and coded an object we named a comparisonMap:
This comparison map is valuable not on its own but as a reference used by the function actually doing the comparison of card values. As you can see above, the comparison map is an object with a set of key/value pairs. The key is a number corresponding to a position on the board and the value is an array of objects with information necessary to make comparisons. Inside each object is the number of a position relevant as compared to the position selected by the current player and which values need to be compared from position.
When I finished writing out comparisonMap, it revealed a few things to me. The most important was how vital it is to have intermediaries helping a process along. I admit this is a very procedural way of working out this issue, but every step is another in the right direction. But more importantly, the reason why my mind was a blank void when confronted with this issue was because I psyched myself out imagining a crazy long and complicated solution. What I needed to do was start thinking a bit broader, a bit more conceptually, and a lot more programmatically.
The comparisonMap solution and how it was used in the rest of my code represents some of the most interesting strides I made during my coding journey so far. I hope this experience helps you on yours too!
While it’s still a work in progress, if you’d like to take a look at Triple Triad, you can do so here and here.
