Connect Four Programming Challenge Pt 3
Continuing from Pt 2 ...
Unfortunately the remainder of this challenge is not so exciting. After part 2, I've actually successfully completed the conditions (simulating game board, placement of pieces, and an optimized victory checking algorithm!)
Well, almost...
Alternation of Turns
This is pretty straightforward - in a two player game this is simply a boolean bit (0 or 1) that is simply set to not itself whenever a move is played. In my two hour version I made the mistake of not connecting these two things together, but instead provided a method to manually advance turns. (This is more a function of the game rather than inherent in the board itself). Because these two things are decoupled, we can allow for more robust changes in the future - not necessarily optimized to complete a game of connect 4.
Additionally, in a multiplayer version, the algorithm for selecting the next player that I chose was simply to advance down the player list and then loop. However, since that never came to fruition, this still reduces down to the same functionality with two players.
Now we're done. However, there are things left to do to make this a "game" rather than just being able to simulate the state.
Designing the Input Loop
At this point we're just closing up and making sure that there is a flow to the game that makes sense. We want to be able to display the board, and take in input. We should be able to fail gracefully if the input is incorrect or not a legal move, and ask again.
With the way the classes are separated and the methods structured, the board attempts to place a piece but will return -1 to indicate failure. Since this does not change the board, we can allow for the user attempt to place in a full column however much they want but it will not advance unless they place a valid move. It is the same with the input loop.
The idea is that since we have a very clear idea of what input is necessary to advance, we can simply just run on a loop until we have a satisfactory condition (a valid move). We can throw helpful error messages depending on the type of fault to help guide the user to advance ("Insert a number from 0...6!")
Throwing Error MEssages
Even in something simple like this it makes sense to be able to throw error messages a user's way. I could just simply print when something goes wrong but it may be confusing to not have it displayed in a consistent way, especially if it fails somewhere you don't expect.
We could just have an error field in the Game object that you can set a message to, but what if there are multiple errors between user events? An error message stack that gets emptied on user event loops is a solution. We simply just push errors onto the stack so that we can keep track of them and only show them the next time the user is prompted for action. "Enter a valid column!" and "Enter a valid number!" can both be pushed without conflict or complications with overwriting.
Good String Habits
Good software development habits in production is to separate and abstract all your string prompts and representations into variables. This is necessary for good localization in a production environment, where the representation of your data may need to change on the fly. In an increasingly globalized world, this is some of the concerns that needs to go into software development.
It also makes a good case for separation of the function of the prompt from the representation of it. (e.g. function is to solicit user input, representation is the English string)
Well that's all the thoughts I had about this programming challenge! It was good to turn my brain on again, and also to write it down explicitly so I remember my thought process.
This was mostly for me but if you're stumbling upon this good for you too! I hope you enjoy.