Dated source reference. Current release status: handoff state. Full original relative paths are in the developer archive.
OpenHoops deep-customization approach
Current internal handoff: CURRENT-STATE. Earlier dated research/checkpoint statements below retain their original source versions.
Current implementation checkpoint (October15,2026): API0.2.0.dev36/ABI14,eventABI4,collegeprofile4,courtdefinition3. See the current contract and verification for delivered features and limits. Agreed college mechanics and reference regulation/OT exports are implemented; direct roster/team launch and arbitrary extension callbacks remain future work. Extra production watching and rare live reproductions are deferred; public release packaging is not requested. Research/proposal sections below do not override this checkpoint.
Decision updated October 13, 2026. The user selected deep edits to the existing game instead of full decompilation/recompilation, with Windows first and Mac/Linux compatibility later. This is the adopted direction. See scope and implementation plan.
Architecture
The original NBA 2K14 engine remains the playable simulation and content runtime. OpenHoops owns a version-aware integration adapter, a public API, external identities and mode data, and selected replacement behavior where a verified engine boundary allows it. Decompilation is a targeted analysis technique, not a whole-game delivery requirement.
flowchart TD
CLIENTS[Independent dynasty, career, scoreboard and mod tools] --> API[Versioned OpenHoops API and companion broker]
API --> ADAPTER[Verified Windows x86 adapter]
RULES[Selected in-process rule and presentation modules] --> ADAPTER
ADAPTER --> GAME[Original NBA 2K14 simulation]
GAME --> WINDOWS[Windows first]
GAME -. later validation .-> OTHER[macOS and Linux compatibility stacks]
This diagram includes both implemented API infrastructure and planned rule/launch/presentation extensions. It does not claim all modules are complete.
What customization must provide
| Surface | Contract |
|---|---|
| External modes | Any tool can own its league/career state and submit supported match/roster configuration; no dependency on one first-party manager |
| Live API | Stable external identities, typed state, verified event meanings, explicit unknowns/gaps, reconnect and revision behavior |
| Final exports | Reconciled team/player/period totals, immutable revisions, consumer-specific acknowledgements and no accidental completion after a crash/quit |
| Rules | Verified decision points and dependency handling for clocks, possession, fouls, awards, stats, AI and presentation; parameter writes alone are not complete rule implementations |
| Presentation | Custom scoreboards and interfaces consume the public model; renderer/device lifetime, input and asset invalidation are explicit |
| Editing | Supported roster/asset intake, version checks, reversible deployment, preserved originals and save compatibility |
Use named game concepts at the public boundary. The supported executable hash and private addresses belong inside the adapter. A native or64-bit companion does not change the original game's32-bit process. Large external leagues can use stable external IDs and stage current participants into supported game slots; that route still needs implementation and validation.
Network requests must not block frame-critical engine decisions. A broker serves HTTP/JSON and SSE; small bounded in-process modules perform authoritative changes at verified engine points. Preserve baseline behavior as a regression reference. Hot reload must be specified separately for textures, UI, models and other resources; unsupported classes may require the next match.
Windows first, compatibility later
Develop and verify the full supported Windows workflow before making Mac/Linux game execution an active workstream. Keep protocol and client/core code portable where practical. Later choose the compatibility/translation layer and rendering backend based on measured game-and-adapter behavior. Compatibility is a valid product delivery route under the current goal; it must be described honestly rather than called a rewritten native game.
The existing D3D9 renderer can remain. A Vulkan/Metal/OpenGL replacement is not a prerequisite for exposing stats, external modes or rule edits. Targeted renderer work is justified when a supported presentation feature needs it or later platform tests demonstrate a blocker.
Cross-platform acceptance concerns the supported gameplay/API/rules, roster/save/result behavior, input, audio and presentation scenarios. Matching source or reaching a menu is insufficient, and bit-identical GPU output or deterministic play across all hardware is not assumed.
When targeted reconstruction is justified
Replace a bounded routine or subsystem when hooks alone cannot expose a reliable decision boundary, a capacity limit blocks a requested feature, or coordinated patches become too fragile. Require named inputs/outputs, baseline comparisons and intended-rule tests. Do not turn a local limitation into an automatic full-engine rewrite. A standalone source port would require a separate future scope decision.
Evidence and historical research
The October12 comparative research, primary-source citations, community-mod findings, recompilation constraints and original platform observations are preserved in the superseded strategy snapshot. Its full-native completion requirement and migration roadmap are no longer active. External source archives and hashes remain unchanged in resources/approach-research/ and analysis/approach/.
Current implementation and limits: API contract, public requirements, integration evidence and Windows plan. No broad hook capability, arbitrary rule support or Mac/Linux compatibility is implied by the architectural direction.