-
Notifications
You must be signed in to change notification settings - Fork 1
Quick Time Event User Tests
The QuickTimeEvent system consists of two main components:
- QuickTimeEventActions: Manages the QTE lifecycle and game state transitions
- QuickTimeEventDisplay: Handles the UI rendering and user interaction
This test documentation covers both components' functionality, integration, and performance characteristics.
ID | Test Case | Input | Expected Output | Preconditions |
---|---|---|---|---|
UI1 | Load combat screen with UI components | Component creation | All UI elements properly initialized | Game, Screen, Entities and Buttons are initialized and loaded properly |
UI2 | Asset loading | Resource paths | Assets loaded correctly | Valid asset files |
UI3 | Table layout | Window dimensions | Correct component positioning | Button Stage initialized Entity stats loaded |
ID | Test Case | Input | Expected Output | Preconditions |
---|---|---|---|---|
IH1 | Button click to initiate events in QTE | Click events | Appropriate event triggers | UI fully initialized |
IH2 | QTE timing window | Button press within window | Perfect hit registered | QTE active |
IH3 | QTE timing - too early | Early button press | Fast indicator shown | QTE active |
IH4 | QTE timing - too late | Late/no button press | Slow indicator shown | QTE active |
ID | Test Case | Input | Expected Output | Preconditions |
---|---|---|---|---|
VF1 | Target image updates | Image state change | Correct texture displayed | Assets loaded |
VF2 | Score display | Score change | Updated score text | Display initialized |
VF3 | QTE animation | Animation trigger | Correct scaling/rotation | QTE component active |
VF4 | Background rendering | Draw call | Background properly rendered | SpriteBatch available |
ID | Test Case | Input | Expected Output | Preconditions |
---|---|---|---|---|
SM1 | Countdown initialization | Start event | count = 3, label updated | Component created |
SM2 | Update cycle | Time progression | Correct count updates | Countdown active |
SM3 | Screen transition | Count reaches 0 | Combat screen loaded | Game instance available |
ID | Test Case | Input | Expected Output | Preconditions |
---|---|---|---|---|
CC1 | Action-Display sync | State changes | Components properly synchronized | Both components active |
CC2 | Score propagation | QTE completion | Score correctly transferred | Full system running |
CC3 | Screen flow | Sequence completion | Proper game flow maintained | All components active |
ID | Test Case | Input | Expected Output | Preconditions |
---|---|---|---|---|
RM1 | Asset Availability | Screen Sequencing | Proper loading/unloading | Required Services registered correctly |
RM2 | Service locator usage | Service requests | Correct service provision | ServiceLocator registered |
Several integration tests have failed, revealing significant issues in the QuickTimeEvent system:
-
Score Propagation Failure (CC2): The test for transferring scores between screens failed, indicating a major issue in the combat manager. This requires a substantial refactoring of how scores are passed between different game screens.
-
Screen Flow Disruption (CC3): The test for maintaining proper game flow after QTE sequence completion failed. This suggests that the transitions between the QTE system and other game components are not functioning correctly.
-
Animation and UI Component Issues: The failures in tests VF3 and VF4 indicate that the animations and UI components in the combat stats display are not working as expected. This necessitates a major refactoring of these elements.
These failures are causing ripple effects throughout the codebase, particularly in the combat manager and related UI components. The need for extensive refactoring highlights potential architectural issues in the game's design.
The integration test failures have brought attention to pre-existing issues in the main game code:
-
Circular Dependencies: The codebase suffers from extensive circular dependencies, with this class being part of 98 cycles containing 87 classes. This issue has been flagged in the SonarCloud.
-
Impact of Circular Dependencies:
- Disrupts dependency hierarchy and layer structure between packages
- Increases architectural complexity
- Reduces code readability, extensibility, and maintainability
- Leads to the creation of more circular dependencies as the project grows
- Increases technical debt
- Makes future refactoring increasingly difficult
These issues compound the problems revealed by the integration test failures, making the necessary refactoring more challenging and time-consuming.
The integration test failures and existing code quality issues have revealed significant challenges in the QuickTimeEvent system as we realized the overall game architecturedoes not leave enough room to integrate quick time events bug free. Therefore, due to time constraints and the need to maintain a baseline functional game, implementing major changes was not feasible. Here are the key conclusions:
Architectural Limitations: The circular dependencies, particularly those crossing package boundaries, represent a significant architectural challenge. These issues increase the complexity of the codebase and make it difficult to implement clean solutions for the problems identified in the integration tests.
Combat Manager Constraints: The score propagation failure highlighted issues in the combat manager. While a complete refactoring would be ideal, the team had to settle for minimal adjustments to ensure basic functionality.
UI and Animation Compromises: The failures in animation and UI component tests for the combat stats display required attention. However, only minor tweaks could be made to ensure the game remained playable, leaving room for future improvements.
Screen Flow Workarounds: The screen flow disruption after QTE sequence completion was addressed with temporary fixes rather than a comprehensive redesign of the transition mechanism.
Technical Debt Accumulation: The inability to address the root causes of these issues, particularly the circular dependencies, has resulted in increased technical debt. Which was made apparent while trying to integrate Quick Time Events.
Testing Limitations: While the integration tests revealed critical issues, the team couldn't allocate time to significantly increase test coverage or implement more robust testing practices.
Baseline Functionality Priority: Given the project constraints, maintaining and refining the existing functional baseline took precedence over architectural improvements. This decision allowed the team to deliver a playable game but left underlying issues unresolved.
Learning Opportunity: This experience has provided valuable insights into the importance of early architectural decisions and the challenges of managing technical debt in game development projects with tight deadlines.
Documentation Value: Despite the limitations in implementing changes, the comprehensive test documentation and identification of issues serve as a valuable resource for future development efforts.
These conclusions reflect the reality of game development under constraints, where balancing immediate functionality with long-term code quality is an ongoing challenge. While the team couldn't implement ideal solutions, they've gained important insights that can inform future development practices and priorities.