Documentation of the Journey

PLAN:

• First → create base game, including animations, win conditions, and title screen
• Second → implement a quick match and best of 3 mode  (SCRAPPED DUE TO SCOPE CREEP)
• Third → implement online multiplayer (maybe add ranks?) (SCRAPPED DUE TO SCOPE CREEP)
• Fourth → Add Tic Tac Toe bot
• Fifth → Alternative game modes (e.g., 4x4, 2x2, etc..) 

Monday: Project START:

• Began setting up the environment of the game; Used a colrorect node for the environment and used 2 colours (blue and green) to represent player 1 and player 2. When it’s player one’s turn, the ColorRect will have its colour modulated to blue; for player 2, green. Ended day there
• Code:
  • 

Tuesday: Setting up the game itself:

• Implemented a  button node, which would disable when pressed, that can be used to place down either an X or  an O (may reimport assets for X and O in the future)
• Code:
  • 

Wednesday:

• Began setting up animations for player turns and the game beginning. I decided to keep it simple and use a RichTextLabel Node, which will return text put into it in BBcode format, allowing for effects such as text waves, background colour changes, and text font overrides within the code itself. However, I am met with the error that the BBcode surrounding the text is not read properly. As a result, the text shown in the label is the entire text, rather than just the main text itself. Unable to do much due to it being Christmas.
• Code:
  • 
  • 
  • 
  • 
    • Key Points:
      • First chunk of code (within the _Ready() function) sets up the RichTextLabel to be able to be manipulated
      • player_turn_show.BbcodeEnabled must be set to true, as it allows the RichTextLabel node to be able to read BBCode text, otherwise it will not function properly (for more information, see RichTextLabel — Godot Engine (stable) documentation in English)
      • player_turn_show.SelfModulate is always reset for the next player’s turn

Thursday:

• Began further fixing the error on the RichTextLabel, and setting up the world environment (i.e., bloom, etc)
• Finished button animations
• Started sound effects
• Began screenshake coding → ran into error due to the camera 2d being a null instance by the time the process function is called within the CameraShakeHelper class
• Code:
  • 
  • 
  • 
    • Key Points:
      • Created the variable can_on_hover, which handles “turning off” animations depending on whether or not the button is pressed. (private void Target_Pressed()
      • {

can_on_hover = false;

_Off_Hover()//plays the off hover “animation”, and inhibits the on hover “animation” when the button is pressed. In the main scene, the button being pressed also disables it

});

• Uses the CallDeferred() method on the function Setup(), avoiding any errors involving any null instances of the button object which may prohibit it from finding a target centre, and subsequently a target default scale;
• Using the .SetTrans(Tween.TransitionType.Back)function within the .TweenProperty()function allows for more control over how a tweened animation looks. In this case, we borrow from the array of tween transition types, to use the “back” transition. This effect gives a slightly bouncy feel to the tweened animation.

Friday:

• Fixed camera shake problem. Code:
  • 
  • 
    • Key points:
      • Create an RNG system to determine the camera offset using RandomNumberGenerator rand = new RandomNumberGenerator();
      • Allow access to all buttons and the Camera node within the main scene using Node node_name = null, then, within the _Ready() function, get the root of the tree in order to find the node, as they exist higher up i the hierarchy of nodes  (signifying by tic_tac_tiles = GetNodeOrNull<GridContainer>("../GridContainer"), where "../” tells the code that it needs to access the root of the scene first;
      • Connect the signal button.Pressed to the method Button_Pressed(), allowing the variable button_pressed (which handles whether or not the screen will shake) to be set to true, and resets the shake intensity at the end of the interpolation.
• Began implementing sound effects, using the AudioStreamPlayer node and setting the stream type to Polyphonic, allowing multiple sounds to be played over the same audio bus. EDIT → Finished implementing sounds, and started moving onto implementing the wind condition, including animations for both a win and a draw.

Saturday:

• Finished implementing both the Win and the Draw conditions, and added animations for both to improve game feel. Added particle effects for more ambience using the GPUParticles2D node, and setting certain values there
• GPUParticles2D custom presets:
  • 
  • 
• Code:
  • 
    • Key Points:
  • 
  • 
  • 
  • 
• Began implementing a simple bot to play against. Once the bot for the main (or rather default) game mode is created, I will create new scenes corresponding to every kind of game mode, and have a custom bot for each scene. EDIT → FINISHED IMPLEMENTING BOT (though said bot is pretty stupid)

Sunday:

• Game is in its final stage of development; adding a title screen is now the final step
• EDIT → TITLE SCREEN NOW DONE, FINAL PART IS PAUSE/RESTART MENU

Monday:

• LOTS OF BUG FIXES AND TORTURE TESTING:
  • Title screen now fully works as intended
  • Post game options screen fully implemented
  • Pause Screen implemented (but currently does not function as intended, likely due to how it’s being drawn relative to the root of the game (i.e., the game window itself)
  • Modified Bot behaviour to be more “smart” (still very stupid though)
  • Discovered error in 4x4 Bot with modified behaviour → runs draw and win (X) events parallel to each other
  • 
    • Explanation of code:
      •  CheckForWinningMove(string player) utilises the previously defined function CheckWin(). Here, it will first loop through the entire board, until it reaches an empty cell. It then sets this cell to the player, allowing it to process a move ahead of time. By doing this, it can check to see if the result of the current player (be it the bot or the human) will result in a win, and if so, it sets the index (which it will use to modify the corresponding button) accordingly.
      • Within the modified BotMove() function, the bot processes this for both cell_X and cell_O. In doing so, if the bot detects that O (the human) is about to win, the bot will attempt to block at the first place it is blockable. Otherwise, if X (the bot) can win, it will prioritise the cell in which it can win. Otherwise, it will loop through the board to find the first empty space, then place an X there.
      • For every part, a value is returned. This value is used during the bot’s turn, to change the text displayed within a button. If the bot cannot move, or the game has ended, it returns -1 (which is outside the range of the grid of buttons, meaning it cannot be manipulated)

TUESDAY → FINAL DAY:

• Pause Menu finally works; changed the root node from a Control to a CanvasLayer, meaning that it shows in front of all other nodes
• Torture tested every scene, making sure that no bugs are present in both co-op and bot modes
• Modified the title screen (through animations)
• Added new sound effects for the pause menu and title screen
• GAME COMPLETE