Thematic Issue - Coding Standard for OOP and effective collaboration

[nigelmoses32]

If it's not obvious, the following text is from ChatGPT:

Prompt: I would like to modify my existing code base for the game to make it more Object oriented and modular, so that working with other people is easier without merge conflicts. What practical principles/changes can be applied to the existing code in Godot?

Answer: To make your existing game codebase more object-oriented and modular for better collaboration and to minimize merge conflicts, here are some practical principles and changes you can apply:

1. Single Responsibility Principle (SRP)

• Ensure each class or script has a single responsibility. For example, split functionality such as scoring, dice rolling, and network management into separate classes.
• Benefits: Each script is easier to understand and modify independently without risking unexpected changes to other areas.

2. Inheritance and Polymorphism

• Abstract Base Classes: Create base classes for shared functionality, as discussed with your dice classes (BaseDie.gd).
• Use Inheritance: Create specialized versions of common game components by inheriting from base classes. This helps in managing shared code and reduces redundancy.
• Polymorphism: Make use of polymorphism by having functions in the base class that can be overridden by the derived classes. This way, specific components can customize behavior without changing the interface.

3. Encapsulation and Modularization

• Encapsulate Variables: Use private (_variable_name) or exported variables to control access. This prevents unintended changes to critical data.
• Signal-based Communication: Use signals for communication between nodes instead of direct function calls. This keeps modules decoupled, making them easier to work on independently.
• Modular Scenes: Break down your game into modular scenes. For instance:
  • Dice as a separate scene.
  • PlayerManager and GameManager as individual scenes.
  • UI Elements as standalone scenes.
  • This makes it easier for different team members to work on different parts of the game without causing conflicts.

4. Scene Inheritance and Prefabs

• Scene Inheritance: Use scene inheritance for repeated structures. For example, if you have multiple types of UI panels with similar layouts, create a base UI panel scene, then inherit and customize it.
• Prefabs: Treat common game components (like buttons, player avatars, etc.) as prefabs. This allows for consistent re-use across the game, reducing redundancy.

5. Separation of Concerns

• Network Logic: Separate the networking logic from game logic. For example:
  • Use a NetworkManager.gd to manage connections, disconnections, and data synchronization.
  • Keep GameManager.gd focused only on managing the gameplay.
• UI Logic: Keep UI-related scripts separate from gameplay logic. Have UI scenes (e.g., scoreboards, pause menus) communicate via signals to the game logic, reducing coupling.

6. Use Design Patterns

• Singletons (Autoloads): Use singletons for game-wide services like managing game settings, saving data, or global state (e.g., SettingsManager or AudioManager). This ensures there's a single point of control for shared resources.
• State Pattern: For managing game states (e.g., "Waiting for Player", "Rolling Dice", "Scoring"), create a state machine. Each state can be a separate class that implements a common interface, making state transitions easy to maintain.
• Factory Pattern: Use a factory pattern for creating objects that have similar structures but need customization (e.g., dynamically generating dice with specific properties).

7. Delegate Responsibilities Using Composition

• Component-based Architecture: Instead of having monolithic classes, break responsibilities into components. For example, a Player could have separate components for managing health, score, and network status.
• This can be done by using Node composition:
  • Attach different Scripts to different Nodes under a parent object to handle specific functionalities.

8. Scripting and Naming Conventions

• Consistent Naming: Use a consistent naming convention for nodes, signals, and scripts so that it's easy for team members to understand what each part of the code does.
• Commenting and Documentation: Document each class and method, detailing its responsibility and usage. This helps new contributors quickly understand what the code is supposed to do.

9. Version Control Best Practices

• Smaller, Independent Scripts: Keep your scripts modular and independent. This reduces merge conflicts since smaller files are easier to work on individually.
• Branch per Feature: Work on separate branches for each feature. Merge frequently and resolve conflicts when they are small.
• Scene Merging: Godot scenes are saved as text files (.tscn), but complex scenes can still lead to conflicts. Keep scenes small and modular so that fewer team members need to modify the same scene at once.

10. Refactor Code for Clarity and Reusability

• Refactor Duplicated Code: If you see repeated logic across different classes or nodes, refactor it into a reusable function or class. The BaseDie example was one such refactor, but look for similar patterns in other parts of your code.
• Service Classes: Create service classes for common functions like dice rolling, score calculation, or network utilities. These can be imported and used anywhere in the project.

Example of Consolidating Game Components

Consider a common structure like the Game Flow Management. You could break it down as:

• GameManager.gd: Manages the overall game flow, such as starting and ending rounds.
• PlayerManager.gd: Manages player-specific data like score and turns.
• DiceContainer.gd: Manages the rolling, re-rolling, and collection of dice.
• NetworkManager.gd: Manages communication between clients in a multiplayer environment.

Each of these scripts is modular, allowing different team members to work independently without stepping on each other's toes.

Signal Example for Decoupling

If PlayerManager needs to notify the UI about score changes:

• PlayerManager.gd:

  signal score_updated(new_score)
  
  func update_score(points: int) -> void:
    score += points
    emit_signal("score_updated", score)

• ScoreUI.gd:

  func _ready() -> void:
    player_manager.connect("score_updated", self, "_on_score_updated")
  
  func _on_score_updated(new_score: int) -> void:
    score_label.text = str(new_score)

This approach keeps the UI loosely coupled with the PlayerManager.

Summary

• Inheritance and Modularization: Use base classes for shared behavior and create derived classes for specialized functionality.
• Separation of Concerns: Split game functionality into distinct, well-defined components.
• Signal-Based Communication: Prefer signals over direct node references to keep modules decoupled.
• Service Classes: Extract common logic into reusable service classes.
• Autoload Singletons: Use them for global services or game-wide state management.
• Document and Use Consistent Conventions: Make the codebase easy to navigate and understand for everyone in the team.

Implementing these principles will make the project more maintainable, flexible, and significantly reduce the risk of merge conflicts, enabling smooth collaboration among team members. Let me know if you'd like a more in-depth guide on any of these principles!

[nigelmoses32]

Working on updating the existing codebase to reflect the above standards as soon as possible (with priority given to 4X03 cause we don't want to fail lol), but hopefully, this will help with us working together and being able to assign issues (features/bugs) to individual people without worry about merge conflicts

[nigelmoses32]

Part of implementing code this way, I should be creating template scripts or blank methods in scripts for the rest of the team to implement specific functionality, which should make it easier to pick up a feature or bug, assign it to yourself and read where the code should be implemented and start working

[nigelmoses32]

When creating and organizing scripts in the hierarchy, there is a principle I'm trying to follow which seems sound. The Parent node, which is either the scene node or the gameManager for example, has direct references to the components under it (Like scoreboard, dice container, UI, and so on) and handles initializing if needed. Then when running, the parent can call functions in the child to affect the state of the child, but the child will only use signals for any communication back to the parent, which the parent will be connected to and looking for. This way the child nodes handle specific functionality and can be tested independantly with out need a lot of additional infrastructure