July

7.25.2023

Morning

Filled out GDD with general details.

Wrote example scripts for PowerUps, Weapons, Player

Afternoon

Added some generic sprite packages to exercise components on

Evening

GOAL: Implementing turn-based movement

PlayerController: This class would be attached to the Player object, and would handle input from the user. It would register when a key is held down, triggering the Player to take a turn and move.
TurnManager: This class is essential for coordinating turns. When the PlayerController registers a movement, it would alert the TurnManager, which would then call each entity in the game to take its turn. This class would also handle the rapid succession of turns when a key is held down for more than 0.5 seconds.
Entity: This could be a base class for any object in the game world that takes turns. It would have a method, like TakeTurn(), that is called by the TurnManager. It may also have properties for its current position in the game world.
AIController: This would be a controller class for non-player entities, dictating their behavior during their turn based on whatever AI rules you establish. AI rules can be as simple as moving in a straight line toward the player, or as complex as using pathfinding algorithms to navigate a maze.
GameManager: This would be a higher-level class responsible for managing the game state. It would control when the game is in a paused or unpaused state, as well as managing menus and UI.
GridManager: In a grid-based game, this class could manage the grid on which the game takes place. This could include knowing what objects are in each grid cell, as well as handling movement of objects between cells.
UIManager: This class would be responsible for updating the UI in response to game state changes. It could display the number of turns taken, the status of the player, and so on.

COMPLETED:

Entity: Implemented a base Entity class, which represents an object in the game world that can take turns. Added properties like Position, Health, Damage, and EntityStatusCondition. Also created TakeTurn(), CanTakeTurn(), and IsAlive() methods.
PlayerController: This class handles user input. It tracks when movement keys are pressed and triggers the Player to take a turn, including handling for key holds leading to rapid successive turns.
Player: The Player class extends the Entity class and represents the main player in the game. It interacts with the PlayerController for input-driven behavior.
TurnManager: This class is responsible for managing turns in the game. It maintains a queue of entities that are waiting to take their turns, and when the player takes a turn, it calls each entity in the queue to take its turn as well.
GridManager: This class manages the game's grid. It's responsible for tracking what objects are in each grid cell and moving objects between cells. It also includes a function to reset the grid and another function to lock an object to the grid's nearest cell.
GameManager: The GameManager is a high-level manager for the game. It handles game state and interacts with other manager classes like TurnManager and GridManager.
UIManager: This class is responsible for updating the game's UI in response to game state changes, such as displaying the number of turns taken and the player's status.
EnemyController (previously AIController): This class manages non-player entities. It dictates their behavior during their turns, and the enemies move towards the player for now.
Wrote utility functions for various purposes, including converting a Vector2 to a Direction enum, and a function to move an Entity one step in a specified direction.

This structure provides a robust foundation for a grid-based roguelike game, and it should be extensible.

7.26.2023

Task 2: Weapons and Power-ups
- Day 4: Implement the "WeaponManager" and "PowerUpManager" classes.
- Day 5: Create a few sample weapons and power-ups (e.g., the "Nanobot Swarm" and related upgrades).
- Day 6: Test the weapon and power-up system, make necessary adjustments.
- These scripts manage the player's weapons and power-ups, allowing them to be used, upgraded, and swapped out.

Morning

Sidquest

Absolutely, I'd be glad to summarize the work we have done together since refactoring the GetOneStepInRandomDirection function.

Optimized GridManager: We made improvements to the GridManager class to handle situations where there may be thousands of entities. Instead of using a list for each grid cell, we switched to using a HashSet<Entity>. This allows us to quickly check if a specific entity exists in a grid cell without iterating through all entities. It's an important optimization for games with a large number of entities.
Modified GridManager's MoveEntity Method: We modified this method to make sure that players can't move onto an enemy entity and vice versa. The method checks for any entities at the new position and based on the type of entities found, it determines whether the move is legal or not.
Addressed the Entity Turn Taking Issue: You were facing a problem with your turn-based system where enemy entities were taking multiple turns without waiting for the player. We corrected this by modifying the ExecuteTurns function in the TurnManager class and added a waitTurns field in the Entity class to handle entity "speed". We also discussed how to handle entities that can take multiple turns in a row.
Updated CanTakeTurn Method: We updated the CanTakeTurn method in the Entity class to take into account the new waitTurns field. The method now checks if an entity has any waiting turns left before allowing it to take a turn. This introduces a delay or speed mechanic into the turn-based system.
Managed Entity Counter: We created a function in the GridManager to keep track of the number of enemy entities at a specific position. If more than one enemy is present at a position, a counter is shown at that position. The function handles creating, updating, and destroying the counter based on the number of enemies at the position.
Added camera controller. Avoid update function to optimize performance

