Today was all about simplifications in my Tic Tac Toe implementation.
I could simplify my previous
CommandLineIO attempts to separate a player in the game from its input mechanism. The old version of
Player didn’t have any real behavior in it. It was basically just delegating the
next_move() method to its so called “input object” (e.g. an instance of
CommandlineIO). As shown in the image below.
So why not merge these things together?! One thing to note though is, I’m thinking about whether “
CommandLinePlayer” woud be a better name for
HumanPlayer, but I’m still undecided about that.
As I had a rough idea where I wanted to go with my code, I started with implementing a very basic
ComputerPlayer could be added later by renaming the existing Negamax implementation.
The next big change contains an overhaul of the core game logic. Or to put it better: how the game logic will be triggered. In the old version I passed a “display object” to my
Game instance that was responsible to present any messages or UI to the user. I still think abstracting this part from the game itself was a good idea. But an improvable one as well.
One thing that bothered me since quite some time was that the tests for
Game looked messy. Due to the nature of the game logic inside
Game, the tests needed to set up several collaborators and set specific fake values on them in order to instrument the game loop accordingly (and with “game loop” I literally mean a do-while loop). For example in order to verify that both players will be asked for a move, I needed to make sure that the game loop runs at least twice in the test.
So the tests in general verified to correct wiring inside
Game. But they also verified that the game put out the correct messages to this “display object”. That sounds like there are at least two things going on there, that may can be separated from each other. And so I did - or at least I started to.
The main idea now is to have the
Game just to know about the actual game and its rules. Then have a separate
CommandlineUI that uses a
Game and displays its state, prints user informations and so on.
I have a list of things I need to work on tomorrow. One part involves removing the duplications in the tests and production code of
Game. I pretty much implemented the new “game loop” side by side to the existing implementation. Now that I write about it, I realize I could have done this in a separated branch and ignore the fear of breaking too much of the existing code…
What exactly the new game loop looks like will probably topic of tomorrows blog post. Including the main reason to change it in the first place.