Skip to main content

πŸš€ ARCLUX β€” Vessel Design, Visual Governance & 3D Design Dashboard

Design Proposal β€” User-generated vessels with creative freedom, coherent visual identity, content safety, and real-time 3D authoring.
Bagian dari blueprint ARCLUX (Repository War Universe).

1. Vision

ARCLUX memungkinkan repository menjadi source of truth bagi sebuah vessel. Developer tidak sekadar mendapatkan statistik atau graph, tetapi dapat melihat repository mereka berkembang menjadi living spacecraft.
ARCLUX menyediakan engine, world rules, validation, dan canvas. Developer menyediakan repository, architecture, components, dan kreativitas. Β«One engine. Infinite vessels.Β»

2. Core Design Principle

ARCLUX tidak boleh menyeragamkan seluruh vessel menjadi satu model kapal. Setiap repository dapat menghasilkan vessel dengan karakteristik berbeda.
Perbedaan tersebut merupakan bagian dari identitas ARCLUX. Namun kebebasan tersebut tetap berada dalam ARCLUX Visual Language. Β«Protect the universe’s identity, not its creativity.Β»

3. Creative Freedom

User dapat membuat vessel yang:
  • asymmetrical
  • modular
  • geometric
  • alien-inspired
  • experimental
  • compact
  • gigantic
  • highly specialized
  • unconventional
ARCLUX tidak menentukan bahwa semua vessel harus memiliki silhouette yang sama. Contoh evolusi:

3.1 Creative Freedom vs Engineering Reality

Kebebasan desain tetap dijunjung, namun ARCLUX membedakan creative implementation dengan arbitrary technical hallucination. ARCLUX tidak menolak desain eksperimental. Tetapi setiap komponen harus mampu menjelaskan perannya dalam konteks engineering yang realistis:
Sistem komponen kapal mengikuti model dunia nyata (cross-ref 01 Β§2.6 hukum fisika & thermal):
  • STRUCTURAL β€” hull, integrity, component mounting
  • PROPULSION β€” main propulsion, maneuvering, control interface
  • POWER β€” energy source, distribution, emergency power
  • THERMAL β€” heat generation, heat transfer, thermal limits
  • NAVIGATION β€” orientation & navigation capability
  • DEFENSE β€” protection systems
  • DAMAGE CONTROL β€” response & recovery
Prinsip: desain sesuka hati diizinkan, tetapi komponen yang menyimpang dari model fisik/mekanis realistis tidak lolos validasi. Kapal adalah engineering, bukan asal jadi.

4. ARCLUX Visual Language

Walaupun desain bebas, vessel public harus tetap memiliki spacecraft identity. Prinsip visual:
Tujuannya bukan membuat semua kapal terlihat sama. Tujuannya membuat kapal yang berbeda tetap terasa berasal dari universe yang sama.

5. Visual Governance

Karena vessel dibuat oleh user, ARCLUX membutuhkan visual/content governance. Governance digunakan untuk menjaga:
  • reputasi ARCLUX
  • kualitas public universe
  • visual consistency
  • community safety
  • platform integrity
ARCLUX harus mencegah desain yang sengaja dibuat untuk:
  • explicit sexual content
  • sexually suggestive representations
  • hateful/extremist imagery
  • intentionally offensive imagery
  • konten lain yang dilarang oleh community policy
Desain yang sekadar aneh atau eksperimental tidak otomatis ditolak.

6. Public vs Private Vessel

ARCLUX dapat membedakan antara development lokal dan public universe. Private / Local β€” Developer mendapatkan ruang eksperimen yang lebih luas.
Public β€” Vessel harus melewati validation.
Dengan demikian experimentation tidak harus berarti setiap desain langsung menjadi bagian dari public universe.

7. Vessel Validation Pipeline

Validation harus membedakan:
  • unusual design
dengan
  • intentionally inappropriate design.

7.1 ARCLUX Universal Baseline (baseline yang tidak bisa dihapus)

Setiap repository kapal berisi kode universal ARCLUX di bagian awal, yang TIDAK BISA DIHAPUS/diubah inti oleh pemain. Ini yang membuat sebuah repo dapat β€œmenjadi kapal” dan β€œbisa angkasa” β€” baseline yang menjamin:
  • Imun gravitasi (01 Β§2.6): kapal tidak ditarik gravitasi skala system.
  • Sistem dasar kapal (identitas, baseline stat, kerangka).
  • Validasi wajib: tanpa baseline ini, repo TIDAK diterima sebagai vessel (connectRepository D-007 menolak / FLAG).
Pemisahan ini penting: konten kapal = kreativitas user (poin 3 Creative Freedom), baseline = fondasi universal ARCLUX yang konsisten untuk semua pemain, dan menjadi level β€œpenyangga” yang sama. Dalam validasi pipeline, baseline divalidasi sebagai bagian β€œTECHNICAL VALIDATION” β€” kehilangan/kerusakan baseline (dampak kerusakan kapal, lihat 06 Β§18.5) berarti kapal β€œhilang kemampuan angkasa/dasar”. Baseline ini tidak hanya memberikan identitas β€” ia juga membawa bahasa engineering bersama (Vessel Engineering Quickstart): struktur component yang realistis, dependency antar subsystem, dan titik awal canonical blueprint. Dengan demikian pemain baru tidak perlu mulai dari repository kosong dan menebak-nebak seluruh arsitektur kapal (lihat Β§21 Canonical Vessel Model).

8. Automated Visual Validation

ARCLUX dapat menggunakan beberapa signal:
Hasil:
Automated moderation sebaiknya menjadi first layer, bukan satu-satunya mekanisme.

