Tic-Tac-Toe (From Scratch)

Breakdown

Tic-Tac-Toe gameplay (unique approach)

One of the biggest parts of the game play is checking to see if a player has won. The  straight forward approach is to start with each square and check in all directions that could win, and then check the following connected square until there is a win or at the end of a squares.  That is 120 checks per turn. A common sense enhancement would be to stop checking if a connecting square isn't a match, but that only changes the checks to a maximum of roughly 96. I took it a step further and cut in half with a maximum of roughly 48. I was able to do this because I noticed checking each square in every direction was redundant, checking one direction would be the same results if checked in the opposite direction from the other side of the board. Example would be, check the right direction from the (1,1) position would be the same if checked the left direction from the (3,1). So I was able to cut the checking direction in

half. Then I took it to another level, and got the checks to a maximum of 12 per turn. I was able to accomplish that by checking if there is enough length, spaces still available to check for a win, before the end of the board, and if there isn't then the check in that direction never happen. 

m,n,k-game variant (expansion)

This takes the 3 factors of tic-tac-toe, the width of the board, the height of the board, and the winning number of connected symbols, and allows them to be customized to various values

 by the user.  A standard 3x3 game would have the board hard coded, but due to the various sizes, the game board systems should adapt. I broke up the various systems, the board, input validation, win check, win calculation and messaging, and display. Being broken up and having variable inputs lets me build them out and position them in a large array of possibilities. 

Move rewind and fast-forward

The ability to go back any number of moves and resume the game from that point in time, or, if already rewound, can go forward through the moves to any spot up to the most recent. I turned each turn into an independent record, and put them into a list. When a player rewinds the game, it traverses through the list, and if a new turn is made, it throws out the old turns after the current turn, and put the newly made turn in the list. This functionality also allowed me to build other aspects of the turn tracking system.

Render buffer

A duplicate screen space, off camera, that's used as an intermediate and preparation area that all the parts of the desired image are sent  to and organized before being shown to the end user. I created a simple buffer 1D array that would hold all the picture elements with the 2D translation formula of  (y * width + x). I also wrote simple function to wipe and display the buffer. 

Input system (buffered)

Being able to control the menu, game, and settings with a buffered input. A buffered input prevents an input, in this case a key press, from triggering/ activating multiple times from a single press. I wrote a function to encapsulate the desired key inputs with a built in buffer to simplify the process and make it consistent wherever it was needed. Unlike the standard, easy, development approach that most console apps use for input, where each key on the keyboard has a unique 1 to 1 interaction, or constantly asking the user to type in their selection, I made a selection input system. A selection input system utilizes highlighting of options with an additional input press to confirm said options, making for a simpler, more straightforward input system, especially for a game. This led to having to manage the highlighter for the various screens, and making the appropriate selections.  

Dynamic, scalable, systems

Various systems can be modified, updated, grown, or shrunk during the game or in the code easily due to the forward-thinking design and development. Breaking up systems into smaller pieces allowed me to make algorithms that could generate various outcomes on a small set of variables. The various systems that take advantage of this are: the displaying of the game board, win connection amount, board’s position selector, menu high-lighter, player’s move tractor, input, display buffer, and a few more. A good example is the board, it’s made of pieces, and based on the position and pattern it determines the piece that would need to make up the board, so if it needs to scale up, it just needs to repeat certain patterns to fill out the new empty space. 

Safety features (anti-breakage)

Prevents the game from being illegible when the window gets resized. I wrote a function that checks the size of the console window on an input press, if it doesn’t match the dimensions saved, it will resize the window and re-render the frame, so everything can be readable. This prevents the game from being unplayable.