Multi Fuse Box: Per section, and/or per appliance type, plus general fuse

[deavid]

Feature: Stimulating Exploration - Multi Fuse Box Mechanic

Description:

Expand the existing Fuse Box mechanic to allow for multiple fuse boxes per location, controlling different sections of the map or specific appliance types. This will provide more strategic depth, realism, and complexity to the power management gameplay. The base fusebox is already operational.

Goals:

• Implement Hierarchical Fuse Boxes:

  • Allow for multiple fuse box entities per map.
  • Implement per-section, per-appliance-type, and general fusebox controls.

• Allow for new types of devices that can be wired to the fusebox:

  • • Provide the ability to define types of power consumers (e.g., "Lights," "Appliances," "Wing A").
  • • Make it possible to assign a type to a device.
  • • Define the devices connection in the configuration properties: - General: Default (All-encompassing) - Type: Grouped by device type (e.g., "Lights") - Section: By a specific area, controlled by a specific fusebox (e.g., "Wing A")

• Allow for different fuse box properties:

  • • Implement per-fusebox capacity (in "kW" or a similar abstract unit).
  • • Implement each fusebox as an entity.

• Extend the ghost event:

  • Implement a new ghost event to be able to blow the fuse on a rare basis, including which fuse box.

• Ensure Extensibility: The design should be flexible enough to accommodate new appliance types, map layouts, and ghost event interactions.

Implementation Details (Potential Tasks):

• 1. Refactor Existing Fuse Box System:
  • Refactor the existing FuseBox resource to support multiple instances.
  • Adapt the existing code to handle multiple PoweredDevice components correctly.
  • Modify or create a new component to represent a fuse box's configuration.
  • Refactor existing systems to include logic for per section and appliance type, add a property in Behavior.
  • Create new systems if required.
• 2. Data Structures & Components:
  • Update the PoweredDevice component to incorporate information about the devices' type, and what fuses are wired to it (general, specific, etc).
  • Create new components if required
• 3. Map Configuration:
  • Update the map loading system to handle the configuration for multi-fuseboxes, and also the connection of the devices.
  • In the tilemap properties, add fields related to the power consumption of a device and its connected fuse box.
• 4. User Interface:
  • Modify the Journal UI (or Loadout UI, depending on design) to display which devices are connected to what fuse boxes and the amount of power.
  • If applicable, the journal UI needs to update to reflect if the player has the knowledge of what each fusebox does.
• 5. Ghost Interactions:
  • Update the ghost's event system to specify which fuse box to target (or target a random fuse box).
  • In the case of a more advanced ghost, let it to manipulate devices, allowing it to set particular levels of power to them.
• 6. Testing:
  • Comprehensive testing to confirm the correct functionality of multiple fuse boxes.
  • Test for interactions between different sections/appliances and the ghost events.

Dependencies:

• Existing player state and action systems (stamina, health, etc.).
• The game's audio system.
• The existing Fuse Box mechanic.
• The existing player, map, and camera systems.
• Game assets.

Acceptance Criteria:

• Multiple fuse box entities can be placed on a map, with different power capacities.
• Power consumers can be assigned to different fuse boxes.
• When a fuse box is overloaded, only the devices connected to that fuse box are affected.
• The ghost can trigger events that selectively affect different fuse boxes.
• The UI displays power consumption and the state of each fuse box clearly.
• The game is stable, and no errors are generated when using the new system.

Notes:

• This feature significantly increases the complexity of the power management system.
• This can be extended to allow for special actions, such as enabling a generator or the van.
• The initial implementation should focus on the core functionality and extensibility. The UI can be designed later.