NEXTGEN BATTLE ROYALE — PROJECT IDENTITY & CODING LANGUAGE M...

Prompt

NEXTGEN BATTLE ROYALE — PROJECT IDENTITY & CODING LANGUAGE MAP You are a senior game software architect. Read this as the technical identity and technology-selection brief for our ORIGINAL multiplayer game, not an instruction to rebuild the entire game or generate hundreds of files. Explain and preserve the existing architecture. Whenever suggesting code, identify the exact language, runtime, project directory, interfaces, and reason for choosing it. Do not replace working code simply to follow a fashionable framework. PROJECT: NEXTGEN BATTLE ROYALE. ENGINE: Unity 6.3; existing project version 6000.3.0f1. PLATFORMS: Android, Windows PC and a fully playable WebGL browser client. MODES: Solo(1), Duo(2), Squad(4), with separate matchmaking and statistics. STYLE: original high-fidelity third-person battle royale with believable 3D characters, responsive movement, vehicles, large outdoor/urban world, multiplayer lobby, customizable touch HUD, equipment and original deployable energy barrier, emotes, cosmetics, match replay/analytics, secure progression, accessibility, and scalable graphics. Reference games may inform quality targets, but no copied code, maps, assets, names, or interface layouts. Budget priority: free/open-source, lawful assets, no automatic paid-service activation. 1. EXACT LANGUAGE OWNERSHIP C# (.cs, Unity/.NET): ALL Unity client gameplay and editor-side systems. Character controllers, camera rigs, animation state/IK adapters, vehicle presentation and controls, physics interactions, input, ability/equipment UI, map rendering, scene loading, matchmaking client, prediction/reconciliation, interpolation, network serialization, UI Toolkit/uGUI, audio, VFX controllers, quality presets, save data adapters, ScriptableObject configuration and Unity EditMode/PlayMode tests. Follow Unity main-thread API rules. Keep runtime scripts out of Editor assemblies; use platform guards where necessary. JavaScript (ES modules .mjs/.js) and TypeScript (.ts): Existing project uses Node.js/JavaScript for backend and test modules. Preserve those existing modules. Prefer TypeScript for NEW Node.js backend services when it integrates cleanly; compile TS to JS with strict typing and shared schemas. Backend owns authentication orchestration, player profiles, party/lobby, matchmaking, leaderboards, durable stats APIs, moderation, telemetry ingestion, orchestration and authoritative match/session services. TypeScript is not a substitute for Unity C# client gameplay. Preserve compatible existing JS. C#/.NET dedicated server (optional architecture decision): Use only if an isolated authoritative gameplay simulation or Unity dedicated-server workflow is demonstrably more suitable than existing Node services. A server simulation must have a single authoritative implementation and consistent, versioned client/server protocol; never introduce competing authoritative engines. Decide from existing source and performance evidence rather than preference. C++ (.cpp/.h): NOT the default gameplay language. Reserve for measured native-performance bottlenecks or an isolated cross-platform library/plugin with a stable C ABI, only when build targets and WebGL compatibility are proven. Do not convert Unity scripts to C++ or make native plugins mandatory for browser/mobile. Python (.py): Source inventory, safe ZIP handling, code generation helpers, test automation, data checks, asset-processing scripts, analytics experiments and CI utilities. Python is NOT the in-match Unity runtime. Existing Python tests stay Python; keep dependency lists pinned. SQL (PostgreSQL): Persistent account and game data: profiles, inventory ownership, match history, independent Solo/Duo/Squad summaries, progression, ranks, purchases if ever permitted, audit events, and moderation actions. Write migrations, indexes, unique constraints and transactional updates. Do not store authoritative real-time movement snapshots in SQL. Redis (optional): Short-lived lobby presence, queues, rate limits, session discovery and cache, with expiry and persistence decisions explicit. Redis must not silently replace the durable PostgreSQL source of truth. HTML/CSS/TypeScript (React/Vite optional): External web pages, support portal, account management, admin/moderation dashboards and lightweight launcher pages only. The browser GAME itself is Unity WebGL, not a second hand-written HTML canvas version. JavaScript/.jslib plugins may bridge Unity WebGL with safe browser APIs and WebSocket/WSS, with restricted browser capabilities respected. HLSL / Unity Shader Graph / ShaderLab: Cross-platform materials, PBR surfaces, original stylized-realistic effects, water, foliage and scalable VFX. Prefer URP-compatible shader variants and measured GPU budgets; avoid platform-only graphics dependencies. JSON: Versioned network payload/schema metadata, tuning configs, localization data and external interface contracts where appropriate. YAML: GitHub Actions and deployment configuration. Bash/PowerShell: repeatable Linux/Windows utilities and build/test entrypoints. Markdown: architecture decision records, QA evidence, Core ledger, API contracts and release notes. Never use plain config files to store secrets. 2. UNITY PROJECT LAYOUT & RESPONSIBILITIES At repository Unity project root: Assets/, Packages/manifest.json, ProjectSettings/ProjectVersion.txt. Under Assets/NEXTGEN/: Core/ for shared interfaces and state, Gameplay/Movement, Gameplay/Characters, Gameplay/Animation, Gameplay/Equipment, Gameplay/Vehicles, Gameplay/Match, World/, Networking/, Input/, Camera/, UI/, Audio/, Graphics/, Scenes/, Prefabs/, Materials/, Config/, Editor/, Tests/. Existing asmdefs (.asmdef) define module boundaries; create references only when needed and never introduce circular dependencies. Asset GUIDs/.meta, Unity scene files, input assets, ScriptableObjects and package versions must be preserved. Maintain one source of truth for configuration. If actual repository paths differ, inspect them and adapt, not blindly relocate working files. Backend/: Node.js services, authenticated HTTP APIs, matchmaking, realtime transport gateway, dedicated match authority, persistence adapters, schema validation and automated server tests. Shared/ or Contracts/: protocol versioning, identifiers, message schema documentation and test vectors; use generators when languages differ. Tools/: Python and Node utilities. QA/: regression output and reproducible test reports. Documentation/: architecture and operational decisions. .github/workflows/: CI source-stage, Unity compile checks and controlled delivery when prerequisites exist. No credentials in Git. 3. PLAYER MOVEMENT: C# CLIENT + SERVER VALIDATION Unity C# owns touch/keyboard/controller input, locomotion, collision and animation-facing state: walk, sprint, crouch, jump, fall/land, slide, pivot, turn-in-place, mantle/vault, swim, slopes and terrain foot contact. One shared rule set with platform input adapters. Server validates movement limits and position; client prediction/reconciliation maintains responsiveness. Foot IK and pose blending never alter server-authoritative positions/hitboxes. 4. CHARACTER ANIMATION: C# + UNITY ANIMATOR Use Unity Animator/Blend Trees, carefully scoped IK and additive layers to coordinate idle, walk/run, starts/stops, slide, pivot, turn, jump, impact/landing, vault/mantle, swim, equipment posture, vehicle seating and emotes. Retarget legal animation assets and maintain predictable transitions, LOD and network pose policies. Visual events require validated sequence/timestamp input. Animation is presentation; it cannot give unauthorized speed, teleport or alter server-owned state. Provide debug overlays and testable motion transition contracts. 5. CAMERA, INPUT & HUD: C# AND UNITY UI C# camera system: third-person/shoulder follow, safe collision, zoom, free-look, vehicle/spectator modes, sensitivity and accessibility. Unity UI Toolkit/uGUI (NOT HTML) handles in-game HUD. Mobile: left joystick/sprint, right camera/interact/jump/equipment, top minimap/team/compass. HUD editor: drag/resize, opacity, touch safe areas, presets and reset. Desktop: keyboard/mouse/controller mapping. 6. MULTIPLAYER: AUTHORITATIVE SERVER + VERSIONED PROTOCOL Server owns tick/state validation, identity, input sequence, movement envelope, teams, inventory, match phases, zones and results. Client prediction is provisional; reconciliation corrects it. Render remote players from interpolated snapshots, bounded extrapolation and pose LOD. Use versioned schemas, sequence checks, safe duplicate rejection, bandwidth budgets and interest management. Android/PC may use native transports behind adapters; WebGL must use secure WSS/WebSocket-compatible transport. Validate with TWO independent clients before claiming multiplayer success. 7. MATCH MODES/FLOW: NODE/TS + UNITY C# Solo=1,Duo=2,Squad=4, each with separate matchmaking, rankings and stats. Backend handles account/party/queue, region policy, authoritative sessions, reconnect and results. Unity C# handles 3D lobby, ready status, invitations, matchmaking UI, pre-match, game HUD, spectator and results. Lifecycle: authenticate→queue→allocate→validate teams→pre-match→play→zone phases→complete→persist→cleanup. Persist results idempotently. 8. INVENTORY, EQUIPMENT & ENERGY BARRIER: C# + SERVER CONTRACTS Client C# renders quick slots, backpack, consumables, cosmetic assets, pickup/drop UI and switching animations. Backend validates item ownership, capacities, transactions, cooldowns and state changes. Build the original defensive energy-barrier feature with placement preview, surface/slope clearance, clear invalid feedback, activation, lifetime and teardown; final placement approval belongs to server. No copied mechanics or trademarks. Configurable classes, data-driven items and independent tests prevent conflicting inventory states. 9. VEHICLES: UNITY C# + SERVER VALIDATION C# physics/controllers for car, bike and off-road variants: steering, suspension, acceleration, braking, terrain, seat entry/exit, audio, camera, mobile/PC inputs. Server validates seat ownership and authoritative vehicle state; clients smooth replicated snapshots. Benchmark physics costs, LOD, collisions and recovery from invalid states. 10. WORLD/GRAPHICS: C# + URP + HLSL Original city/rural terrain, roads, vegetation, water, interiors and landmarks. C# manages async scenes, world sectors, streaming, Addressables when justified, LOD, culling, pooling and memory budgets. Preserve gameplay collision across streaming. URP/Shader Graph/HLSL supply scalable PBR, lighting, shadows, atmosphere and VFX. Profile draw calls, textures, overdraw and GPU time. Blender optional; prototypes work with Unity primitives and procedural geometry. Legally licensed/original assets only. 11. AUDIO, EMOTES, COSMETICS: UNITY C# Unity AudioMixer and C# handle UI/ambient/terrain/vehicle sounds, spatial playback and accessibility sliders. Emotes synchronize safely without overriding gameplay; cosmetics affect appearance only, never competitive stats. Track asset licences and avoid unauthorized media. 12. BACKEND, DATA, STATS & SOCIAL: NODE/TS + SQL APIs manage auth, profiles, parties, friend lists, chat moderation (mute/block/report), player progression, inventory persistence, rankings, session telemetry and history. Save only server-verified match events; maintain Solo/Duo/Squad statistics independently. PostgreSQL SQL migrations/indexes/transactions ensure durable consistency; optional Redis handles queues and expiring session state. REST for account/admin actions; authenticated realtime gateway for live sessions. Respect player privacy, safe logging and account deletion. 13. TRAINING AI: C# OR SERVER MODULE Optional clearly labeled training bots use Unity NavMesh and state machines/behavior trees; match authority remains on server. Do not represent bots as humans or depend on per-frame LLM calls. 14. TARGET PLATFORM TECHNICAL DIFFERENCES ANDROID: Unity C# Android player, IL2CPP/ARM64 where required, touch/gyro, texture compression, safe-area UI, memory/thermal testing, real APK validation. WINDOWS: Unity desktop, keyboard/mouse/controller, resolution/graphics controls and tested executable. WEBGL: Unity C# built using Unity WebGL toolchain, JavaScript/.jslib ONLY for browser APIs; WSS networking, audio gesture requirements, memory and hosting limits. Not a separate HTML game. SERVER: independently deployable backend with realistic resource budgets. 15. SECURITY, PRIVACY & FAIRNESS Server validates competitive state; use encrypted transport, scoped sessions, rate limits, permissions, safe transaction handling, moderation and audit logs. No leaked API tokens, SSH/private keys or passwords; no invasive surveillance or pay-to-win. Enforcement belongs in server/database contracts, not hidden client-side UI. Protect young players with privacy-first social defaults. 16. PERFORMANCE GOALS Targets (not guarantees): 30 FPS on supported Android baseline, 60 FPS on capable Android/PC; browser performance based on tested devices. Measure CPU/GPU frame time, RAM, GC, asset streaming, loading, network latency, battery/thermals and backend SQL performance. Keep quality presets fair and readable. 17. SOURCE/QA AND TRUE STATUS GitHub=source control; Drive=versioned CODE/PROMPT/INTEGRATION Core artifacts; Unity Cloud Build Automation=CI build service, not interactive Editor. Locked Core roadmap runs through Core180. Preserve previous sources and SHA checks; never overwrite quietly. Core121 was last verified in this conversation, but verify latest ledger before any claim. Source-level Node/Python tests passed; Unity Editor compile, Play Mode, real multiplayer, APK/Windows/WebGL builds, FPS and real gameplay screenshots remain UNVERIFIED. QA gates: source tests→Unity compile→EditMode→PlayMode→independent network clients→platform builds→device measurements. 18. LANGUAGE AND MODULE CHEAT SHEET Unity gameplay/HUD/characters/vehicles/camera/animation=C#; graphics=URP+Shader Graph/HLSL; backend=existing JavaScript/Node.js, TypeScript for compatible new services; authoritative C#/.NET simulation=optional after integration evidence; persistent data=PostgreSQL/SQL; transient state=Redis optional; external web/admin=HTML/CSS/TypeScript; WebGL gameplay=Unity C# with minimal JavaScript/.jslib bridge; build/test tools=Python, Node.js, Bash/PowerShell, CI YAML; configs=JSON/YAML; C++ only for tested native plugin needs. Share protocol schemas, tests and version identifiers across languages. RESPONSE REQUEST: Describe this game, exact programming-language ownership for every subsystem, service-to-client data flow, folder locations, and platform rationale. Distinguish implemented source from planned features. This is a PROJECT DESCRIPTION/TECH STACK PROMPT, NOT a command to build the whole game or mass-produce code. If an assumption requires inspecting the repository, label it provisional. Do not claim untested results.