In your terminal, after cloning or forking this repository, and cd into it, run ruby lib/runner.rb to run the game.
- This project did not provide an interaction pattern. How did you approach the design and problem solving process for this project?
- When we started the project we went through the instructions of each iteration, broke down in more concise terms what each iteration was asking for, and started to develop ideas for how we wanted to make the program capture all the necessaties listed in the iterations. As we continued through each iteration, we would circle back to previously determined classes/ideas that we had come up with and either added to them, or changed them to fit what we thought would be needed. Once we began writing the actual code, we then referred back to our own project outline to act as a guide and made changes where we saw fit. Having the outline helped us with design problems and decisions early on. It also helped us making decisions early on on what responsibilities each class would have.
- If you had one more day to work on this project, what would you work on?
- We had discussed an extension that was not listed in the iteration 4 page, but would be a bit of a combination of utilizing HTTP and making the game playable by two players. We were interested in seeing what it would take to make the game online multiplayer so that we could play each other from our own computers at the same time. We have discussed doing this as a fun little side project in separate time from class work to see what that process would look like.
- Describe the pairing techniques you used while working on this project.
- We used mostly driver-navigator pairing techniques to complete this project. We considered using the ping-pong method, however because we have similar working schedules, and so much of this program requires interaction with previously built classes, we found that the driver-navigator method was the smoothest and quickest process for us to complete the project. It also allowed us to more quickly make decisions on design choices for our different classes, how things were output, and how we solved different problems or roadblocks that we encountered.
- Describe how feedback was shared over the course of this project.
- Much of our feedback was shared in real time as we were almost 100% working together via slack huddle while we completed this project. There was a small portion of feedback that we gave to each other via comments on pull requests via GitHub, but that was used mostly to capture notes for ourselves about what to continue working on when we came back to the project from breaks/pairing sessions. When we began the project with our DTR, we were able to quickly determine what styles of feedback work best for both of us and capture those in writing. Being able to refer back to that document helped us make sure that we were able to give concise and clear feedback, while still being kind, respectful, and considerate of how our feedback and tone would be taken by the other partner. Had we not established that through our DTR ahead of time, we both likely would have hit more road blocks and struggled to clearly convey our own opinions on design choices as well as technical implementation and improvements that we thought could be made.