Project 2 Milestone 4
Project 2 Reflection
Creative side:
- We kept the design minimal, with the highest contrast parts being the colors used to play the game. I think this worked well, as it makes the game easily readable.
- We discussed putting a background image, but decided not to since we thought that it might distract the player from the game, or may not fit with the minimalist style of everything else.
- There were many good suggestions during the presentation for edits to the layout and style.
- Having the rules initially hidden and then toggleable with a show/hide button would be nice for user first impressions (would show the game board instead of a wall of text), as well as for users who have played a version of mastermind before.
- Different color themes would also be a nice addition. As the current color scheme is very bright, and a darker theme would be an obvious choice. Other variations could also be made that mimic the original board game.
Tactical side:
- Splitting the tasks based on components worked well, and I think the sets of components we divided the project into were good as they could be programmed and tested independently with some placeholder props.
- Our planning was good for the most part (some problems later on). The component breakdown drawing and component hierarchy helped us both get an understanding of our individual tasks and how they fit into the project.
- I worked on the Game, Color Picker, GuessList and Guess components, and ended up adding a ColorPeg component to make displaying the colored circles an easily repeatable task.
- The ColorPeg component is rendered as a div with rounded corners and a background color based on a number (and optional border for the ColorPicker). My first idea was to use images, but I think the rounded div method works better as it doesn’t require the user’s browser to download images and allows for adding more colors to the game or modifying the existing ones easier.
- The logic for checking the game took two attempts, since my first missed some edge cases leading to incorrect miss counts, but it wasn’t too hard to program once I spent some time to walkthrough and write the problem out.
- Getting the game part complete and fully tested early helped me know that the logic was correct for when we started merging our work, since merging caused some errors that appeared to be game logic related, but were instead caused by a misunderstanding in our handling of state between Mastermind and Game.
- While planning the state, we didn’t fully figure out how to reset and change the Game component’s settings only once when the Settings component’s “save settings” button was pressed. Our solution was a combination of storing the settings in both the Mastermind and Game components and calling a Mastermind function from Game to reset the reset flag once the game is reset, ensuring that the game is reset with all of the correct settings and only once.
- If I were to remake this project, I’d probably keep both the Mastermind and Game component’s states in Mastermind, or remove the Mastermind component completely and put all state in the Game component and make Settings a child of Game.