89 lines
5.0 KiB
Markdown
89 lines
5.0 KiB
Markdown
|
# Development Status Report - 2025-11-21
|
||
|
|
|
||
|
|
## Overview
|
||
|
|
|
||
|
|
Significant progress was made on the Unified Build System and the In-Game Builder, moving away from purely editor-based construction. We successfully implemented procedural geometry generation for structural pieces and refactored the snapping logic to support the upcoming geodesic structures. Networking logic also saw crucial stability fixes.
|
||
|
|
|
||
|
|
## Completed Features & Implementations
|
||
|
|
|
||
|
|
### 1. Unified Build System Foundation
|
||
|
|
|
||
|
|
- StructureData Resource: Implemented a robust resource-based definition system for ship parts. This decouples the "DNA" of a part (mesh, collider, mounts, health) from its scene instantiation, allowing shared logic between the Editor Plugin and the In-Game Builder.
|
||
|
|
|
||
|
|
- PieceMount Logic: Formalized attachment points into a dedicated PieceMount class (inheriting Area3D). This replaced the ad-hoc dictionary system, providing type safety and better collision filtering.
|
||
|
|
|
||
|
|
- ProceduralPiece Generator: Created a script that dynamically generates 3D meshes and collision shapes based on parameters (e.g., triangle vs. square, size, thickness) defined in StructureData. This supports:
|
||
|
|
|
||
|
|
- Extruded 3D geometry (thickness) rather than flat planes.
|
||
|
|
|
||
|
|
- Convex collision hull generation.
|
||
|
|
|
||
|
|
- "Opaque Blueprint" preview materials (semi-transparent, emissive).
|
||
|
|
|
||
|
|
### 2. In-Game Builder (PlayerController3D)
|
||
|
|
|
||
|
|
- Build Mode State: Implemented a toggleable Build Mode (B key) in PlayerController3D.
|
||
|
|
|
||
|
|
- Piece Selection: Added logic to select pieces via hotkeys (1 = Square, 2 = Triangle), instantiate a preview "ghost," and switch its material.
|
||
|
|
|
||
|
|
- Raycast Snapping: Implemented a physics-based raycast/sweep to detect existing ship modules and mounts.
|
||
|
|
|
||
|
|
- Visual Feedback: Added color-coded feedback for the preview ghost:
|
||
|
|
|
||
|
|
- Cyan: Floating (no snap target found).
|
||
|
|
|
||
|
|
- Geen: Snapped (aligned with a valid mount).
|
||
|
|
|
||
|
|
### 3. Snapping Logic Refactor
|
||
|
|
|
||
|
|
- SnappingTool Class: Created a dedicated static helper class for snapping math.
|
||
|
|
|
||
|
|
- Shape Cast Sweep: Replaced simple raycasting with a sphere_cast (radius 0.2m). This adds "thickness" to the cursor, making it much easier to hit thin structural elements like struts or small mounts.
|
||
|
|
|
||
|
|
- Transform Alignment: Implemented matrix math to align a new piece's mount with a target mount, respecting position, normal (facing direction), and up-vector (roll/orientation).
|
||
|
|
|
||
|
|
### 4. Networking Stability (Previous Session)
|
||
|
|
|
||
|
|
- Server Authority Enforcement: enforced strict server authority on CharacterPawn3D, removing client-side overrides that caused "fighting" and stutter.
|
||
|
|
|
||
|
|
- Relative Velocity Sync: Implemented logic to sync local_velocity relative to the parent ship instead of global velocity. This prevents pawns from "falling out the back" of moving ships during network jitter.
|
||
|
|
|
||
|
|
- Input Serialization: Fixed RPC errors by converting custom KeyInput objects to Dictionaries before transmission.
|
||
|
|
|
||
|
|
## Pending / In-Progress
|
||
|
|
|
||
|
|
- Mount Orientation Constraints: The snapping tool currently aligns normals but needs refinement to strictly enforce edge length compatibility and specific mount types (e.g., preventing a 2m edge from snapping to a 1m edge).
|
||
|
|
|
||
|
|
- Module Persistence: The logic for creating a new Module when building in empty space works in memory but needs testing for persistence and saving.
|
||
|
|
|
||
|
|
- Collision Layers: Need to verify that all PieceMount nodes are consistently on the correct physics layer (1 << 14) to ensure the snapping sweep always finds them.
|
||
|
|
|
||
|
|
## Discussion & Direction Changes
|
||
|
|
|
||
|
|
### Shift to "Geodesic & Procedural" Building
|
||
|
|
|
||
|
|
We moved away from the initial "Voxel Grid" concept for ship hulls.
|
||
|
|
|
||
|
|
- Old Direction: Ships built on a strict integer grid (Minecraft-style but with slopes).
|
||
|
|
|
||
|
|
- New Direction: A node-based "Geodesic" system. Pieces connect Node-to-Node (Mount-to-Mount) at arbitrary angles. This allows for complex shapes (hexagonal cylinders, spheres, rings) and supports the "Industrial/Hard Sci-Fi" aesthetic better.
|
||
|
|
|
||
|
|
- Implication: The building tool no longer relies on grid_step for positioning. It relies entirely on the SnappingTool to calculate transforms based on the geometry of the mounting points.
|
||
|
|
|
||
|
|
### Shift to "Server Authoritative" Networking
|
||
|
|
|
||
|
|
We abandoned the "Client Authoritative" movement for pawns to solve synchronization issues.
|
||
|
|
|
||
|
|
- Old Plan: Client moves pawn, Server accepts pos. (Caused hacking risks and desync with physics objects).
|
||
|
|
|
||
|
|
- New Plan: Server simulates physics. Client sends inputs. MultiplayerSynchronizer interpolates the result. To combat latency feel, we are using Visual Interpolation (detaching camera/mesh from the physics body) rather than full Client-Side Prediction (CSP) for this milestone.
|
||
|
|
|
||
|
|
### Manufacturing & Blueprints
|
||
|
|
|
||
|
|
We discussed that the StructureData resource is the key enabler for the manufacturing gameplay loop. By defining parts as data (Resources), we can easily:
|
||
|
|
|
||
|
|
1. Store a "Blueprint" as a list of StructureData references + Transforms.
|
||
|
|
|
||
|
|
2. Have a manufacturing machine consume resources to produce a "Crate" containing a StructureData item.
|
||
|
|
|
||
|
|
3. Have the player pick up that item and use it to place the ProceduralPiece.
|