Skip to content

README.md

Latest commit

 

History

History
137 lines (92 loc) · 3.63 KB

README.md

File metadata and controls

137 lines (92 loc) · 3.63 KB
SimAnalyzer logo

SimAnalyzer

Telemetry-first desktop app for sim racing.
Built with Kotlin Multiplatform + Compose Desktop.

Kotlin Multiplatform Compose Multiplatform License

Compose Desktop (Windows)

Important

Project status: active development.
Platform focus: Desktop (Windows-first runtime).

What SimAnalyzer is

SimAnalyzer reads telemetry from racing simulators, shows live HUD panels, records sessions, and provides post-session analysis.

Planned product scope (TODO - fill later):

  • TODO: Live telemetry HUD capabilities
  • TODO: Session recording capabilities
  • TODO: Post-session analytics capabilities
  • TODO: Supported simulators and integrations

Start here (priority order)

  1. Run the app
./gradlew :composeApp:run

  1. Understand module boundaries (api vs impl)

  2. Understand build conventions (moduleApi, moduleImpl, app)

  3. Only then deep-dive into feature modules

Requirements

  • JDK 21
  • Gradle Wrapper (./gradlew)

Quick setup

git clone https://github.com/dev-darck/SimAnalyzer.git
cd SimAnalyzer
./gradlew :composeApp:run

Module map

Top-level module groups:

  • :composeApp - desktop app entry point
  • :core:* - shared app infrastructure (DI, navigation, telemetry, theme, utils)
  • :feature:* - screens and HUD features
  • :games:* - game-specific integrations (AC, LMU)
  • :ksp:* - custom code generation tooling
  • build-logic - Gradle conventions + project DSL

Most domains follow this split:

  • */api - contracts and stable surface
  • */impl - concrete implementation

Examples:

  • :core:di:api + :core:di:impl
  • :games:game:api + :games:game:impl
  • :feature:screens:session:api + :feature:screens:session:impl

moduleApi vs moduleImpl

The repo uses DSL helpers from build-logic:

  • moduleApi { ... }
  • moduleImpl { ... }
  • app { ... }

moduleApi

  • KMP library conventions
  • Kotlin explicit API enabled
  • used for public contracts

moduleImpl

  • same KMP base conventions
  • explicit API not enforced
  • used for implementation details

Rule of thumb: put interfaces/models in api; put behavior/wiring in impl.

Dependency DSL shortcuts

Inside module DSL, dependencies are source-set aware:

  • commonImpl
  • jvmImpl
  • jvmTest
  • commonTestImpl

Example:

dependencies {
    projects.core.di.api.jvmImpl
    projects.core.di.impl.jvmImpl
    lib.metro.runtime.jvmImpl
}

DI style

  • bindings live in di packages
  • ViewModels are multibound via @IntoMap + @ViewModelKey
  • prefer clean module boundaries over direct cross-feature coupling

Build logic note

build-logic/conventions/src/main/kotlin/convention-project-dsl.gradle.kts can be intentionally empty.
It acts as a marker precompiled script plugin that exposes the DSL across all modules.

License

Apache License 2.0