perf: async task execution for player SaveManager

[dudantas]

Description

This implements a new approach for executing player-related save tasks asynchronously using a task-based model. The change allows for tasks to be stored in a vector and later executed as a batch, which reduces the load on the main game thread and improves the efficiency of player data persistence. Each task is added to the Save Manager as a lambda function, allowing flexibility for handling various save operations (e.g., player inventory, stash, storage). The solution aims to ensure that tasks are executed in the same order they were added, addressing the potential bottlenecks in high-load scenarios.

Replacement of std::ostringstream with fmt::format in load/save functions:
All instances of std::ostringstream were replaced by fmt::format. This change results in several improvements:

• Performance: fmt::format is generally faster and more efficient compared to std::ostringstream when constructing strings, especially in high-load scenarios.
• Code Readability: The use of fmt::format improves code readability, making string formatting more concise and reducing verbosity.
• Reduced Risk of Errors: Using fmt::format reduces the risk of common errors that occur with multiple chained << operators, leading to more robust and maintainable code.

Behaviour

Actual

• Tasks were executed synchronously, creating delays in gameplay and blocking main game logic due to expensive save operations.

Expected

• Tasks should be added to a list and executed asynchronously without blocking the main game logic, reducing the overall impact on performance during high-load scenarios.

Type of change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested

• Task addition and asynchronous execution were verified with multiple players, ensuring the correct order of task completion.
• Verified the impact on game performance by measuring latency before and after the change.
• Tested data consistency after asynchronous saves to ensure no data was lost during the process.

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I checked the PR checks reports
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works

---

Improvements in Player Storage, Stash, and Forge History

Summary of Changes:

1. Centralization into Separate Classes:
   The functionalities related to player storage, stash, and forge history have been organized into individual classes under a new folder named "components." This separation enhances code maintainability and readability, ensuring each component is modular and well-defined.

2. Caching System for Modified Items Only:
   A caching mechanism was introduced to only save information that has been modified. Instead of saving all data related to the player, the system tracks modified or removed keys/items, significantly improving save efficiency. This reduces redundant save operations and minimizes database load.

3. Unique Key for Forge History (done_at):
   For the Forge History system, a unique key (done_at) was added to ensure precise control over what needs to be saved. This modification allows for selective updates, meaning only records that were changed will be saved, leading to improved consistency and optimized performance when dealing with large data sets.

These enhancements collectively contribute to improving the scalability and efficiency of the system, reducing the performance overhead caused by frequent save operations.

[sonarqubecloud]

Quality Gate passed

Issues
61 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud