79 lines
5.9 KiB
Markdown
79 lines
5.9 KiB
Markdown
|
|
||
|
|
## Development Progress Report 14/10 - 25
|
||
|
|
### Overview
|
||
|
|
The project has successfully undergone a foundational architectural refactor. The legacy monolithic Spaceship class has been deprecated in favor of a fully modular, component-based architecture designed for multiplayer scalability. The core gameplay loop of a player spawning, possessing a character, using a station, and controlling a ship's systems via a diegetic UI is now functional. The project is now entering "Cycle 2" of development, focusing on unifying the physics system and migrating the remaining legacy gameplay logic into the new architecture.
|
||
|
|
|
||
|
|
### ✅ Implemented Systems & Features
|
||
|
|
#### 1. Core Architecture
|
||
|
|
Modular Ships: Ships are now built around a root Module class which extends OrbitalBody2D. The Module dynamically understands its structure by finding its Component and StructuralPiece children, removing the need for rigid container nodes.
|
||
|
|
|
||
|
|
Custom Physics Body: The OrbitalBody2D class serves as the base for all physical objects in the simulation, including ship parts and modules. It correctly handles force routing from child components to the root physics body and includes a robust, deferred check to warn if a child class forgets to call super() in its _ready function.
|
||
|
|
|
||
|
|
Dynamic Inertia Calculation: The ship's moment of inertia is now calculated realistically based on the mass and distribution of all its component parts in local space, leading to more authentic rotational physics.
|
||
|
|
|
||
|
|
#### 2. Player Control & Multiplayer Foundation
|
||
|
|
PlayerController/Pawn Architecture: A multiplayer-ready control scheme has been implemented.
|
||
|
|
|
||
|
|
The PlayerController class is responsible for capturing raw input and sending it to the server via RPCs.
|
||
|
|
|
||
|
|
The PilotBall (the "Pawn") is now a "dumb" character that only acts on commands received from its controller, with all direct calls to the Input singleton successfully removed.
|
||
|
|
|
||
|
|
Dynamic Spawning & Possession: The GameManager now manages the game's startup sequence. It dynamically spawns a PlayerController and a default ship (Tube.tscn), and then correctly "possesses" the PilotBall within the ship with its corresponding controller.
|
||
|
|
|
||
|
|
Local Server Initialization: The GameManager correctly initializes a local ENet server, which enables the multiplayer authority system (is_multiplayer_authority()) to function correctly in a single-player testing environment.
|
||
|
|
|
||
|
|
#### 3. Station & UI Systems
|
||
|
|
Modular UI Framework: The "databank" system has been fully implemented and separated into three distinct resource types:
|
||
|
|
|
||
|
|
ControlPanel: A resource representing a physical UI element (e.g., a screen, a lever).
|
||
|
|
|
||
|
|
Databank: A resource representing a "datashard" which contains pure logic in a script.
|
||
|
|
|
||
|
|
SystemStation: The physical station component that acts as a "chassis," hosting panels and databanks.
|
||
|
|
|
||
|
|
Persistent Station Logic: The SystemStation has been refactored to instantiate datashard logic (_ready) once for its entire lifetime, allowing for background processing. UI Panels are created ephemerally only when a player occupies the station.
|
||
|
|
|
||
|
|
Functional Helm: The helm is partially migrated.
|
||
|
|
|
||
|
|
A HelmLogicShard contains the attitude-hold (PD controller) and calibration logic.
|
||
|
|
|
||
|
|
ControlPanels for a throttle lever, buttons, and a status readout are functional.
|
||
|
|
|
||
|
|
The station correctly wires the panels to the helm shard at runtime, allowing the player to control the ship's main engine and RCS thrusters.
|
||
|
|
|
||
|
|
Functional Sensor Display: The sensor/map system is partially migrated.
|
||
|
|
|
||
|
|
A SensorSystemShard is responsible for gathering all trackable bodies in the system.
|
||
|
|
|
||
|
|
A refactored SensorPanel acts as a "dumb" display that visualizes the "sensor feed" signal it receives.
|
||
|
|
|
||
|
|
The ShipStatusShard correctly displays the ship's velocity and rotational data on the ReadoutScreen and also displays the currently selected target from the map.
|
||
|
|
|
||
|
|
### ❌ Not Yet Implemented / Pending Tasks
|
||
|
|
#### 1. Physics & Simulation (Cycle 2 Priority)
|
||
|
|
|
||
|
|
CelestialBody Refactor: All celestial bodies (Planets, Moons, etc.) still inherit from Godot's RigidBody2D and use the _integrate_forces callback. They must be refactored to extend our custom OrbitalBody2D to create a single, stable physics simulation.
|
||
|
|
|
||
|
|
Astronomical vs. Ship Scale: A system for scaling forces needs to be designed and implemented to allow massive planets and lightweight ships to coexist and interact realistically within the same simulation.
|
||
|
|
|
||
|
|
Simulation Stability Test: The proposed GhostSimulator and test runner for verifying long-term orbital stability has not yet been created.
|
||
|
|
|
||
|
|
Interior Physics: The simulation does not yet account for how the ship's acceleration affects characters or loose objects inside it.
|
||
|
|
|
||
|
|
#### 2. System & Feature Migration
|
||
|
|
|
||
|
|
Full Helm/Nav Migration: The complex maneuver planning logic (e.g., Hohmann transfers) still resides in the legacy navigation_computer.gd script and needs to be migrated into one or more Databank shards.
|
||
|
|
|
||
|
|
Thruster Refactor: The Thruster component still uses a simple turn_on()/turn_off() model. It needs to be refactored to accept a variable set_throttle(value) command for more precise control.
|
||
|
|
|
||
|
|
Retirement of Legacy Scenes/Scripts: The old Spaceship.tscn, spaceship.gd, thruster_controller.gd, and navigation_computer.gd files are still in the project and need to be fully removed once their logic is migrated.
|
||
|
|
|
||
|
|
#### 3. Planned Features (Future Cycles)
|
||
|
|
Wiring System: The foundational classes exist, but the in-game system for players to visually wire panels to databanks, and the editor tools to support this, have not been started.
|
||
|
|
|
||
|
|
Character & Movement: The current PilotBall is a placeholder. The planned humanoid character, grapple points, and EVA gameplay are not yet implemented.
|
||
|
|
|
||
|
|
Core Gameplay Systems: The foundational systems for Electricity, Life Support (pressurization), Fuel, Character Damage, and Inventory/Pickupable Objects have not yet been created.
|
||
|
|
|
||
|
|
Multiplayer Connectivity: While the architecture supports it, the UI and logic for multiple players to connect to a server (e.g., a main menu with a "Join Game" option) do not yet exist.
|