9. Community Reporting

Public universe dapat menyediakan reporting system.
Possible actions:
  • approve
  • request redesign
  • temporarily hide
  • restrict visibility
  • reject

10. 3D Vessel Design Dashboard

ARCLUX membutuhkan 3D Vessel Design Dashboard sebagai visual bridge antara repository dan vessel. Dashboard bukan game editor biasa. Dashboard adalah: Β«Real-time authoring + inspection + preview environment.Β»

11. Dashboard Layout


12. 3D Canvas

Canvas menjadi pusat visual development. Fitur:
  • orbit camera
  • pan
  • zoom
  • rotate
  • focus selected component
  • reset camera
  • free camera
  • cinematic camera
  • grid/spatial reference
  • selectable components
  • subsystem highlighting
Contoh shortcuts:
(Usulan shortcut β€” dapat dikonfigurasi pada tahap berikutnya.)

13. Component Selection

Setiap component dapat dipilih langsung dari 3D vessel.
Ini membuat hubungan:
menjadi eksplisit.

14. Code ↔ Vessel Navigation

ARCLUX harus memungkinkan navigasi dua arah. Vessel β†’ Code
Code β†’ Vessel
Developer dapat memahami software architecture melalui dua representasi:
  • code representation
  • spatial representation

15. Visual Configuration

User dapat mengontrol aspek visual vessel melalui .arclux/ dan dashboard. Contoh:
Visual customization tidak boleh menjadi sumber authoritative gameplay statistics.

16. Lighting System

Lighting menjadi bagian dari visual layer. User dapat menentukan style lighting vessel:
  • hull illumination
  • engine glow
  • navigation lights
  • subsystem indicators
  • emissive components
  • interior/exterior lighting
  • decorative lights
ARCLUX tetap dapat menetapkan technical constraints seperti:
  • effect budget
  • light count
  • performance limits
  • mobile rendering profile
Dengan demikian:

17. Real-Time Preview

Perubahan .arclux/ atau visual configuration dapat dipreview secara langsung.
Developer tidak perlu membangun seluruh application hanya untuk melihat perubahan vessel.

18. Design Modes

Dashboard menyediakan beberapa mode. DESIGN
INSPECT
COMBAT PREVIEW
HISTORY

19. Damage Preview

Developer dapat mensimulasikan damage dalam sandbox.
3D representation kemudian berubah sesuai subsystem state. Contoh:
Preview tidak mengubah real world-state.

20. Visual vs Simulation Separation

Ini harus menjadi architectural boundary.
Mengubah mesh, lighting, atau particle effect tidak boleh meningkatkan:
  • damage
  • armor
  • defense
  • weapon capability
  • combat authority

21. Canonical Vessel Model

ARCLUX harus memiliki canonical representation sebelum vessel dipublish.
Client hanya menggambar validated representation. Dengan demikian visual client tidak dapat digunakan untuk mengubah authoritative state.

21.1 Canonical Blueprint β‰  Final Vessel

Canonical vessel model bukan kapal jadi β€” ia adalah engineering foundation. Setiap vessel dapat dimulai dari canonical blueprint universal (Vessel Engineering Quickstart, cross-ref Β§7.1 gambaran baseline).
SAME FOUNDATION β‰  SAME VESSEL. Satu blueprint dapat menghasilkan ribuan desain. Engineer bebas:
  • mengubah arsitektur & redundancy
  • membuat sistem modular
  • mengembangkan komponen baru
  • membuat konfigurasi khusus
  • mengoptimalkan subsystem
  • menciptakan teknologi komunitas
Selama berada dalam batas: world rules + technical validation + component constraints (cross-ref Β§3.1). Progressive engineering membantu pemain belajar bertahap (Foundation β†’ Systems β†’ Architecture β†’ Advanced) tanpa harus menguasai seluruh arsitektur dalam satu hari.

22. Rendering & Performance

Visual freedom tetap harus mempertimbangkan hardware. HIGH-END PC
MOBILE
Simulation tidak bergantung pada FPS. Β«Graphics quality changes the presentation, not reality.Β»

23. Git-Native Design Workflow

Vessel design tetap mengikuti filosofi Git.
Dashboard dapat menyediakan comparison:
Developer dapat melihat konsekuensi perubahan sebelum commit. Setiap evolusi vessel tetap dapat dilacak melalui Git, dan Git History menjadi jembatan antar lapisan:
Contoh garis waktu generasi:
Repository adalah catatan evolusi engineering kapal (cross-ref 08 Β§6 & Β§16 untuk incident/service history pada sisi dunia).

24. Visual History

Setiap validated vessel state dapat dikaitkan dengan repository history.
Perubahan dapat dibandingkan berdasarkan:
  • silhouette
  • components
  • subsystem state
  • visual configuration
  • architecture
  • health

25. Design Evolution

Vessel tidak harus statis. Repository yang berkembang dapat menghasilkan vessel yang berevolusi.
Dengan demikian vessel menjadi representasi visual dari living software project. Evolusi membentuk engineering loop yang berkelanjutan:
Tidak ada β€œfinal perfect vessel”. Setiap iterasi adalah generasi baru yang membawa pelajaran dari generasi sebelumnya (cross-ref 08 Β§16 Persistent Consequence Loop & 04-wreckage-history).

26. Proposed Architecture

Validation layer:

27. Core Philosophy

ARCLUX tidak perlu membuat ribuan vessel secara manual. ARCLUX menyediakan:
Developer menyediakan:
Hasilnya: Β«One engine. Infinite vessels.Β» Dan governance memastikan: Β«Infinite creativity does not require infinite chaos.Β»