Throughout these improvements, we made sure to refactor the code to keep it clean and maintainable. We used design principles like encapsulation and modularization to ensure each class and function has a single responsibility. This makes the code easier to understand, debug, and extend in the future.\

In the afternoon and evening continue work on

Day 5: Create a few sample weapons and power-ups (e.g., the "Nanobot Swarm" and related upgrades).
Day 6: Test the weapon and power-up system, make necessary adjustments.
- Add Player death and enemy death / apply damage
Basic Geometric patterns for spawning. WaveData and WaveManager (control of LevelManager)

Evening

Sure, here's a summary of what we've discussed and developed from the CameraController until now:

Camera Controller: We created a script that ensures the camera smoothly follows the player using a lerp function. The camera updates its position every time the player takes a turn, rather than every frame in the Update method, to ensure better performance.
Enemy Wave Management: We discussed how to handle enemy waves. You wanted to have the option to spawn the enemies at intervals or via the turn manager. We adjusted the enemy wave spawner to spawn X enemies over X turns.
Entity Turn Manager: We modified the entity turn manager to handle multiple enemies taking turns more rapidly than the player, based on a speed value.
Enemy Counter At Position: We reviewed and refactored a function for updating an enemy counter at a certain grid position. The function checks for the presence of multiple enemies at a single position and either updates an existing counter or creates a new one.
Level Management: We discussed how to manage player's level. You wanted a function that would be called when the player's XP changes to handle level logic. We implemented an XP-to-Level calculation function that increases exponentially as per the formula: XP = (Level ^ 3) + 2 * Level.
Entity Damages: We handled an issue where calling the TakeDamage method might destroy an entity during iteration over a collection of entities. To avoid modifying the collection during enumeration, we made a copy of the list before looping over it.
Doodad Destruction: We addressed a question about casting in C#. You wanted to check if an entity was a destructible doodad and handle it accordingly, so we used an is type-check and introduced how to cast the entity to a doodad.

Overall, we made significant progress in game mechanics and structure, improving turn management, introducing wave dynamics, and refining entity behaviors. We also worked towards creating a balance in the game by setting and adjusting initial values for player's base damage, basic enemy health, spawn rate, player health, enemy damage, XP values, and level-up/upgrade values.

Very Late Evening

Absolutely, I'll be glad to provide a recap of the recent discussions and developments:

Turn System Update: You made sure that the player always triggers a new turn when they move, and that all enemies will then take their turns. This represents a major part of your game logic.
Grid System Update: You updated your GridManager to support entity movement within the grid. When an entity attempts to move to a new position on the grid, checks are made to see if the movement is valid, considering factors such as the presence of other entities at the target position.
Entity Interactions: You've implemented player-enemy interactions. If an enemy attempts to move onto a player, the player takes damage. Conversely, if the player attempts to move onto an enemy, the movement is blocked.
Animation Implementation: You integrated DoTween into your project to handle the animations of entity movements. You ran into some synchronization issues between the grid logic and the animations because the DoTween animations were executing asynchronously, but you decided to proceed without immediate changes as the animation duration was quite short and it didn't have a noticeable impact on the gameplay experience.
Enemy Count UI: To help track the number of enemies at a given position on the grid, you created an Enemy Counter UI that appears at positions with more than one enemy.
Player Attack Implementation: You refactored the player's attack mechanism to make it feel more responsive. Now, the player tries to move first, and if the movement is successful, the attack is delayed for a short duration, otherwise, the attack is immediate. This provides a more fluid and dynamic combat experience for the player.

The systems that you've put in place form a solid base for your game's development. They show a clear progression towards a playable game. With your basic game logic, grid system, animations, and UI elements in place, you have a robust foundation to build upon. Going forward, you can focus on adding new gameplay features, tweaking game balance, or improving the game's presentation.

7.27.2027

GridManager

The GridManager is responsible for tracking entities in a grid structure and providing mechanisms for moving these entities around. Here are the key points of our work:

