I Are Game Programmer

As of this point, I am now a Game Programmer. Connect Four is complete and it does everything that the basic game does. It allows players to take turns and figures out who wins and ends the game. Sure the indication of "End of Game" is the background going from white to blue, and you no longer see a potential chip, but there is a change in how the game behaves. I will be a Game Publisher later this weekend when I put the release up for download.

There is still a list of feature enhancements I could implement, like adding sounds, animating the dropping of the chips, and adding more feedback on the current state of the game. Not to mention I could spend some time adding some details to the various graphical elements. Right now it is just a lot of circles of single color. And there is adding a "computer player." I would not really call it an AI since it would be fairly simple, but it would at least be an structured algorithm.

If I were in a team environment, I would submit what I had for code review. Not because it is "perfect" but more to get an opinion of what would be more important to refactor and make the code better.

Today's coding insight was dealing with creating a state variable to determine if particular procedures should run or not. Now I am working with a fairly simple but clear game loop:

Initialize Game components:
Run Loop while game window is open:
    Get Event from Input
    Process events
    Apply game logic
    Draw/Refresh the screen with updated state of game
Clean up and end program

Since this is constantly iterating many times a second, I don't want the game to check to see if there is a winner every refresh, only once after a new chip is added to a column. Also when the game is "over" but the window is still open, though it should not handle any game related input events.

There are two procedures in the game object that were conditional on the state of the game and if there was a chip recently dropped. I only wanted to check to see if the game is over and change players if there was a new chip to consider. chip_added was a flag set so that both procedures could run. At one point I had the chip_added flag complete modifiable by the main loop and not by the game object. This broke the level of abstraction I was trying to maintain. Not to mention having a publicly modifiable attribute from a class.

My problem was not in setting the condition, that was easily done in the event for adding new chip. But which of the other procedures should reset it. The final solution was to change the name of the flag to player_added_chip. This now makes is consistent that NextPlayer() should be the one to reset the flag.

In the end it was just simply rethinking the name of a variable that makes the logic of the program flow consistently.