Error Handling: We addressed the potential exceptions that could arise during entity unregistration. We ensured that an entity can only be removed if it exists in the grid at the specified position.
Null Checks: We made sure to check for null values returned by the GetEntitiesAtPosition() function before operating on them. This helped us prevent NullReferenceExceptions that could arise from trying to use a null reference.
Collision Checks: We updated the MoveEntityOneStep() function to handle collision logic more robustly. Now, the function checks if the entity it's trying to move onto is alive, and it handles cases where the moving entity or the entity being moved onto is killed.

TurnManager

The TurnManager is responsible for managing the turns of different entities in your game.

Entity Deletion: We improved how entities are removed from the turn order to prevent potential issues that could arise when trying to give a turn to an entity that has been destroyed. Now, when an entity is killed, it is immediately unregistered from the TurnManager, and we check if an entity is dead before attempting to give it a turn.

Overall, these changes increased the robustness of your game's logic and helped to prevent potential errors or unexpected behaviors. The result is a more stable game that should handle edge cases and unexpected conditions more effectively.

Late Evening ☹️

\ In a typical turn-based game, there is often some system to decide the order in which entities (like characters or enemies) take their turns. This is often based on some sort of attribute, like "speed" or "initiative". Let's break down how this is implemented in your code:

Initiative: Initiative is a concept used in many games to determine the order of turns at the beginning of a combat round. Typically, each entity involved in the combat rolls a die and adds their initiative modifier to it (if any). The entity with the highest result gets to act first.

In your case, the InitiativeRoll property of each Entity can be used to determine this order. You may randomly determine this value at the beginning of each combat round, or it may be statically set based on the entity's stats. The entities are then ordered by this value in descending order.

csharpCopy code

entities.OrderByDescending(e => e.InitiativeRoll)

Speed: Speed is another commonly used attribute in games, which can determine how frequently an entity gets to act. The higher an entity's speed, the more turns they might get in a round of combat.

In your TurnManager class, you're using a dictionary speedCounters to keep track of how many "ticks" each entity has accumulated. Each time the Tick() method is called, each entity's counter is incremented:

csharpCopy code

speedCounters[entity]++;

When an entity's counter reaches their Speed, they get to take a turn, and their counter is reset to zero:

csharpCopy code

if (speedCounters[entity] >= entity.Speed) { speedCounters[entity] = 0; if (entity.CanTakeTurn()) { yield return entity.StartCoroutine(entity.TakeTurn()); } }

This allows entities with higher Speed to take turns more often. Entities are also ordered by their Speed in descending order, so higher Speed entities will act before lower Speed ones in the same tick.

csharpCopy code

entities.OrderByDescending(e => e.Speed)

So in summary, Initiative determines the initial order of turns, and Speed determines how often entities get to take their turns. Both work together to simulate a dynamic turn-based combat system.

7.28.2023

Morning Task List

With a player speed of 5 and an enemy speed of 6, The player needs to tap their button 5 times to move once. 1 more time to make the enemies move, and so on. As enemies spawn in at random intervals or turns the game becomes dynamic, enimes move with, before, or after the player.

Major refactors to the TurnManager and the GridManager are complete. They are functional enough to allow me to proceed into the more 'fun' work. Tomorrow I can get to the rest of the task list above.

7.29.2023

Morning Task List

Worked on a Dialogue manager, Dialogue UI, Lighting, Music, SFX, Sprites and scene composition. Good day, but I need to leave the task list for tomorrow.

7.30.2023

Morning Task List

Major progress on visual elements && lighting. Major progress on UIManager, Game state, and HUD.

7.31.2023

Morning Task List

Implemented another weapon. Moving onto the wave spawns and the AI. Will work on the nanobot swarm or chain weapon later.

Add XP powerups (Need to collect them by moving onto them

AddWeapon pickups (unlock / equipped system

July

7.25.2023​

Morning​

Afternoon​

Evening​

7.26.2023​

Morning​

Sidquest​

Evening​

Very Late Evening​

7.27.2027​

GridManager​

TurnManager​

Late Evening ☹️

7.28.2023​

Morning Task List​

7.29.2023​

Morning Task List​

7.30.2023​

Morning Task List​

7.31.2023​

Morning Task List​

7.25.2023

Morning

Afternoon

Evening

7.26.2023

Morning

Sidquest

Evening

Very Late Evening

7.27.2027

GridManager

TurnManager

7.28.2023

Morning Task List

7.29.2023

Morning Task List

7.30.2023

Morning Task List

7.31.2023

Morning Task List