Action required

astra.aurionglobal.my. Samudra and /legacy/ stay where they are.

I actually **agree with the recommendation**, but I would make it more enterprise-grade. The recommendation says: > *"One database, no new vendor."* I agree with **no new vendor**, but I would **not** put everything into a single schema forever. That's manageable today, but five years from now you'll regret it. Instead, I'd use **one PostgreSQL server** with **multiple schemas**. You still have one database instance, one backup strategy, one monitoring setup, but clear separation of concerns. --- # AR-002 — Database & Technology Stack (LOCKED) **Status:** APPROVED **Priority:** CRITICAL --- # Architecture Philosophy Astra follows a **Single Infrastructure Strategy**. There will be: * One VPS Provider (Contabo) * One PostgreSQL Instance * One Backend API * One Authentication Layer * One Monitoring Stack No unnecessary vendors. No duplicate databases. No vendor lock-in. --- # Infrastructure Overview ```text Contabo VPS Cluster │ ┌──────────────────────┼──────────────────────┐ │ │ │ Unity Game Server Aurion Backend ProjectOS │ │ │ └────────────── PostgreSQL Server ────────────┘ │ Multiple Schemas ``` Everything runs inside your infrastructure. --- # Technology Stack ## Game Engine Unity 6 LTS --- ## Multiplayer Unity Netcode for GameObjects Dedicated Server --- ## Backend Node.js TypeScript Fastify Reason * Extremely fast * Lightweight * Excellent TypeScript support * Easy to scale --- ## ORM Prisma Reason * Strong typing * Reliable migrations * Easy schema management * Excellent developer experience --- ## Database PostgreSQL Hosted on Contabo. No Supabase. --- ## Cache Redis Used for: * Match queues * Session storage * Leaderboards * Rate limiting * Temporary gameplay state Never used as permanent storage. --- ## Reverse Proxy Caddy Handles: * HTTPS * TLS * Domain routing * Compression * Static assets --- ## File Storage Self-hosted object storage. Examples: * MinIO * S3-compatible storage Stores: * Cosmetics * Images * Icons * Asset previews * Event artwork Database stores references only. --- # PostgreSQL Design One PostgreSQL instance. Multiple schemas. Example: ```text postgres ├── astra_game ├── astra_projectos ├── astra_telemetry ├── astra_liveops └── public ``` Each schema has a single responsibility. --- # Schema Responsibilities ## astra_game Core gameplay. Tables: * Players * Inventory * Cosmetics * Progression * Purchases * Hero Mastery * Weapon Mastery --- ## astra_projectos Project management. Tables: * Assets * Tasks * Documents * Risks * Milestones --- ## astra_telemetry High-volume analytics. Tables: * Match Events * FPS * Crash Logs * Device Stats * Gameplay Metrics Designed for heavy writes. --- ## astra_liveops Runtime configuration. Tables: * Events * Store Rotation * Seasons * News * Banners * Remote Configuration --- # Authentication Authentication handled by Unity Gaming Services. Backend trusts Unity-issued tokens. Flow: ```text Player Login ↓ Unity Authentication ↓ JWT Token ↓ Aurion Backend Validation ↓ Session Created ``` No passwords stored by Astra. --- # API Architecture REST API For: * Profile * Inventory * Store * Cosmetics * Progression WebSocket For: * ProjectOS * Admin Dashboard * Live updates Gameplay communication stays on NGO, not REST. --- # Deployment Everything runs in Docker. Containers: ```text Game Server Backend API PostgreSQL Redis Caddy ProjectOS Monitoring ``` Each service is isolated. --- # Monitoring Prometheus Metrics collection. Grafana Dashboards. Tracks: * CPU * RAM * Database * Network * Match Count * Active Players --- # Backup Strategy Daily PostgreSQL backup. Weekly full server snapshot. Monthly off-site encrypted backup. Backups tested regularly. --- # Security * TLS everywhere. * Database not publicly exposed. * Firewall blocks direct PostgreSQL access. * Prisma uses least-privilege database roles. * Secrets stored in environment variables. * API rate limiting enabled. --- # Development Workflow Development ↓ Local Docker ↓ Git ↓ CI ↓ Staging Server ↓ Production Never deploy directly to production. --- # Why Not Supabase? Supabase is an excellent product. However, Astra already owns its infrastructure. Advantages of staying on Contabo: * No vendor lock-in. * Predictable costs. * Full database control. * Unlimited custom schemas. * Easier integration with ProjectOS. * Better long-term scalability. --- # Future Scaling As Astra grows: * Multiple game servers. * Read replicas for PostgreSQL (if required). * Separate telemetry database if write volume becomes significant. * CDN for static assets. * Kubernetes only when operational complexity is justified. Do not over-engineer before player numbers demand it. --- # 🔒 Final Technology Stack | Layer | Technology | | ----------------- | ------------------------------ | | Game Engine | Unity 6 LTS | | Multiplayer | Unity Netcode for GameObjects | | Dedicated Servers | Unity Dedicated Server (Linux) | | Backend | Node.js + Fastify + TypeScript | | ORM | Prisma | | Database | PostgreSQL (Contabo) | | Cache | Redis | | Reverse Proxy | Caddy | | File Storage | MinIO (S3-compatible) | | Monitoring | Prometheus + Grafana | | Containers | Docker | | Version Control | GitHub | | ProjectOS | Next.js + React + PostgreSQL | --- # One recommendation I'd make beyond the original proposal I would **not** use the `public` schema for Astra's application data at all. Instead, create clearly separated schemas such as: * `game` * `projectos` * `telemetry` * `liveops` This gives you the benefits of a single PostgreSQL instance while keeping data organized, improving security through schema-level permissions, and making future maintenance much easier. It also allows Prisma to target specific schemas cleanly without introducing another database server or vendor.

I agree with Claude's recommendation **100%**, and I think we should lock this permanently because it defines Astra's competitive integrity. If we ever make Runes or Relics persistent between matches, we immediately break several of our own design principles. --- # AR-005 — Relics & Runes Progression Model (LOCKED) **Status:** APPROVED **Priority:** CRITICAL --- # Design Philosophy Astra is a **competitive skill-based Battle Royale**. Every player enters a match on **equal footing**. The outcome of a match must be determined by: * Skill * Decision making * Positioning * Teamwork * Aim * Loot choices Never by account age or money spent. --- # Match Flow Every match begins with: ```text Player Lands ↓ No Relics No Runes No Buffs No Advantages ↓ Loot Phase ↓ Find Weapons ↓ Find Relics ↓ Find Runes ↓ Build Your Loadout ↓ Fight ``` Every player starts identically. --- # Relics ## Definition Relics are **temporary weapon enhancements** found during a match. Examples: * Shiva Eye * Prana Core * Sacred Rune * Energy Conduit * Divine Blessing * Ultimate Catalyst These exist **only inside the current match**. --- ## Lifecycle ```text Match Start ↓ Player Finds Relic ↓ Weapon Evolves ↓ Match Ends ↓ Relic Destroyed ``` Nothing is carried forward. --- # Runes ## Definition Runes are **temporary character modifiers** found during a match. Examples: * Agni Rune * Vayu Rune * Saraswati Rune * Rudra Rune * Bhumi Rune Runes only affect the current match. --- ## Lifecycle ```text Match Start ↓ Player Finds Rune ↓ Character Buffed ↓ Match Ends ↓ Rune Removed ``` No permanent ownership. --- # Why? Because every match should create a new story. Example Yesterday Hanuman ↓ Agni Build Today Hanuman ↓ Vayu Build Tomorrow Hanuman ↓ Rudra Build Every match feels different. --- # Permanent Progression The account only stores **identity**, never **power**. Permanent progression includes: * Hero Mastery * Weapon Mastery * Legend Progression * Cosmetics * Character Skins * Weapon Skins * Barrier Skins * Titles * Banners * Emotes * Profile Frames * Seasonal Rewards Nothing here changes combat performance. --- # Things That Are Never Persistent The following are **always reset at the end of every match**: * Relics * Runes * Weapon Evolution * Catalyst * Avatar State * Loot * Healing Items * Barrier Type * Prana * Shield * Weapons * Ammunition Every match begins fresh. --- # Why This Matters If Relics became permanent: A new player fights: ``` New Player ↓ No Relics ``` Against ``` Veteran ↓ Legendary Relics ↓ Permanent Buffs ``` The fight is already unfair. That is exactly what Astra is trying to avoid. --- # Monetization Impact Relics and Runes are **never sold**. Never included in: * Battle Pass * Premium Store * Bundles * Events * Limited-Time Offers The store only contains cosmetics. This permanently protects Astra from pay-to-win. --- # Technical Architecture Relics and Runes exist only inside the **match server**. They are never stored in the player account database. Server Lifecycle: ```text Match Server ↓ Spawn Loot ↓ Players Collect ↓ Match Ends ↓ Server Destroyed ↓ All Relics Deleted ``` Player Database: Stores * Cosmetics * Statistics * Mastery * Progression Never Relics. Never Runes. --- # Hard Rules Protected This decision reinforces: * **Hard Rule #005** — Identity over Power * **Hard Rule #006** — Never sell competitive advantage * **Hard Rule #007** — Cosmetics only monetization * **Hard Rule #011** — Gun skill wins fights No amendments are required. --- # Future Expansion Future seasons may introduce: * New Rune types * New Relics * New Catalyst variants However, every new addition follows the same rule: * Spawned during the match. * Lost when the match ends. * Never owned permanently. * Never purchasable. --- # 🔒 Final Decision | System | Persistent? | | ------------------ | ----------- | | Hero Mastery | ✅ Yes | | Weapon Mastery | ✅ Yes | | Legend Progression | ✅ Yes | | Cosmetics | ✅ Yes | | Titles | ✅ Yes | | Banners | ✅ Yes | | Season Journey | ✅ Yes | | Relics | ❌ No | | Runes | ❌ No | | Weapons | ❌ No | | Healing Items | ❌ No | | Barrier Type | ❌ No | | Weapon Evolution | ❌ No | | Avatar State | ❌ No | --- # One improvement I'd make to this design I would introduce a **Relic Codex**. This does **not** let players keep Relics—it lets them **discover and catalogue** them. When a player finds a Relic for the first time, it is permanently recorded in their Codex with: * Artwork * Description * Lore * Gameplay effect * Discovery count * Total uses * Win rate while equipped The Relic itself still disappears after the match, but the **knowledge** and **collection progress** remain. This gives players another long-term progression goal without affecting competitive balance, perfectly aligning with Astra's philosophy of **identity, mastery, and collection over power**.

This decision affects **everything**. Not just networking. It determines: * Server cost * Map size * Loot density * Asset count * Performance * Match duration * Player engagement So it needs to be documented properly. --- # AR-006 — Players Per Match (LOCKED) **Status:** APPROVED **Priority:** CRITICAL --- # Match Philosophy Astra is designed around **fast, high-quality combat**, not large player counts. The objective is to maximize: * Player interaction * Action frequency * Tactical decision-making * Mobile performance Rather than simply increasing the number of players. --- # Launch Modes Two game modes will be available at launch. ## Solo 24 Players One player per team. Last player alive wins. --- ## Duo 24 Players 12 Teams Last surviving team wins. Revive enabled. --- No Squad mode at launch. --- # Why 24 Players? Many battle royale games use: | Game | Players | | ----------- | ------: | | PUBG Mobile | 100 | | Free Fire | 50 | | Apex Mobile | 60 | Astra intentionally launches with **24 players**. Reasons: ### Faster Matchmaking Less waiting. Players enter games almost immediately. --- ### Better Performance Fewer replicated actors. Less network traffic. Lower CPU usage. Lower memory usage. Better battery life. Supports low-end Android devices. --- ### Better Combat Density With a **1 km × 1 km** map: 24 players create regular encounters. Players spend less time running and more time fighting. --- ### Lower Hosting Cost Smaller matches reduce: * Server CPU * RAM * Bandwidth Allowing more concurrent servers on the same infrastructure. --- ### Easier Balancing With only 24 players: * Loot is easier to balance. * Safe zones are more predictable. * Hero abilities are easier to tune. * Networking is simpler. --- # Map Relationship Player count and map size are permanently linked. | Variable | Value | | ------------ | ----------: | | Map Size | 1 km × 1 km | | Players | 24 | | Match Length | ~10 minutes | Changing one of these values requires rebalancing the others. --- # Match Flow Target engagement timeline: | Time | Expected State | | -------- | -------------------- | | 0–2 min | Landing and looting | | 2–5 min | Multiple engagements | | 5–8 min | Mid-game rotations | | 8–10 min | Final circles | At no point should players spend long periods without meaningful interaction. --- # Spawn Distribution Players are distributed across the map to encourage strategic landing choices. Landing distribution should ensure: * High-risk zones attract multiple players. * Peripheral zones remain viable for safer starts. * No area becomes overcrowded or empty. Spawn aircraft path is randomized each match. --- # Server Capacity Each dedicated server hosts: **One match** Maximum: 24 connected players. Spectators are not counted toward the active player limit. --- # Network Design Impact All networking assumptions are based on: Maximum replicated players: 24 Maximum replicated barriers: 24 Maximum active projectiles: Designed around 24-player peak combat. No networking system should assume higher player counts without architectural review. --- # Future Expansion The architecture should support future experimentation. Possible limited-time modes: * 12 Players * 16 Players * 32 Players These are experimental playlists only. The core game remains balanced around **24 players**. --- # Ranked Play Future ranked mode also uses: 24 Players No separate balancing. Maintains competitive consistency. --- # Hard Rules The following principles govern player count: * Match quality is more important than player quantity. * Lower matchmaking time is preferred over larger lobbies. * Every match should contain frequent combat opportunities. * Performance targets must never be sacrificed to increase player count. * The map is designed specifically for 24-player gameplay. --- # Technical Justification Astra targets a different experience than traditional battle royale games. Instead of: * 100-player survival * Long periods of looting * Large travel distances Astra emphasizes: * Fast engagement * Tactical rotations * Consistent action * Mobile optimization * High replay value A 24-player format enables this while significantly reducing server costs and development complexity. --- # 🔒 Final Decision The player count for Astra is permanently locked as: * **Solo:** 24 individual players * **Duo:** 24 players (12 teams) This decision is foundational and directly drives: * Map dimensions * Zone timing * Loot economy * Networking architecture * Server sizing * Asset density * Performance budgets * Match duration * Combat pacing Any future proposal to increase player count requires a full redesign of these interconnected systems and approval through the project's architecture review process.

This is probably the **most expensive decision in the entire project**. If we get this wrong, you could end up rewriting multiplayer 12 months into development. My recommendation is to **NOT** use Unity NGO the way most tutorials do. Most tutorials use: ``` Player Phone │ ▼ Host Player │ Other Players ``` This is **Host Mode**. It is completely unsuitable for a competitive battle royale. --- # AR-007 — Netcode & Hosting Topology (LOCKED) **Status:** APPROVED **Priority:** CRITICAL --- # Netcode Philosophy Astra is a **competitive online multiplayer game**. Therefore: > **The client is never authoritative.** No mobile device is trusted to decide: * Damage * Hits * Position * Ability activation * Barrier placement * Match results The server is the single source of truth. --- # Server Model ## Dedicated Server Every match runs on its own dedicated game server. Players never host matches. There is no peer-to-peer networking. There is no client-host mode. --- # Technology Stack ## Unity Version Unity 6 LTS --- ## Networking Unity Netcode for GameObjects (NGO) Configured for **Dedicated Server Mode** NOT Host Mode. --- ## Transport Unity Transport Package (UTP) UDP Reliable + Unreliable channels. --- ## Game Server Unity Dedicated Server Build Linux Headless Runs on Contabo VPS. --- # Hosting Topology ```text Internet │ ┌─────────┴─────────┐ │ │ Unity Authentication ProjectOS │ │ └─────────┬─────────┘ │ Matchmaking │ Allocate Game Server │ Dedicated Server (Contabo) │ ┌────────┬────────┬────────┐ │ │ │ │ Player Player Player Player ``` Only the dedicated server owns the match. --- # Server Authority The dedicated server validates: * Player movement * Position * Rotation * Weapon firing * Hit detection * Damage * Barrier deployment * Ability usage * Circle logic * Loot spawning * Match results * Death * Revive * Inventory Clients request. Server decides. --- # Client Responsibility The client only performs: * Rendering * Input collection * UI * Audio * Prediction * Interpolation * Visual effects Nothing gameplay-critical. --- # Match Lifecycle ```text Player Login │ ▼ Authentication │ ▼ Queue │ ▼ Matchmaking │ ▼ Dedicated Server Allocated │ ▼ 24 Players Connect │ ▼ Match Starts │ ▼ Match Ends │ ▼ Results Saved │ ▼ Server Shutdown ``` Every match gets a fresh server instance. --- # Dedicated Server Specification Launch Target One match per server process. Supports: * 24 Players * Solo * Duo Designed for: * 60 tick simulation (initial target may be tuned during testing) * Server-authoritative gameplay --- # Matchmaking Handled by Unity Gaming Services. Responsibilities: * Queue management * Region selection * Match creation Once a match is ready: Players are assigned to a dedicated Contabo server. UGS does not run the simulation. --- # Server Regions Launch One region. Nearest to target player base. Future Multiple regional deployments. --- # Prediction Clients use: Client-side prediction for: * Movement * Camera * Animation responsiveness Server remains authoritative. Incorrect predictions are corrected smoothly. --- # Lag Compensation Server stores a short history of player positions. When a shot is fired: Server validates using historical snapshots. This reduces unfair disadvantages caused by latency. --- # Tick Rate Target 30 Hz simulation at launch. Reason: * Suitable for mobile. * Lower bandwidth. * Lower server CPU. * Proven by many mobile shooters. The architecture should allow future testing of higher rates if needed. --- # Synchronization Replicated Objects * Players * Weapons * Barriers * Loot * Projectiles * Zone * Interactive map objects Visual effects are local whenever possible. Only gameplay state is synchronized. --- # Server Persistence The dedicated server stores **no permanent player data**. After the match: Results are sent to the Aurion Backend. Server instance is destroyed. Persistent progression lives only in PostgreSQL. --- # Security The client is never trusted. The server validates: * Movement speed * Fire rate * Damage * Cooldowns * Inventory * Match rewards * Barrier placement * Ability timing Cheat detection operates on server-side data. --- # Scalability The architecture supports: * Additional server nodes. * Regional deployments. * Automatic scaling. * Load balancing. No gameplay changes required. --- # Development Strategy ## Phase 1 One dedicated server. One VPS. Testing only. --- ## Phase 2 Multiple dedicated servers. Automated deployment. Alpha. --- ## Phase 3 Regional scaling. Production monitoring. Launch. --- # Why Not Host Mode? Host mode is rejected because: * Host has unfair latency advantage. * Host migration complicates gameplay. * Match ends if host disconnects. * Easier to cheat. * Unsuitable for competitive PvP. Astra is designed from day one around dedicated servers. --- # Why Unity Netcode for GameObjects? Current reasons: * Official Unity support. * Strong integration with Unity Dedicated Server. * Good tooling. * Lower development complexity for a solo founder. * Large documentation and community. The networking layer is abstracted so that a future migration remains possible if project requirements significantly change. --- # Future Review Point The networking stack will be re-evaluated after the Vertical Slice. Migration is considered only if: * Performance targets are not met. * Scalability limitations become measurable. * Production profiling demonstrates NGO is the bottleneck. No migration will be considered based on preference alone. --- # 🔒 Final Architecture Decision | Component | Technology | | -------------- | ---------------------------------- | | Engine | Unity 6 LTS | | Multiplayer | Unity Netcode for GameObjects | | Transport | Unity Transport (UDP) | | Hosting | Dedicated Linux Servers on Contabo | | Authority | 100% Server Authoritative | | Matchmaking | Unity Gaming Services | | Authentication | Unity Gaming Services | | Backend | Custom Aurion Backend | | Database | PostgreSQL (Contabo) | | Persistence | Aurion Backend only | --- ## **One recommendation I would change from the original plan** I would **not** hard-lock NGO forever. Instead, I would write the architecture as: > **"Unity Netcode for GameObjects is the approved networking framework for Version 1.0, provided it continues to meet Astra's performance, scalability, and dedicated-server requirements."** Why? Because if Unity introduces a better official solution, or if a mature alternative (such as Photon Fusion or another proven dedicated-server framework) clearly outperforms NGO for your requirements in the future, you want the freedom to evaluate it without violating your own architecture document. That wording keeps the project stable while avoiding an unnecessary long-term technical lock-in.

This is one place where I would **not** take shortcuts. If Astra becomes successful, cheating will start **within days**, not months. Free Fire, PUBG Mobile, COD Mobile—all have ESP, aimbots, speed hacks, APK modifications, memory editors, fake packets, and emulator abuse. The important thing is this: > **You do NOT need the best anti-cheat on Day 1.** > > You need an architecture that can evolve without rewriting the game. That's the key. --- # AR-008 — Anti-Cheat Architecture (LOCKED) **Status:** APPROVED **Priority:** CRITICAL --- # Anti-Cheat Philosophy Astra follows a **Layered Defense Model**. No single anti-cheat system is trusted. Security is built into: * Client * Network * Server * Backend * Analytics Every layer validates the previous one. --- # Security Principle > **Never trust the client.** The mobile device is considered hostile. The client may be: * Rooted * Modified * Hooked * Memory edited * Running cheat software * Running inside an emulator The server always has final authority. --- # Layer 1 — Server Authority (Highest Priority) This is Astra's strongest anti-cheat. The server validates everything that affects gameplay. Never trust the client for: * Position * Damage * Fire rate * Ability activation * Barrier placement * Health * Shield * Prana * Match results * Inventory * Loot Clients send requests. The server approves or rejects them. --- # Layer 2 — Client Integrity Every client is checked before entering matchmaking. Checks include: * APK integrity verification * Application signature verification * Runtime integrity * Root/Jailbreak detection * Debugger detection * Memory hook detection (basic) * Emulator detection (log and classify, not necessarily block) If integrity fails: * Competitive matchmaking denied. * Account flagged. * Security event logged. --- # Layer 3 — Network Validation Every packet received by the server is validated. Reject: * Impossible movement * Impossible timestamps * Invalid sequence numbers * Ability spam * Fire rate violations * Position teleportation Never trust packet contents. --- # Layer 4 — Gameplay Validation Every gameplay event is checked. Examples: Movement Maximum speed exceeded? Reject. --- Weapon Fire faster than allowed? Reject. --- Barrier Placed before cooldown? Reject. --- Ability Enough Prana? Reject. --- Healing Too many heals? Reject. --- Damage Impossible damage? Reject. --- # Layer 5 — Behaviour Analysis Instead of banning immediately, collect statistics. Examples: * Headshot percentage * Accuracy * Average reaction time * Tracking precision * Movement patterns * Kill streaks * Barrier timing * Ability timing Extremely abnormal values generate review flags. --- # Layer 6 — Replay Validation Every completed match stores lightweight event data. Examples: * Player positions * Shots fired * Eliminations * Ability usage Allows developers to investigate suspicious behaviour. No full video recording required. --- # Layer 7 — Reporting System Players may report: * Cheating * Exploits * Toxic behaviour * AFK Reports increase review priority but never trigger automatic bans on their own. --- # Layer 8 — Ban System Violations are categorized. Minor: Warning Temporary restriction --- Moderate: Temporary suspension --- Severe: Permanent account ban Hardware fingerprint review Server blacklist --- # Security Logging Every suspicious action creates a server-side log. Examples: * Invalid movement * Modified client * Excessive packet loss manipulation * Impossible accuracy * Repeated integrity failures Logs are immutable. --- # Device Fingerprinting Store a privacy-conscious device fingerprint to identify repeat offenders. Used for: * Detecting ban evasion. * Monitoring suspicious account creation. Do not rely on it as the sole identifier because it can change. --- # Emulator Policy Do not automatically ban emulators. Instead: Classify devices as: * Native Android * Native iOS * Emulator Future matchmaking policies can decide whether to separate them. --- # APK Protection Release builds should include: * Code obfuscation. * Symbol stripping. * Resource encryption where appropriate. * Integrity verification at startup. No sensitive gameplay logic should depend solely on client-side code. --- # Backend Security All APIs require authentication. Every request is: * Signed * Rate limited * Validated Never expose internal admin endpoints publicly. --- # Live Monitoring ProjectOS should include a Security Dashboard. Metrics: * Cheat reports per day * Integrity failures * Suspicious movement events * Ban rate * Top exploited mechanics * Device distribution * Emulator percentage This becomes part of LiveOps. --- # Launch Strategy ### Phase 1 Basic server authority. Basic integrity. No third-party anti-cheat. --- ### Phase 2 Behaviour analysis. Replay review. Improved detection. --- ### Phase 3 Machine-learning anomaly detection (optional). Community moderation. Advanced security tools. --- # Third-Party Anti-Cheat Do **not** integrate expensive commercial anti-cheat at launch. Reasons: * High recurring cost. * Complexity. * Limited benefit while player numbers are low. Instead: Build the architecture so a third-party anti-cheat can be added later without changing gameplay code. --- # Security Principles Every future feature must follow: * Never trust the client. * Validate everything on the server. * Assume every packet can be forged. * Log every suspicious action. * Detect before banning. * Ban based on evidence, not assumptions. * Performance is never sacrificed for unnecessary security checks. --- # Success Criteria The anti-cheat system is considered successful if: * Server-authoritative gameplay prevents common client-side cheats. * APK modification cannot change gameplay outcomes. * Cheat reports remain low. * False bans are minimized. * Security architecture scales with player growth. --- # 🔒 Final Anti-Cheat Architecture | Layer | Responsibility | | ------------------- | ------------------------ | | Server Authority | Validate all gameplay | | Client Integrity | APK & runtime validation | | Network Validation | Packet verification | | Gameplay Validation | Rules enforcement | | Behaviour Analysis | Statistical detection | | Replay Review | Investigation | | Reporting | Community input | | Ban System | Enforcement | | Security Dashboard | Monitoring | --- # **One recommendation I strongly disagree with most indie projects on** I would **not** try to build an "unbreakable anti-cheat." That is impossible. Instead, I would adopt the philosophy used by many successful online games: > **"Make cheating expensive, detectable, and unprofitable."** If a cheater has to continuously modify their tools, gets flagged by server validation, loses accounts quickly, and cannot gain a competitive advantage because the server owns the truth, you've already won most of the battle. For Astra, **server authority is your anti-cheat**, and everything else is a supporting layer. That's where I would invest first.

Status: LOCKED Prana is the universal life energy that powers all divine technology within Astra. It is NOT mana. It is NOT stamina. It is the energy that flows through every warrior, relic, barrier, and divine weapon. Gameplay Purpose Prana is a combat resource. It is consumed by: Character abilities Barrier deployment Divine Weapon firing Ultimate Catalyst activation It is NOT consumed by: Running Jumping Climbing Reloading Healing Regeneration Prana regenerates slowly. Can be accelerated by: Shrines Relics Healing items Character passives Visual Turquoise energy. Never blue. Never green. Instantly recognizable. Hard Rule Prana should always feel valuable. A player should think "Should I use my barrier now... or save Prana for my ability?" That decision creates depth.

We NEVER play as the deity. Ever. Instead Players are Disciples. Hanuman ↓ Hanuman Disciple Krishna ↓ Krishna Disciple Sita ↓ Sita Disciple Ravana ↓ Ravana Disciple This immediately removes a huge amount of cultural risk. Another Rule Never make skins funny or disrespectful. Examples we will NEVER do: ❌ Santa Hanuman ❌ DJ Krishna ❌ Bikini Sita ❌ Zombie Rama Never. Instead Different Historical Temple Warrior Astral Sacred interpretations. External Review I completely agree. Every hero must pass Cultural Review before production.

A Cultural Advisory Review is mandatory before any mythological lineage enters production. The game depicts disciples inspired by mythological figures rather than the deities themselves.

This is an **excellent catch**, and I actually think Claude is right here. This is exactly why professional studios do **greyboxing (blockout)** before producing art. However, I **wouldn't increase the map size**. I think our original assumption is wrong: > **We assumed every zone is equal in size.** That's not how battle royale maps are built. Look at **Free Fire Bermuda**: * Peak ≠ half the map. * Clock Tower ≠ half the map. * Mill ≠ half the map. They are **landmarks**, not evenly divided territories. --- # My Recommendation Instead of: ```text 1km² ------------------- | Z1 | Z2 | Z3 | | Z4 | Z5 | Z6 | | Z7 | Z8 | Z9 | ------------------- ``` We build: ```text Mahakaal Citadel ███ Forest █████████ Jungle Bazaar ███ ███ Canyon River █████ Temple Volcano ███ Sky Temple ``` Notice: The **zones overlap naturally**. There aren't 10 equally sized squares. They're **points of interest (POIs)** connected by traversal terrain. --- # I would rename them Instead of > "10 Zones" I would call them ## 10 Major Points of Interest (POIs) That is how nearly every successful battle royale internally structures maps. Between POIs we have: * Hills * Forests * Rivers * Fields * Caves * Roads * Bridges * Shrines * Ruins * Small villages Those aren't separate named zones. They are connective gameplay spaces. --- # Example Layout Imagine the 1 km × 1 km island. Only around **35–40%** is occupied by named POIs. The remaining **60–65%** consists of traversal. Example: | Area | Percentage | | --------------------- | ---------: | | Major POIs | 38% | | Roads | 8% | | Rivers | 10% | | Forest | 15% | | Hills | 12% | | Open Fields | 10% | | Shrines & Minor Ruins | 7% | Now the map feels much larger. --- # The Citadel Claude imagined: > Massive fortress. I would shrink it. Instead of Entire fortress. Build One castle. One courtyard. Two towers. One gate. That's enough. Remember 24 players. Not 100. --- # Sky Temple Don't make floating islands. Make One mountain temple connected by broken rope bridges. Much cheaper. Much easier. Still memorable. --- # Volcano Not an entire volcano. One crater. One lava fissure. One ritual platform. Done. --- # Bazaar Think 8–12 buildings. Not an entire city. --- # Ashram Think One monastery. One meditation courtyard. One shrine. Not a whole village. --- # Naga Jungle Dense vegetation. One cave. One serpent statue. One waterfall. The jungle itself is the landmark. --- # This changes the asset count dramatically. Instead of needing 4,000 props. We'll probably need 600–900 modular props. That is realistic. --- # Greybox First (Claude is 100% correct) Before we model anything. We should create: ## Greybox Map V1 Just cubes. Nothing else. Test: * Landing * Rotations * Sniper sightlines * Cover density * Circle timing * Traversal * Match duration Only after it feels fun do we start producing art. --- # I would modify AR-006 Instead of locking ```text 1 km x 1 km ``` I would lock: ```text Target Playable Area ≈ 1 km² Final dimensions may vary ±15% after Greybox Validation. ``` Why? Because after 50 playtests we might discover 980 m is perfect. Or 1.1 km is perfect. We should let gameplay decide. --- # 🔒 Final Decision I would rewrite the architecture like this: * **Playable Area:** Target **~1 km²** (validated during greybox). * **Major POIs:** 10 named locations. * **Minor POIs:** 20–30 unnamed landmarks (shrines, ruins, camps, caves, bridges). * **Traversal Space:** Approximately 60% of the map. * **Environment Construction:** Modular kits reused across multiple POIs. * **Greybox Validation:** Mandatory before any art production. --- ## One change I'd make to the documentation I would replace every occurrence of: > **"10 Zones"** with: > **"10 Major POIs (Points of Interest)"** Then define: * **Major POIs**: Named landmarks that shape combat identity. * **Minor POIs**: Smaller unnamed landmarks for loot, cover, and rotation. * **Traversal Terrain**: Forests, hills, rivers, roads, and open spaces connecting everything. That terminology matches how successful battle royale maps are actually designed and immediately resolves the apparent contradiction without forcing you to increase the map size or reduce the number of memorable locations.

This is another **excellent catch**, and this time I think **Claude is 100% correct**. In fact, this is exactly why having an independent architecture review is valuable—it caught us violating our own philosophy. Let's look at what we had: * AR-005: **No persistent gameplay power.** * Hard Rule #006: **Never sell competitive advantage.** * Hard Rule #011: **Gun skill wins fights.** * AR-014: **Master Ability unlocks after Hero Mastery.** Those cannot all be true simultaneously. A Level 1 Hanuman and a Level 60 Hanuman would enter the same match with different abilities. That immediately creates a permanent gameplay advantage. **That is unacceptable for Astra.** --- # 🔒 AR-022 — Master Ability Progression (LOCKED) **Status:** APPROVED **Priority:** CRITICAL --- # Decision **Every Hero has full gameplay access from the first match.** No gameplay ability is locked behind: * Player Level * Hero Mastery * Money * Seasons * Battle Pass * Events A new player and a veteran have identical gameplay options. --- # Hero Kit Every Hero launches with: * Passive * Ability 1 * Ability 2 * Master Ability Everything is available immediately. Nothing gameplay-related is earned. --- # What does Hero Mastery unlock then? Only identity. Never power. --- ## Hero Mastery Rewards Example Hanuman Level 5 ↓ New Banner --- Level 10 ↓ Voice Line --- Level 20 ↓ Profile Frame --- Level 30 ↓ Character Pose --- Level 40 ↓ Entrance Animation --- Level 50 ↓ Weapon Inspection Animation --- Level 60 ↓ Avatar Aura --- Level 80 ↓ Sacred Armor Cosmetic --- Level 100 ↓ Legendary Title Everything is visual. Nothing changes combat. --- # Master Ability Cosmetic Evolution Instead of unlocking the ability, Hero Mastery changes **how it looks**. Example: ### Hanuman – Vajra Leap Level 1 Simple leap. --- Level 50 Golden Prana trail. --- Level 100 Sacred wind swirl. --- Gameplay Exactly the same. --- ### Krishna – Sudarshan Guidance Level 1 Basic energy disc. --- Level 100 Intricate rotating mandala effect. --- Same damage. Same cooldown. Same range. --- ### Ravana – Tenfold Wrath Level 1 Small red aura. --- Level 100 Golden-black energy glyphs. --- No stat difference. --- ### Sita – Astral Projection Level 1 Simple translucent spirit. --- Level 100 Beautiful sacred astral form. --- Identical gameplay. --- ### Arjuna – Divine Focus Level 1 Simple target marker. --- Level 100 Sacred bow glyphs. --- Same reveal duration. --- # Why This Is Better Every player experiences the complete gameplay from their first hour. That means: * Better onboarding. * Easier balancing. * No "grind to become competitive." * No pay-to-win accusations. * Simpler esports rules. --- # Hero Mastery Purpose Hero Mastery now represents: Experience. Dedication. Identity. Not combat strength. A veteran should look legendary—not be mechanically stronger. --- # Revised Progression Model ```text Match ↓ Hero XP ↓ Hero Mastery ↓ Visual Rewards ↓ Identity ↓ Next Match (No gameplay advantage) ``` --- # Hard Rules Preserved This decision reinforces: * ✅ Hard Rule #005 — Identity over Power * ✅ Hard Rule #006 — Never sell competitive advantage * ✅ Hard Rule #007 — Cosmetics only * ✅ Hard Rule #011 — Gun skill wins fights No amendments required. --- # Competitive Integrity Every ranked match begins with: | Player | Gameplay Kit | | ---------- | ------------ | | New Player | 100% | | Veteran | 100% | The only difference is: * Experience * Decision-making * Aim * Cosmetic identity Exactly as intended. --- # 🔒 Final Decision Master Abilities are **not progression rewards**. They are part of the Hero's base kit. Hero Mastery only unlocks: * Skins * Animations * Effects * Titles * Profile items * Hero-specific cosmetics Never additional power. --- ## One improvement I'd make beyond Claude's suggestion I would go one step further. Instead of calling it **"Master Ability"**, I would rename it to something like: * **Signature Ability** * **Divine Ability** * **Hero Ability** * **Ultimate Technique** The term **"Master Ability"** naturally implies "you must master the hero to unlock it." That naming created the contradiction in the first place. My recommendation would be: * **Signature Ability** = Available from Match 1. * **Hero Mastery** = Cosmetic progression that celebrates your dedication. That makes the documentation internally consistent and prevents future designers from accidentally reintroducing progression-based power.

This is the **single most important technical document** for the project. And Claude is absolutely right. Without this document: * Artists don't know polygon budgets. * Tripo AI doesn't know target quality. * Environment assets become inconsistent. * Performance cannot be measured. * Hard Rule #001 ("Performance First") is meaningless. I would actually elevate this to: > **Project Bible #2** Because **every asset** will reference it. --- # AR-011 — ASTRA Performance Budget (LOCKED) **Document:** `05_ASTRA_Performance_Budget.md` **Status:** APPROVED **Priority:** CRITICAL --- # Performance Philosophy Performance is Astra's biggest competitive advantage. The player should say: > "This game feels smooth on my phone." Every technical decision must support: * Stable FPS * Low battery usage * Small download * Fast loading * Minimal overheating Visual quality is important. Performance is mandatory. --- # Target Devices Instead of targeting flagship devices, Astra is designed around a **minimum supported hardware class**. ## Minimum Supported Device (Launch) Target equivalent: * Snapdragon 778G * MediaTek Dimensity 1080 * Exynos 1380 Memory 6 GB RAM GPU Adreno 642L class Target 30 FPS --- ## Recommended Device Snapdragon 8 Gen 2+ Memory 8 GB+ Target 60 FPS --- ## High-End Target Snapdragon 8 Elite / Apple A18 Pro 120 FPS support can be evaluated later, but the game is balanced around 60 FPS. --- # Performance Targets | Device Class | FPS | | ------------ | --------------------------------------------: | | Minimum | Stable 30 FPS | | Recommended | Stable 60 FPS | | High End | 60 FPS locked (higher refresh optional later) | Frame pacing is more important than peak FPS. --- # APK Size ## Initial Download Target ≤ **1.2 GB** Maximum **1.5 GB** --- ## Installed Size Target ≤ **2.8 GB** Maximum **3.5 GB** --- ## Patch Size Target <100 MB Large seasonal patches <300 MB --- # Loading Times Cold Boot Target <10 seconds --- Match Loading Target <15 seconds --- Respawn/Spectator <3 seconds --- # Memory Budget ## Runtime RAM Minimum Device Target ≤ **2.5 GB** Peak ≤ **3.0 GB** --- Texture Streaming Enabled Always. --- # Draw Calls Maximum Visible Target ≤ **180** Absolute Peak ≤ **250** The environment must use batching, GPU instancing, and LODs to stay within these limits. --- # Triangle Budget ## Character LOD0 25,000–30,000 triangles LOD1 15,000 LOD2 8,000 LOD3 2,000 --- ## Weapons LOD0 4,000–6,000 triangles LOD1 2,500 LOD2 1,000 --- ## Barrier LOD0 3,000–5,000 triangles LOD1 2,000 LOD2 800 --- ## Environment Props Small 200–800 triangles Medium 800–2,000 Large 2,000–8,000 Hero Landmark 10,000–20,000 Reserved only for major structures. --- # Texture Budgets ## Character One 2048×2048 atlas Normal map Shared materials where possible --- ## Weapons 1024×1024 --- ## Props 512×512 Common assets --- ## Hero Landmarks 2048×2048 Maximum --- ## Vegetation 512×512 shared atlas --- # Materials Character Maximum 3 materials --- Weapon Maximum 2 materials --- Prop Maximum 1 material Shared master materials should be used throughout the project. --- # Skinned Mesh Budget Maximum active skinned meshes on screen Target ≤ **30** This includes: * Players * Animated creatures (future) * Dynamic banners Static props are excluded. --- # Bones Maximum 120 bones per hero Finger bones included No facial rig at runtime. Facial expressions use blend shapes sparingly or are baked into animations. --- # Animation Target 30 FPS animation sampling Root motion minimized Animation compression enabled --- # Audio Budget Maximum simultaneous voices 32 Priority system: 1. Gunfire 2. Footsteps 3. Hero abilities 4. Barriers 5. Ambient 6. Music Gameplay audio always has priority. --- # Lighting Realtime lighting Minimum Baked GI wherever possible. One primary directional light. Limited realtime shadows. No dynamic GI. --- # Shadows Characters Enabled Medium quality --- Props Selective --- Vegetation Disabled on low settings --- # VFX Budget Maximum simultaneous major VFX 15 Particle count Kept below device-specific thresholds. GPU particles preferred where supported. --- # Network Budget 24 Players Server Tick 30 Hz Bandwidth Target <30 KB/s per client (average gameplay) Replication only for gameplay-critical objects. --- # Battery Target Average ≤ **12% battery consumption per 30 minutes** on the minimum supported device. This is a design target and must be validated during testing. --- # Thermal Target No sustained thermal throttling within: 30 minutes of continuous gameplay on the minimum supported device. --- # Asset Production Rules Every asset created must include: * Triangle count * Texture resolution * Material count * LODs * Memory estimate * Performance validation No asset enters production without these values. --- # LOD Policy Every 3D asset larger than 2,000 triangles must include: * LOD0 * LOD1 * LOD2 Hero landmarks require LOD3 if visible across long distances. --- # Performance Gates No asset is approved until it passes: * Triangle budget * Texture budget * Material budget * Draw-call impact * Memory validation * LOD validation * Mobile performance test --- # Hard Rule Every future document must reference this performance budget. If a designer requests: * Higher polygon counts * Larger textures * More materials The request must justify why it exceeds the established budget. Performance budgets cannot be ignored for visual preference alone. --- # 🔒 Final Performance Philosophy Astra is built for **consistent performance across a wide range of Android devices**, not maximum graphical fidelity. The game should feel: * Smooth * Responsive * Cool-running * Battery efficient * Quick to load A player should never lose a fight because their phone cannot maintain a stable frame rate. --- ## **One change I would make to Claude's recommendation** I would **not** lock the performance budget to a single phone model (for example, "Samsung Galaxy A54"). Android hardware changes too quickly, and regional markets differ. Instead, define **hardware classes**: * **Minimum Class** (Snapdragon 778G / Dimensity 1080 / Exynos 1380 equivalent) * **Recommended Class** (Snapdragon 8 Gen 2 equivalent) * **High-End Class** (latest flagship) That keeps the document relevant for years while still giving artists and engineers concrete budgets to target.

Just me saahil taggala

ASTRA only.

I actually think this is where Astra can become different from every other Battle Royale. Most games do this: * Desert * Snow * City * Forest They're just **different scenery**. I think Astra's zones should be **different combat philosophies**. A player should instantly know: > "I'm in Zone 4. I must fight differently." That is far more important than visual diversity. --- # AR-012 — The Ten Combat Zones (LOCKED) **Status:** APPROVED **Priority:** HIGH --- # World Philosophy The island is called # **Astra Dweep** An ancient sacred island where the balance of Prana has collapsed. Thousands of years ago, ten great civilizations flourished here. Each mastered a different aspect of Prana, leaving behind temples, cities, forests, and battlefields. Over time, nature reclaimed them, but their ruins remain. Every match is a struggle to survive while the island awakens again. Each zone represents a different civilization, terrain type, and combat style. --- # World Layout The map is divided into **10 major named zones** connected naturally by roads, rivers, caves, cliffs, forests, and ruins. Each zone must provide: * Unique visual identity * Unique combat style * Unique traversal * Different loot profile * Different risk level No two zones should play the same. --- # Zone 1 — Mahakaal Citadel ### Theme Ancient mountain fortress. Imagine: * Massive stone walls * Multi-level courtyards * Watch towers * Broken bridges * Sacred statues --- ### Combat Style Medium to long range. Strong sniper positions. Vertical combat. Lots of cover. --- ### Loot High --- ### Risk High --- ### Signature Landmark Temple throne overlooking the island. --- # Zone 2 — Brahma Bazaar ### Theme Ancient marketplace. Dense streets. Stone shops. Market squares. Collapsed roofs. --- ### Combat Style Close quarters. Fast fights. Many flank routes. Indoor combat. --- ### Loot Very High --- ### Risk Very High --- ### Signature Landmark Grand central trading hall. --- # Zone 3 — Ashram of Forgotten Rishis ### Theme Sacred monastery. Meditation gardens. Stone courtyards. Ancient libraries. Prayer halls. --- ### Combat Style Balanced. Medium range. Excellent for tactical teams. --- ### Loot Medium --- ### Risk Medium --- ### Signature Landmark Ancient Prana Shrine. --- # Zone 4 — Naga Jungle ### Theme Dense tropical jungle. Huge roots. Waterfalls. Hidden caves. Sacred snake ruins. --- ### Combat Style Ambush. Stealth. Short range. Limited visibility. --- ### Loot Medium --- ### Risk Medium --- ### Signature Landmark Giant serpent statue. --- # Zone 5 — Rudra Canyon ### Theme Rocky canyon. Massive cliffs. Natural bridges. Narrow passes. --- ### Combat Style High ground control. Long sightlines. Snipers. Vertical fights. --- ### Loot Medium --- ### Risk High --- ### Signature Landmark Stone bridge crossing the canyon. --- # Zone 6 — Sunken Mandap ### Theme Flooded temple complex. Half submerged. Stone platforms. Broken pillars. Shallow water. --- ### Combat Style Constant repositioning. Water crossings. Mixed range. --- ### Loot Medium --- ### Risk Medium --- ### Signature Landmark Submerged sanctum. --- # Zone 7 — Sky Temple ### Theme Temple built on floating cliffs. Suspension bridges. Broken staircases. Wind currents. --- ### Combat Style Extreme verticality. Risk vs reward. Excellent observation points. --- ### Loot High --- ### Risk Very High --- ### Signature Landmark Floating gateway. --- # Zone 8 — Pralaya River ### Theme Large sacred river. Stone crossings. Small islands. Marshland. Destroyed boats. --- ### Combat Style Rotations. Bridge fights. Open crossings. --- ### Loot Low --- ### Risk Medium --- ### Signature Landmark Ancient river gate. --- # Zone 9 — Agni Crater ### Theme Ancient volcanic basin. Black rock. Molten fissures. Steam vents. Collapsed shrines. --- ### Combat Style Open terrain. Limited cover. Fast aggressive fights. --- ### Loot High --- ### Risk Very High --- ### Signature Landmark Sacred Fire Altar. --- # Zone 10 — Temple of Creation ### Theme The heart of Astra. Gigantic temple. Perfect symmetry. Massive mandala floor. Golden architecture. --- ### Combat Style Final circle hotspot. Balanced. Every weapon viable. --- ### Loot Highest --- ### Risk Extreme --- ### Signature Landmark The Eternal Prana Core. --- # Zone Connectivity The island should feel like a real place. Zones connect through: * Stone roads * Jungle paths * Rope bridges * River crossings * Caves * Cliff trails * Ancient tunnels Players should always have multiple rotation options. --- # Loot Philosophy | Zone | Loot | Risk | | ------------------ | --------- | --------- | | Mahakaal Citadel | High | High | | Brahma Bazaar | Very High | Very High | | Ashram | Medium | Medium | | Naga Jungle | Medium | Medium | | Rudra Canyon | Medium | High | | Sunken Mandap | Medium | Medium | | Sky Temple | High | Very High | | Pralaya River | Low | Medium | | Agni Crater | High | Very High | | Temple of Creation | Highest | Extreme | High-risk zones offer better loot but attract more players. --- # Environmental Storytelling Every zone tells part of Astra's history. Players discover: * Broken murals * Ancient weapons * Ritual circles * Forgotten libraries * Destroyed observatories * Sacred trees * Prana crystals This creates world-building without forcing narrative. --- # Performance Design Each zone is built from reusable modular kits. Example: Temple Kit ↓ Citadel ↓ Ashram ↓ Temple of Creation share many assets. This reduces memory usage and production time. --- # Hard Rules Every zone must satisfy: * Recognizable silhouette. * Distinct combat identity. * Multiple entry and exit routes. * No dead-end camping areas. * Balanced loot distribution. * Mobile-friendly asset density. * Reusable modular construction. --- # 🔒 Final Design Philosophy Astra's zones are **not biome changes**—they are **combat identities**. A player should never think: > "This is just another jungle." Instead, they should think: * **Mahakaal Citadel** → "Expect long-range rooftop fights." * **Brahma Bazaar** → "Shotguns and close-quarters combat." * **Naga Jungle** → "Move slowly, watch for ambushes." * **Rudra Canyon** → "Control the high ground." * **Temple of Creation** → "This is where legends are made." If players can identify a zone purely from its combat experience—even with the textures removed—then the zone design has succeeded. That should be the design benchmark for every future map expansion.

I actually think this is where Astra can become **its own game**. This is where I disagree with most Battle Royale games. Most games do: * Find better gun. * Bigger number. * Win. That's boring. I think Astra should make **every weapon feel like it has a journey** during the match. Not permanent. Only **within the match**. That creates excitement without becoming pay-to-win. --- # AR-013 — The Ten Divine Weapon Families (LOCKED) **Status:** APPROVED **Priority:** HIGH --- # Weapon Philosophy Weapons are not "guns." Weapons are **Divine Prana Instruments**. Every weapon family represents one combat philosophy. Every weapon can evolve **during the match only**. Everything resets after the match. --- # Weapon Architecture Every weapon follows exactly the same lifecycle. ```text Weapon Found ↓ Collect Relics ↓ Evolution Level I ↓ Evolution Level II ↓ Catalyst Activated ↓ Avatar State ↓ Match Ends ↓ Everything Reset ``` This gives every match its own progression story. --- # Shared Weapon Rules Every weapon has: * Base Form * Evolution I * Evolution II * Avatar State Every weapon supports: * Relics * Catalyst * Cosmetic Skins No weapon has permanent upgrades. --- # THE TEN WEAPON FAMILIES --- # 1. Surya Stambh ## Class Assault Rifle --- ## Combat Style Balanced Medium Range Beginner Friendly --- ## Signature Solar Prana --- ## Magazine 30 --- ## Fire Rate Medium --- ## Damage Balanced --- ## Evolution Evolution I Solar accuracy improves. --- Evolution II Reduced recoil. --- Avatar Golden Prana rounds. Visual only. --- Best For Most players. --- # 2. Garuda Wing ## Class SMG --- Combat Style Mobility Close Range --- Magazine 40 --- Fire Rate Very High --- Evolution Movement speed while holding. ↓ Reload speed. ↓ Avatar Golden feather effects. --- # 3. Indra Garjana ## Class LMG --- Combat Style Suppressive Fire --- Magazine 80 --- High recoil. High sustained damage. --- Evolution Better stability. ↓ Cooling efficiency. ↓ Avatar Lightning barrel. --- # 4. Chandra Kiran ## Class DMR --- Combat Style Precision --- Magazine 15 --- Semi Auto. --- Evolution Reduced sway. ↓ Higher precision. ↓ Avatar Moonlight trail. --- # 5. Divya Netra ## Class Sniper --- Combat Style Extreme Range --- Magazine 5 --- High damage. Slow reload. --- Evolution Faster ADS. ↓ Steadier aim. ↓ Avatar Constellation scope. --- # 6. Naga Fang ## Class Shotgun --- Combat Style Close Combat --- Magazine 8 --- Heavy burst. --- Evolution Tighter spread. ↓ Faster pump. ↓ Avatar Serpent energy. --- # 7. Vajra Chakra ## Class Energy Launcher --- Combat Style Area Control --- Magazine 6 --- Slow fire. --- Evolution Larger impact radius. ↓ Faster projectile. ↓ Avatar Storm effects. --- # 8. Kala Danda ## Class Heavy Cannon --- Combat Style Anti Barrier --- Magazine 4 --- Very slow. Very powerful. --- Evolution Barrier damage. ↓ Armor penetration. ↓ Avatar Dark energy core. --- # 9. Brahma Sutra ## Class Beam Weapon --- Combat Style Continuous Fire --- Magazine Prana Based --- Consumes energy. --- Evolution Efficiency. ↓ Cooling. ↓ Avatar Pure white beam. --- # 10. Mahakaal Rudra ## Class High Risk / High Reward --- Combat Style Late Game --- Magazine 20 --- Very powerful. Hard to control. --- Evolution Recoil reduction. ↓ Stability. ↓ Avatar Black flame effects. --- # Weapon Evolution System Weapons evolve naturally during the match. Nothing is permanent. --- ## Evolution I Requires Two Relics. Example: ```text Surya Stambh ↓ Solar Crystal + Focused Lens ↓ Evolution I ``` Small gameplay improvement. Visual glow. --- ## Evolution II Requires Four Relics. Weapon becomes fully awakened. Slightly stronger handling. Visual changes. --- ## Avatar State Temporary. Requires Catalyst. Lasts 60 seconds. Visual transformation. Small tactical enhancement. Returns to Evolution II afterwards. --- # Relic System Relics are **attachments with mythology**. Instead of: * Scope * Grip * Stock Astra uses Relics. --- Every weapon supports **four Relic Slots**. --- ## Slot 1 Core Example: Solar Crystal Prana Core Rudra Eye --- ## Slot 2 Control Example: Focused Lens Stability Stone Wind Rune --- ## Slot 3 Enhancement Example: Sacred Coil Energy Chamber Divine Prism --- ## Slot 4 Blessing Example: Shiva Blessing Garuda Feather Lotus Sigil --- Players choose combinations. Not every Relic fits every weapon. --- # Catalyst System Catalysts are **rare temporary awakenings**. Every weapon has **one compatible Catalyst**. Example Surya Stambh ↓ Catalyst ↓ Sun Awakening 60 seconds. Visual transformation. Weapon temporarily reaches Avatar State. When the timer ends: Returns to Evolution II. Catalysts are very rare and intended to create memorable moments, not permanent power. --- # Weapon Rarity Weapon rarity affects: * Spawn frequency * Starting condition Not permanent ownership. A common Surya Stambh and a legendary Surya Stambh can both reach Avatar State if the player finds the required Relics and Catalyst during the match. --- # Audio Every family has: * Unique firing sound * Reload sound * Evolution sound * Avatar activation sound Players should identify the weapon without seeing it. --- # Performance All weapons share: * Animation rig * Attachment sockets * Material system * Shader pipeline Evolution uses: * Material swaps * Emissive masks * Small geometry additions No entirely separate weapon meshes. --- # Hard Rules Every weapon must follow: * Easy to recognise. * Distinct combat role. * One clear strength. * One clear weakness. * Gun skill remains primary. * Evolution improves handling, not raw dominance. * No permanent upgrades. * No pay-to-win. --- # 🔒 Final Design Philosophy Astra's weapon system is designed around **mastery during the match**, not progression across matches. Players do not become stronger because they have played longer or spent money. Instead, they become stronger because they: * Choose the right weapon. * Find the right Relics. * Build an effective loadout. * Decide when to activate a Catalyst. * Use the weapon skillfully. This creates a satisfying sense of progression within every match while preserving competitive fairness between new and veteran players. --- ## **One thing I would change from our earlier discussions** I would **remove stat increases from Evolution I and II**. Instead: * **Evolution I** = unlocks the first Relic slot. * **Evolution II** = unlocks the remaining Relic slots and cosmetic transformation. * **Avatar State** = the only temporary gameplay enhancement, lasting 30–60 seconds. Why? If Evolution itself directly increases damage or recoil every match, lucky players who find Relics early snowball too hard. Instead, let **Relics** define the build and let the **Catalyst/Avatar State** create the exciting "power moment." That keeps the match fairer while still making the weapon progression feel meaningful.

This is where I think Astra can be **far better balanced** than Free Fire. One thing I don't like in many hero shooters is that abilities become more important than aiming. I want Astra to be: > **80% Gun Skill** > **20% Hero Ability** That ratio should never change. So before designing heroes, we need something AAA studios use internally. --- # Ability Impact Budget (AIB) Every hero ability consumes from a **100-point Impact Budget**. Think of it as a balancing currency. ```text 100 Points Maximum Damage ............... 25 Mobility ............. 20 Vision ............... 20 Defense .............. 20 Utility .............. 15 Total = 100 ``` No hero may exceed the total. This makes balancing measurable instead of emotional. --- # Hero Rules (Locked) Every Hero has: * 1 Passive * Ability 1 (Core) * Ability 2 (Support) * Master Ability (Unlocks later) Only **2 active abilities can be equipped** at launch. Master Ability unlocks after Hero Mastery. Every ability follows: * Cooldown: 25–45 sec * Activation Time: <0.5 sec * Counterplay Available * Cannot instantly kill * Cannot ignore cover --- # HERO 1 — HANUMAN ## Role Mobility / Entry --- Passive ### Monkey Agility * Vault 20% faster * Climb 25% faster * Landing recovery reduced No combat damage increase. --- Ability 1 ## Vajra Leap Cooldown 30 sec Cost 25 Prana Effect Leap forward approximately 18–20 meters. Can reach rooftops. Cannot attack during leap. Landing has a short recovery. Impact Budget Mobility: 18 Utility: 2 Total: 20 --- Ability 2 ## Wind Dash Cooldown 25 sec Cost 20 Prana Quick horizontal dash. Distance 6 meters. Cannot pass through walls. Budget Mobility: 10 Utility: 5 --- Master Ability ## Mountain Resolve Cooldown 90 sec Gain temporary resistance to knockback and faster reload for 12 seconds. No damage boost. --- # HERO 2 — RAVANA ## Role Aggressive Assault --- Passive ### Scholar of Lanka Reload speed +10% Weapon swap faster. --- Ability 1 ## Tenfold Wrath Cooldown 40 sec Cost 35 Prana Duration 8 sec Effect * Recoil reduced * Hip-fire accuracy improved * No damage increase Budget Offense: 12 Utility: 8 --- Ability 2 ## Battle Chant Cooldown 35 sec Cost 25 Prana Nearby teammates receive: * Faster reload * Slight recoil stability Radius 12 m Budget Support: 10 Utility: 10 --- Master Ability ## King's Command Nearby teammates instantly reload. No damage buff. --- # HERO 3 — SITA ## Role Recon / Survival --- Passive ### Serenity Footsteps 20% quieter. --- Ability 1 ## Astral Projection Cooldown 40 sec Cost 35 Prana Duration 6 sec Body remains vulnerable. Spirit scouts freely. Cannot attack. Budget Vision: 18 Utility: 7 --- Ability 2 ## Sacred Veil Cooldown 30 sec Cost 20 Prana Creates a short-lived visual distortion that makes it harder for enemies to track movement through it. No invisibility. Budget Defense: 10 Utility: 10 --- Master Ability ## Divine Sanctuary Small safe zone for healing. No invulnerability. --- # HERO 4 — KRISHNA ## Role Control --- Passive ### Divine Insight Enemy footsteps become audible from a slightly greater distance. --- Ability 1 ## Sudarshan Guidance Cooldown 35 sec Cost 30 Prana Launches an energy disc. Tracks only once. Deals moderate damage. Cannot kill a full-health player alone. Budget Damage: 10 Utility: 10 --- Ability 2 ## Maya Pulse Cooldown 35 sec Cost 25 Prana Briefly reveals enemies within 15 m. No wallhack beyond the pulse. Duration 2 sec Budget Vision: 15 Utility: 5 --- Master Ability ## Divine Strategy Entire Duo team sees enemy positions for 3 sec after first contact. --- # HERO 5 — ARJUNA ## Role Precision --- Passive ### Focused Archer ADS sway reduced. No recoil reduction. --- Ability 1 ## Divine Focus Cooldown 30 sec Cost 25 Prana Marks one visible enemy. Team sees marker. Duration 6 sec Budget Vision: 15 Utility: 5 --- Ability 2 ## Eagle Eye Cooldown 35 sec Cost 20 Prana Zoom vision slightly without using a scope. Useful for spotting enemies. Budget Vision: 10 Utility: 5 --- Master Ability ## Perfect Shot First bullet fired within 5 seconds has no weapon sway. Does **not** increase damage. --- # Ability Budget Table | Hero | Mobility | Damage | Vision | Defense | Utility | Total | | ------- | -------: | -----: | -----: | ------: | ------: | ----: | | Hanuman | 28 | 0 | 0 | 0 | 12 | 40 | | Ravana | 0 | 12 | 0 | 0 | 28 | 40 | | Sita | 0 | 0 | 18 | 10 | 17 | 45 | | Krishna | 0 | 10 | 15 | 0 | 15 | 40 | | Arjuna | 0 | 0 | 25 | 0 | 10 | 35 | No hero exceeds the intended impact ceiling. --- # Counterplay Matrix | Hero | Counter | | ------- | ---------------------------------------- | | Hanuman | Track landing, punish recovery | | Ravana | Wait out buff duration | | Sita | Attack vulnerable body during projection | | Krishna | Break line of sight after pulse | | Arjuna | Reposition after being marked | Every ability has a clear answer. --- # Hard Rule #011 (Made Measurable) Instead of simply saying: > **Abilities assist, gun skill wins.** We define measurable limits: * No ability may deal more than **25% of a full-health player's HP** by itself. * No ability may provide more than **3 seconds of unavoidable information**. * No mobility skill may ignore map geometry. * No defensive skill may grant invulnerability. * No hero ability may replace weapon mastery as the primary method of securing eliminations. --- ## One thing I would change from our previous discussions I would **remove every direct damage buff**. Originally we discussed Ravana increasing weapon damage. I don't think we should do that. Instead: * Improve handling. * Improve positioning. * Improve information. * Improve mobility. * Improve teamwork. But **never** increase raw weapon damage. That keeps every firefight fundamentally about the weapon in the player's hands and the decisions they make, which is exactly what Hard Rule #011 is trying to protect.

This is one of the systems I think we can make **better than Free Fire's Gloo Wall**. The mistake would be trying to make **10 different barriers**. That creates balancing nightmares. Instead, I would make **ONE core barrier system** with different visual families and tactical roles. This keeps it simple, competitive, and easy to balance. --- # AR-015 — Divine Barrier System (LOCKED) **Status:** APPROVED **Priority:** HIGH --- # Purpose The Barrier System is Astra's equivalent of **Free Fire's Gloo Wall**. However, barriers are **not** just emergency walls. They are tactical tools that: * Create temporary cover * Enable revives * Block enemy sightlines * Control movement * Support team rotations * Create counterplay in open terrain The Barrier System exists to **extend tactical decision-making**, not to replace gun skill. --- # Core Philosophy > **A barrier should buy time, not guarantee survival.** Every barrier can be: * Broken * Flanked * Outplayed * Waited out A barrier should never make a player invincible. --- # Player Rules Every player starts every match with: * **1 Barrier Slot** Barriers are found through loot. Only **one barrier type** can be equipped at a time. Changing barriers replaces the previous one. No stacking. --- # Deployment Deployment Time **0.4 seconds** Reason Fast enough to react. Slow enough to punish panic. --- # Lifetime Barrier Duration 30 seconds Barrier disappears automatically. No permanent structures. --- # Health Barrier HP Approximately **400 HP** Destroyed by sustained fire. Heavy weapons destroy faster. --- # Inventory Barrier occupies **one dedicated inventory slot**. Separate from * Weapons * Healing * Runes Players always know where it is. --- # Barrier Categories Instead of ten unrelated barriers, Astra launches with **five tactical families**. Each family has the same base HP and lifetime, but different behaviour. --- # 1. Shila-Stambh **Role:** Standard Cover The default barrier. Visual Ancient stone slab rises from the earth. Characteristics * Flat wall * Medium width * High durability * Best all-round choice Use Case Emergency cover. Rotation. Healing. Revive. --- # 2. Vajra Dome **Role:** Defensive Bubble Creates a small protective dome. Characteristics * Circular * Smaller than Shila * Excellent for Duo revives * Cannot be stacked Use Case Final circles. Healing. Revive. --- # 3. Vana Barrier **Role:** Natural Cover Large sacred roots emerge. Characteristics * Irregular shape * Slight camouflage * Excellent inside jungle zones Use Case Ambush. Stealth. Forest fights. --- # 4. Varuna Wall **Role:** Vision Control Flowing sacred water. Characteristics * Distorts visibility * Slightly slows projectiles visually * Excellent for crossing open ground Use Case River crossings. Retreat. Rotation. --- # 5. Rudra Pillars **Role:** Movement Cover Three stone pillars emerge. Characteristics * Multiple cover points * Encourages aggressive peeking * High skill ceiling Use Case Competitive play. --- # Barrier Interaction Rules Barriers interact with the world. Examples Fire ↓ Burns vegetation around barrier. --- Lightning ↓ Damages water barriers more effectively. --- Explosive weapons ↓ Deal increased damage. --- No barrier is immune. Every barrier has a counter. --- # Combat Balance Barrier is a **defensive utility**, not an offensive weapon. Barrier cannot: * Deal damage * Trap enemies * Reflect bullets * Stun opponents Barrier only creates tactical opportunities. --- # Deployment Restrictions Barriers cannot be placed: * Inside other barriers * Inside solid walls * On extremely steep slopes * On rooftops with insufficient space * In invalid geometry Automatic placement preview appears before deployment. --- # Cooldown Barrier cooldown begins after deployment. Cooldown **25 seconds** Prevents barrier spam. --- # Loot Economy Barrier rarity affects **appearance only**, not strength. Example Common ↓ Stone texture. Rare ↓ Gold engravings. Legendary ↓ Floating sacred runes. Gameplay remains identical. --- # Duo Strategy Barrier becomes a key teamwork tool. Example Player A deploys Shila-Stambh. Player B revives teammate. Barrier expires. Team rotates. This encourages coordination without introducing complex mechanics. --- # Audio Design Every barrier has a unique deployment sound. Shila Deep stone impact. Vajra Electric hum. Vana Roots breaking ground. Varuna Flowing water. Rudra Stone pillars erupting. Players can identify barrier type without seeing it. --- # Visual Design Barrier silhouettes are intentionally distinct. This follows **Hard Rule #003** Silhouette First. Even on Low graphics: * Flat wall * Dome * Roots * Water sheet * Pillars are immediately recognizable. --- # Technical Design Implementation uses a **shared barrier framework**. Common systems: * Placement * Health * Lifetime * Network synchronization * Destruction * Animation timing Only visuals and behaviour differ. This minimizes code duplication and simplifies balancing. --- # Performance Budget Maximum active barriers: * Solo: **8** * Duo: **12** Oldest barriers automatically despawn if the global limit is exceeded. Barrier meshes use: * Shared materials * Shared shaders * Shared destruction effects Designed to support low-end Android devices. --- # Future Expansion Additional barrier skins and visual themes may be introduced over time. Examples: * Temple Stone * Black Granite * Lotus Marble * Crystal Shrine * Sacred Sandstone These are **cosmetic variants only**. Gameplay characteristics remain unchanged. --- # Hard Rules The Barrier System must always obey: * **Gun skill remains the deciding factor.** * **Barriers create opportunities, not guarantees.** * **Every barrier has clear counters.** * **Barrier placement must be predictable and readable.** * **No pay-to-win barrier variants.** * **Performance takes priority over visual complexity.** --- # 🔒 Final Design Philosophy The Barrier System exists to make firefights more tactical without slowing the pace of the game. A good player uses barriers to: * Reposition * Revive * Heal * Create angles * Survive rotations —not to become invulnerable. The goal is for barriers to become **a skill expression tool**, much like the Gloo Wall in Free Fire, but integrated naturally into Astra's mythological world and designed from day one around fairness, readability, and mobile performance.

1. Match Structure Match Duration Target: 10 minutes Reasoning: Mobile players prefer short sessions. Allows multiple matches in a lunch break. Reduces battery usage. Faster matchmaking. Target Flow Phase Duration Landing & Loot 2 minutes Mid Game 5 minutes Final Circles 3 minutes 2. Player Count Players 24 Modes Solo Duo No Squad at launch. Reason Easier balancing. Lower server cost. Better performance. Faster matchmaking. 3. Map Size Playable Area 1 km × 1 km Reason Designed around 24 players 10 minute matches Fast rotations Minimal downtime 4. Safe Zone System Total Circles 6 Circle Duration Circle 1 120 sec Circle 2 90 sec Circle 3 75 sec Circle 4 60 sec Circle 5 45 sec Final Circle 30 sec Final circle should always force combat. Never allow healing contests. 5. Time To Kill (TTK) Target 0.9–1.3 seconds Reason Fast enough to reward good aim. Slow enough to deploy barriers. Gives players time to react. Never instant death. 6. Health System Every player starts with: Health: 100 HP Kavach (Shield): 100 Shield Prana: 100 Energy Maximum Effective Health 200 Simple. Easy to understand. 7. Damage Model Damage order Shield ↓ Health No exceptions. Example Enemy hit for 30 Shield 100 → 70 Health unchanged. 8. Headshots Headshot Multiplier 1.8× Never 2.5× Never instant kill. Reason Maintains competitive balance. 9. Character Abilities Abilities consume Prana. Abilities NEVER consume Health. Abilities NEVER consume Shield. Every ability follows Cooldown 30–45 seconds Prana Cost 20–40 Maximum one active ability at a time. 10. Weapon System Each player carries 2 Weapons 1 Divine Ability No third firearm. No backpack full of weapons. Simple. 11. Inventory Maximum inventory slots Item Slots Weapon 1 1 Weapon 2 1 Barrier 1 Healing 4 Rune 3 Relics Equipped directly No inventory management simulator. 12. Healing System Launch Items Jal Quick heal 20 HP Fast use. Soma Medium heal 50 HP Amrit Full heal 100 HP Rare. Healing cannot exceed maximum HP. Healing does NOT restore Shield. 13. Kavach (Shield) Restored by Shield Cells 50 Shield Shield Core 100 Shield Rare. Healing items do not restore Shield. 14. Prana Restored by Prana Crystal 50 Prana Prana Shrine Full restore Map objective Natural regeneration Slow Approximately 5 Prana every 10 seconds after being out of combat. 15. Duo Revive Allowed Only in Duo. Revive Time 6 seconds Interrupted by Damage Movement Death No instant revive. 16. Barrier System Players carry ONE Barrier. Barrier deployment 0.4 seconds Barrier HP Approximately 400 Lasts 30 seconds Maximum One active barrier per player. 17. Recoil Philosophy Every weapon has recoil. No laser beams. Pattern Predictable. Skill based. No random bloom while aiming. 18. Aim Assist Mobile only. Strength Low. Purpose Counter thumb limitations. Never lock onto targets. Never track through walls. Can be disabled. 19. Movement Movement Speed 100% Sprint 115% Slide Momentum based Jump Consistent height No stamina system. Players should never stop moving because of exhaustion. 20. Traversal Allowed Vault Climb Ladder Zipline Rope Water Not allowed Wall running Double jump Jetpacks Flying 21. Friendly Fire Disabled Always. 22. Loot Philosophy Landing Player should find A usable weapon within 15–20 seconds. Never make players search multiple buildings just to fight. 23. Death Player eliminated ↓ Loot crate drops ↓ Spectator mode ↓ Return to lobby after match No respawn in Solo. No buyback system. 24. Victory Condition Last player or Last Duo alive Wins. No score system. No objectives replacing survival. 25. Combat Design Principles Every combat mechanic must satisfy these rules: Gunplay is the primary skill. Abilities create opportunities, not guaranteed kills. Barriers provide temporary cover, not invulnerability. Movement should feel fast and responsive without becoming unrealistic. Every firefight should allow meaningful counterplay. The player should always understand why they won or lost. 🔒 Final Combat Philosophy Astra should sit between Free Fire and PUBG Mobile in terms of pacing: Faster and more fluid than PUBG Mobile. More tactical and readable than Free Fire. Less ability-dependent than Apex Legends. Simpler than Valorant. Entirely fair with no pay-to-win progression. The guiding principle is: Every match should be easy to start, quick to finish, and deep enough that improving aim, positioning, timing, and decision-making is always more valuable than unlocking stronger equipment. This document should become the foundation for all balancing, animation timing, VFX, networking, AI behavior, and future playtesting. Once these values are locked, changes should only happen after measurable playtest evidence, not intuition.

This is actually where I disagree with Claude's estimate. > **"2,000–4,000 unique assets."** That's true for a traditional AAA pipeline. **But that is NOT how we're building Astra.** One of our Hard Rules is: > **Everything must be modular and reusable.** We're building like **Fortnite**, **Valorant**, and **Supercell**, not like Assassin's Creed. That changes everything. --- # AR-018 — Team, Budget & Production Schedule (LOCKED) **Status:** APPROVED **Priority:** HIGH --- # Production Philosophy Astra is **AI-first, modular-first, solo-founder-first**. The objective is **not** to build thousands of handcrafted assets. The objective is to build a **small number of high-quality modular systems** that can generate thousands of gameplay combinations. The project intentionally minimizes traditional content production by leveraging: * AI-assisted concept generation * AI-assisted 3D asset generation * Modular environment kits * Shared character skeletons * Shared material libraries * Shared animation libraries * Procedural assembly where appropriate --- # Project Timeline Estimated duration to Public Launch **18–24 months** Broken into structured milestones. --- # Phase 0 — Foundation **Duration:** 2 months Status Completed / In Progress Deliverables * Vision * Hard Rules * Complete GDD * Technical Architecture * Production Bible * Combat Balance Bible * ProjectOS * Art Direction * UI System * Asset Taxonomy Gate No production begins until documentation is complete. --- # Phase 1 — Vertical Slice Duration 3 months Objective Prove that Astra is fun. Contains * One map section * Two heroes * Three weapons * Loot * Barrier system * Complete combat loop * Networking * One complete playable match Success Criteria The game is enjoyable without additional content. Gate Playtest approval before expanding. --- # Phase 2 — Alpha Duration 5 months Contains * Five heroes * All ten weapon families * Complete map * Solo mode * Duo mode * Matchmaking * Progression * Cosmetics foundation * Core UI * Audio Gate Feature Complete. No new gameplay systems after this point. --- # Phase 3 — Beta Duration 4 months Focus Optimization. Tasks * Performance * Balancing * Bug fixing * Device compatibility * Telemetry * Anti-cheat * LiveOps preparation Gate Stable on target devices. --- # Phase 4 — Release Duration 2–4 months Focus Store Marketing Community Launch readiness Submission Soft Launch Global Launch --- # Team Structure ## Phase 0–1 Founder * AI Only. AI acts as: * Technical Architect * Game Designer * Producer * Documentation Assistant * Concept Artist * Technical Writer External help only if required. --- ## Phase 2 Founder * Freelance Artist * Animator * Audio Designer As needed. No permanent hires. --- ## Phase 3 Additional QA Part-time Only if required. --- ## Phase 4 Community Support LiveOps Added only after launch. --- # Budget Strategy The project prioritizes ownership over outsourcing. Major expenses include: * Development hardware * Unity licensing (if required) * Server hosting (Contabo) * AI services (Claude, ChatGPT, image generation, Tripo AI, etc.) * Audio tools * Store accounts * Marketing * Contract specialists for high-impact assets The goal is to minimize recurring costs through automation and reusable systems. --- # Asset Production Philosophy Astra does **not** target 2,000–4,000 handcrafted assets. Instead, production is based on **modular asset libraries**. Example Temple Kit * 25 modular pieces Can produce Hundreds of unique temple layouts. --- Vegetation Kit * 15 tree variants Produces Entire forests. --- Rock Kit * 10 meshes Produces Hundreds of natural formations. --- Character Kit One shared skeleton ↓ Modular armor ↓ Modular cloth ↓ Modular accessories Supports dozens of visual combinations. --- Barrier Kit One shared framework ↓ Different materials ↓ Different effects ↓ Different mythology themes --- # Estimated Production Assets Instead of counting final placed objects, we count reusable production assets. | Category | Estimated Modules | | ------------------ | ----------------: | | Characters | 5 launch heroes | | Shared Skeleton | 1 | | Armor Modules | 60–80 | | Weapons | 10 | | Barrier Types | 10 | | Environment Kits | 8–10 | | Vegetation Modules | 20–30 | | Props | 80–120 | | VFX | 80–120 | | Audio | 300–500 | | UI Components | 120–180 | This is a realistic production scope for a solo founder using AI-assisted workflows. --- # Production Gates No phase may proceed without meeting predefined quality gates. ### Gate 1 — Design Freeze All core systems documented and approved. --- ### Gate 2 — Vertical Slice Approval Core gameplay proven fun. --- ### Gate 3 — Feature Freeze No new gameplay mechanics. Only balancing and polish. --- ### Gate 4 — Performance Certification Target frame rates achieved across supported device classes. --- ### Gate 5 — Launch Readiness Critical bugs resolved. Backend stable. Telemetry operational. Store approved. --- # Risk Management The project actively controls scope through the following principles: * No feature enters production without documentation. * No asset is created without a defined owner and purpose. * Modular assets are preferred over unique one-off assets. * Systems are completed before expanding content. * Performance budgets are enforced from the first asset. * Content additions require measurable gameplay value. --- # Success Criteria The project is considered on schedule when: * Every milestone passes its quality gate. * Vertical Slice proves the combat loop. * Alpha reaches feature completeness without scope expansion. * Beta focuses exclusively on optimization and stability. * Launch delivers a polished, fair, performance-first battle royale experience. --- # 🔒 Final Production Strategy Astra is **not** attempting to compete with the asset volume of major AAA studios. Instead, it competes through: * Strong systems design * Reusable modular content * AI-assisted production * Performance-first engineering * Tight scope control * High-quality execution The objective is to build **a scalable platform**, not a one-time game. Every asset, system, and workflow is designed to support years of expansion without requiring exponential increases in team size or production cost. --- ## One recommendation I'd add I would add a **Scope Guard** to the Production Bible: > **Any feature that delays the Vertical Slice by more than two weeks is automatically deferred unless it directly improves the core combat loop.** That single rule protects the project from feature creep, which is one of the biggest risks for an ambitious solo game project like Astra.

This is actually one of the most important architectural decisions in the project. My recommendation is **don't build everything yourself**. Use **Unity Gaming Services (UGS)** where they are already excellent, and build **only the parts that make Astra unique**. You're one founder. Your advantage is the game, not writing another authentication system. --- # AR-020 — Backend, Store & Telemetry (LOCKED) **Status:** APPROVED **Priority:** HIGH --- # Backend Philosophy Astra follows a **Hybrid Backend Architecture**. The project uses: * **Unity Gaming Services (UGS)** for multiplayer infrastructure. * **Custom Aurion Backend** for game-specific systems. Rule: > Never rebuild infrastructure that already exists and is battle-tested. Only build systems that are unique to Astra. --- # High Level Architecture ```text MOBILE CLIENT │ Unity Netcode (NGO) │ ┌──────────────┴──────────────┐ │ │ Unity Gaming Services Aurion Backend │ │ │ │ Authentication Player Profile Matchmaking Inventory Lobby Cosmetics Relay (Early MVP) Store Cloud Diagnostics Progression Analytics Seasons Crash Reporting Economy ProjectOS LiveOps Admin Panel Asset Database Telemetry Warehouse ``` --- # Unity Gaming Services (UGS) UGS is responsible only for **multiplayer infrastructure**. ## Authentication UGS Authentication Supports * Google * Apple * Guest * Facebook (optional later) Reason Don't build login systems. --- ## Lobby UGS Lobby Responsible for * Creating matches * Inviting friends * Duo queue Nothing else. --- ## Matchmaking UGS Matchmaker Responsible for Finding players. Not progression. Not inventory. --- ## Relay (Early Development) Used during MVP and Alpha. Later Can migrate to dedicated servers. --- ## Cloud Diagnostics Crash reports Stack traces Performance logs Device issues --- ## Remote Config (Recommended) Enable/disable events XP multipliers Season switches Without updating the app. --- # Aurion Backend (Custom) Everything unique to Astra lives here. --- ## Player Profile Stores * Name * Avatar * Level * Hero Mastery * Weapon Mastery * Legend Progression * Statistics --- ## Inventory Stores * Owned cosmetics * Character unlocks * Weapon skins * Barrier skins * Emotes * Banners Gameplay items NEVER stored here. Relics and runes are **match-only**. --- ## Store Handles * Cosmetic catalogue * Seasonal bundles * Temple Journey rewards * Featured items Never contains gameplay power. --- ## Entitlement Service One of the most important systems. Every purchase creates Permanent entitlement. Example ``` Player ↓ Purchased Hanuman Sacred Armor ↓ Entitlement Created ↓ Inventory Updated ↓ Immediately available ``` Nothing is unlocked until Entitlement exists. --- ## Progression Tracks Player Hero Weapon Legend Battle Pass Everything cosmetic. --- ## Seasons Stores Current Season Past Seasons Rewards Availability --- ## ProjectOS Lives inside Aurion Backend. Completely separate from game runtime. --- ## Admin Dashboard Used by developers. Can * Add cosmetics * Enable events * View analytics * Moderate players * Ban accounts --- # Store Architecture ```text Store ↓ Category ↓ Item ↓ Price ↓ Availability ↓ Purchase ↓ Validation ↓ Entitlement ↓ Inventory ↓ Player ``` Everything server validated. --- # In-App Purchases (IAP) Platform stores remain the payment provider. * Apple App Store * Google Play Flow: 1. Player selects cosmetic. 2. Platform completes payment. 3. Receipt sent to Aurion Backend. 4. Backend validates receipt with Apple/Google. 5. Backend creates entitlement. 6. Inventory updates. 7. Client refreshes inventory. Never trust the client. --- # Cosmetics Stored server side. Player cannot modify. Every cosmetic identified by UUID. --- # Telemetry Every important event should be recorded. Examples Match Started Match Finished Player Eliminated Weapon Used Barrier Used Ability Activated Hero Selected Zone of Death Loot Picked Store Viewed Purchase Completed Crash Disconnect Ping FPS Battery Device Model Everything anonymous where possible and compliant with applicable privacy laws. --- # Analytics Dashboard ProjectOS should visualize: Gameplay * Match duration * Win rate * Hero usage * Weapon usage * Barrier usage * Average survival time * Hot drop locations Technical * FPS * RAM usage * Battery usage * Crash rate * Network latency * Device distribution Business * DAU * MAU * Retention * Session length * Conversion * Revenue * Cosmetic popularity --- # Security The client is never trusted. The server validates: * Purchases * Inventory * Progression * Rewards * Match results * Statistics * Unlocks Clients only request actions. Servers approve them. --- # Database Single PostgreSQL database. Dedicated schema ``` astra ``` Tables * accounts * profiles * inventory * cosmetics * entitlements * progression * hero_mastery * weapon_mastery * seasons * telemetry * purchases * bans * analytics * liveops Prisma manages all migrations. --- # LiveOps Aurion Backend controls * Events * Seasons * Featured Store * Login Rewards * Maintenance * Emergency balancing * Server announcements No client update required. --- # 🔒 Final Architecture Decision | System | Owner | | ---------------------- | --------------------------------- | | Authentication | Unity Gaming Services | | Lobby | Unity Gaming Services | | Matchmaking | Unity Gaming Services | | Relay (MVP) | Unity Gaming Services | | Dedicated Game Servers | Contabo (server-authoritative) | | Game Simulation | Unity Dedicated Server on Contabo | | Player Profile | Aurion Backend | | Inventory | Aurion Backend | | Cosmetics | Aurion Backend | | Store | Aurion Backend | | Entitlements | Aurion Backend | | Progression | Aurion Backend | | Seasons | Aurion Backend | | LiveOps | Aurion Backend | | ProjectOS | Aurion Backend | | Telemetry Storage | Aurion Backend (PostgreSQL) | | Crash Diagnostics | Unity Gaming Services | | Remote Configuration | Unity Gaming Services | --- ## Recommendation I would make **one change** to our earlier plan. For launch, use **UGS Matchmaking + Lobby**, but **do not rely on Relay for production matches**. Instead: * Use **Unity Dedicated Server builds** running on your **Contabo VPS infrastructure**. * Let **UGS handle player discovery and match formation**. * Once a match is formed, players are handed off to a dedicated authoritative game server. This keeps the gameplay fair, reduces cheating, scales better, and gives you full control over server costs and infrastructure while still benefiting from Unity's mature multiplayer services.

This is another place where I think Claude is **100% right**, and it's actually pointing out something more important than the contradiction. It's pointing out a **game design problem**. Let's think like Riot, Valve and Supercell. --- ## The Question Originally we had: ``` Weapon ↓ Evolution I (+ Better recoil) ↓ Evolution II (+ Better stability) ↓ Avatar ``` That creates a snowball effect. The player who lands on better Relics early gets: * Better recoil * Better stability * Better accuracy Then wins more fights. Then gets more loot. Then gets even stronger. That's called a **positive feedback loop**, and Battle Royale games generally try to avoid making early luck too decisive. --- # The Better Solution I actually think we should remove the concept of **Evolution** entirely. Not rename it. Remove it. Because what is Evolution actually doing? Nothing. It's just another progression layer. We already have ``` Weapon ↓ Relics ↓ Catalyst ↓ Avatar State ``` That's enough. --- # My Proposed Weapon System ``` Weapon ↓ 4 Relic Slots ↓ Catalyst ↓ Avatar State ↓ Match Ends ↓ Reset ``` Simple. Elegant. Easy to balance. --- # Relics become the Build Instead of ``` Evolution I ↓ +10 Stability ``` We make ``` Relic ↓ Stability Rune ``` Instead of ``` Evolution II ↓ +15 Reload ``` We make ``` Relic ↓ Reload Chamber ``` Now the player chooses. Not the weapon. --- # Example Surya Stambh Player A ``` Core Solar Crystal Control Wind Stabilizer Enhancement Extended Magazine Blessing Lotus Sigil ``` Balanced rifle. --- Player B ``` Core Fire Core Control Rapid Trigger Enhancement Light Barrel Blessing Rudra Mark ``` Aggressive rifle. Same weapon. Different build. --- # Catalyst This becomes the exciting moment. Instead of Evolution II ↓ Avatar We simply have ``` Weapon ↓ Relics ↓ Catalyst Found ↓ Avatar State ↓ 60 sec ↓ Returns to Normal ``` This is much cleaner. --- # Avatar State Avatar should be THE ONLY temporary power spike. Not Evolution. Example Surya Normal ↓ Golden beam ↓ Magazine glows ↓ Shots leave trails ↓ Slight handling improvement ↓ Ends ↓ Normal That's exciting. --- # What about Relic Slots? I would NOT unlock Relic Slots. I would keep all four available immediately. Otherwise we've recreated another progression system. Instead: Players must FIND the Relics. The slots are always there. --- # Relic Categories ``` Weapon ↓ Core ↓ Control ↓ Enhancement ↓ Blessing ``` One Relic per category. Very easy. --- # Loot Economy Now imagine You find ``` Surya ↓ No Relics ``` Later You find ``` Wind Stabilizer ``` Your gun immediately feels better. Later You find ``` Lotus Blessing ``` Now your build changes. This is exciting. --- # This removes... * Evolution UI * Evolution XP * Evolution balancing * Evolution animation * Evolution bugs * Evolution documentation One entire system disappears. --- # This follows our philosophy Remember what we locked. > Easy to learn. Deep to master. Evolution doesn't make the game deeper. It makes it more complicated. Relics already provide the depth. --- # 🔒 AR-023 — Final Decision (LOCKED) ## Evolution System **Removed from Astra V1.** Weapons no longer have: * Evolution I * Evolution II These concepts are replaced by: * Four Relic Slots (available immediately) * One Catalyst Slot * One temporary Avatar State --- ## Weapon Progression Every match follows this structure: ```text Spawn ↓ Find Weapon ↓ Find Relics ↓ Complete Build ↓ Find Catalyst ↓ Activate Avatar State ↓ Avatar expires ↓ Continue Match ↓ Match Ends ↓ Everything Resets ``` --- ## Permanent Rule Every weapon has: * 4 Relic Slots * 1 Catalyst Slot Relic Slots are always unlocked. Players fill them through looting. No progression. No account power. No level requirements. --- ## Avatar State Avatar State is the **only temporary combat enhancement**. Requirements: * Weapon equipped * Compatible Catalyst found * Activation by player Duration: 30–60 seconds. After expiration: Weapon returns to its Relic build. --- ## Hard Rules Protected This decision reinforces: * ✅ Hard Rule #001 — Simplicity and performance (one less gameplay system). * ✅ Hard Rule #005 — Identity over power. * ✅ Hard Rule #006 — No persistent gameplay advantage. * ✅ Hard Rule #011 — Gun skill remains primary. --- ### One additional recommendation I would also **rename "Relics" internally** to **Weapon Relics** in the documentation. Why? Because we also have world lore, shrines, and mythological relics. Saying "Relic" everywhere will eventually become ambiguous. So the terminology becomes: * **Weapon Relics** → Gameplay attachments. * **Ancient Relics** → Lore objects and world collectibles. * **Catalysts** → Temporary weapon awakening items. That small naming change will make the documentation much clearer as the project grows.

This is another **excellent review**, and I completely agree. This isn't just a documentation issue—it's an architectural decision. You cannot have: * **60 Hz** in one section. * **30 Hz** in another. Every subsystem depends on this value: * Network bandwidth * Server CPU * Client interpolation * Hit registration * Lag compensation * Server cost * Battery consumption There must be **one source of truth**. --- # AR-007 Amendment — Server Tick Rate (LOCKED) **Status:** APPROVED **Priority:** CRITICAL --- # Final Decision **Astra Version 1.0 will run at a fixed 30 Hz server simulation.** There is **no 60 Hz server simulation** in Version 1. All references to 60 Hz in the documentation are removed. --- # Why 30 Hz? Astra is designed as a: * Mobile-first * 24-player * Server-authoritative * Performance-first Battle Royale For these constraints, 30 Hz provides the best balance between: * Gameplay responsiveness * Server CPU utilization * Network bandwidth * Battery consumption * Hosting cost --- # Server Simulation Server Tick Rate **30 Hz** Meaning The dedicated server updates the world 30 times every second. --- # Client Rendering The client renders independently of the server. Examples | Device | Rendering | | ----------------- | ------------------------------------------------: | | Low-end Android | 30 FPS | | Mid-range Android | 60 FPS | | High-end Devices | 60 FPS (120 FPS rendering may be evaluated later) | Rendering FPS and server tick rate are independent. --- # Why Not 60 Hz? Although 60 Hz offers lower latency, it introduces significant costs: * Approximately double the server simulation workload. * Higher outbound bandwidth. * Higher CPU requirements. * Increased hosting costs. * Greater battery consumption on mobile devices. For Astra's launch objectives, these trade-offs are not justified. --- # Future Evaluation The networking architecture must remain flexible. Future testing may evaluate: * 45 Hz * 60 Hz However, any increase requires evidence that: * Player experience improves measurably. * Server costs remain acceptable. * Mobile battery impact is within targets. No tick-rate increase will be made based on preference alone. --- # Lag Compensation Because the server runs at 30 Hz: * Client-side prediction is required. * Server reconciliation is mandatory. * Historical state buffering is required for hit validation. This ensures responsive gameplay despite a lower simulation rate. --- # Documentation Rule The following value is now the **single source of truth**: | Parameter | Value | | ---------------------- | --------: | | Server Simulation Rate | **30 Hz** | Any document referencing another tick rate is considered invalid and must be updated. --- # Future Review Gate Server tick rate may only be reconsidered after: * Vertical Slice completion. * Performance profiling. * Closed Alpha testing. * Real-world latency measurements. * Server cost analysis. Until then, **30 Hz remains permanently locked** for Version 1.0. --- ## One additional recommendation I would go one step further and create a **Core Constants** document (`00_ASTRA_Core_Constants.md`). Every project eventually accumulates values that appear in dozens of documents. Instead of repeating them, define them once: | Constant | Value | | ------------------ | -----: | | Players per Match | 24 | | Server Tick Rate | 30 Hz | | Match Duration | 10 min | | Map Size | ~1 km² | | Heroes at Launch | 5 | | Weapon Families | 10 | | Major POIs | 10 | | Rune Slots | 3 | | Weapon Relic Slots | 4 | | Barrier Slots | 1 | Then every other document references this file instead of duplicating numbers. This eliminates contradictions like the 30 Hz vs. 60 Hz issue and gives the entire project a true **single source of truth** for all core design constants.

I actually think this is the **best review Claude has given so far**. This isn't about game design anymore—it's about **production management**. And Claude is absolutely right. Right now we have: * ✅ Great ideas * ✅ Locked decisions * ❌ They only exist as chat responses A real game studio cannot build from chat history. It builds from **version-controlled design documents**. --- # I completely agree with the recommendation. In fact, I'd improve it. Instead of just writing the missing four documents, I'd reorganize the **entire Phase 0** into a proper documentation structure. --- # Phase 0 Documentation (Version 1.0) ## 00 - Core ```text 00_ASTRA_Vision.md 00_ASTRA_Core_Constants.md 00_ASTRA_Hard_Rules.md ``` These never change often. Everything references these. --- # 01 - Game Design ```text 01_Game_Design_Document.md 02_Combat_Balance_Bible.md 03_Hero_Design_Bible.md 04_Weapon_Design_Bible.md 05_Barrier_System.md 06_Loot_Economy.md 07_Progression_and_Seasons.md ``` These define gameplay. --- # 02 - Art ```text 08_Art_Direction_Bible.md 09_UI_UX_Bible.md 10_Animation_Bible.md 11_Audio_Bible.md ``` Every artist follows these. --- # 03 - World ```text 12_World_Bible.md 13_Map_Design_Bible.md 14_POI_Design_Bible.md ``` Everything related to Astra's world. --- # 04 - Technical ```text 15_Technical_Architecture.md 16_Network_Architecture.md 17_Performance_Budget.md 18_Backend_Architecture.md 19_Database_Architecture.md 20_AntiCheat.md ``` Everything engineering. --- # 05 - Production ```text 21_Asset_Taxonomy.md 22_Production_Bible.md 23_ProjectOS.md 24_Risk_Register.md ``` Everything production. --- # Why this is better Right now Combat numbers exist inside AR-017. That's wrong. Instead AR-017 should simply say ```text See 02_Combat_Balance_Bible.md ``` --- Same for Heroes ↓ Hero Bible. --- Weapons ↓ Weapon Bible. --- Performance ↓ Performance Budget. --- Map ↓ World Bible. --- Now every document has ONE owner. --- # Combat Balance Bible Claude is right. AR-017 already contains 90% of it. We simply promote it. --- # Art Direction Bible This doesn't exist. Needs * Visual philosophy * Color palette * Material rules * Shader rules * Lighting * Architecture * Character style * VFX style Every concept artist uses this. --- # UI Bible Also missing. Contains * HUD * Menus * Typography * Icons * Navigation * Color hierarchy * Touch targets * Safe areas --- # Asset Taxonomy Probably the most important production document. Example ```text Characters CHR- Weapons WPN- Barrier BAR- UI UI- Animation ANM- Audio AUD- Map MAP- Props PRP- FX VFX- ``` Every asset gets one ID. Forever. --- # Core Constants This is something I suggested yesterday. Should contain ONLY numbers. Nothing else. Example ```text Players 24 Tick Rate 30Hz Match 10 Minutes POIs 10 Heroes 5 Weapons 10 Barrier Slots 1 Relic Slots 4 Rune Slots 3 ``` Every document references this. Nobody copies numbers. --- # Gate 1 Claude is absolutely correct. Right now Gate 1 cannot be passed. Because the documentation isn't complete. --- I would rewrite Gate 1 as ```text Gate 1 Design Freeze Requirements ✓ Vision ✓ Hard Rules ✓ Core Constants ✓ GDD ✓ Combat Bible ✓ Hero Bible ✓ Weapon Bible ✓ World Bible ✓ Art Bible ✓ UI Bible ✓ Technical Architecture ✓ Backend ✓ Performance Budget ✓ Production Bible ✓ Asset Taxonomy ✓ Risk Register ✓ Approved ↓ Vertical Slice Begins ``` Nothing enters production before this gate is signed off. --- # I would add one more document I think we're still missing the most important one. ## 25_Gameplay_Feel_Bible.md This isn't about mechanics. It's about feel. Example Movement should feel * Responsive * Lightweight * Predictable Gunfire should feel * Powerful * Readable * Satisfying Reloads * Fast * Intentional Hit Effects * Immediate * Clear Audio * Directional * Recognizable This is the document that answers > "Does Astra *feel* like Astra?" Every AAA studio has an equivalent, even if it's called something else. It keeps animation, VFX, audio, camera, UI feedback, and gameplay working toward the same experience instead of being designed independently. ## My recommendation I would treat **Phase 0 as the foundation of the entire studio**, not just this game. Once these documents exist, they become the blueprint for: * Every AI prompt * Every Tripo AI asset * Every concept artist * Every Unity developer * Every QA tester * Every future contractor At that point, Astra stops being "an idea in chat" and becomes a **production-ready game project** with a professional design system.

I actually agree with Claude. Rename it. "Karma" has religious meaning. Instead Legacy or Legend or Path I actually like Legend Progression Better. Purely cosmetic. Tracks Wins Revives Assists Hero mastery Weapon mastery No combat effects.

This is actually one of the most important business documents in the game. If this isn't answered properly, players will play for 2–3 days and leave. But I also think we need to be careful. One mistake many mobile games make is creating **chores** instead of **reasons to return**. I don't want Astra to become: > Login → Collect reward → Logout That's artificial retention. Instead, players should return because they have unfinished goals. --- # AR-019 — Meta Loop & Seasons (LOCKED) **Status:** APPROVED **Priority:** MEDIUM --- # Meta Philosophy Astra follows the principle: > **Every match should contribute toward long-term identity without giving gameplay advantages.** The player should feel that every match matters. Progression is permanent. Power is not. --- # Core Meta Loop Every match contributes to multiple progression systems simultaneously. ```text Play Match │ ▼ Earn XP │ ▼ Hero Mastery │ ▼ Weapon Mastery │ ▼ Legend Progression │ ▼ Season Journey │ ▼ Unlock Cosmetics │ ▼ Play Again ``` No system grants combat advantages. Every reward is cosmetic, prestige, or collection based. --- # Daily Loop Target session: 20–40 minutes. Players should naturally play 2–4 matches. Daily reasons to return: * Daily Challenge * Hero Challenge * Weapon Challenge * Daily Store Rotation No mandatory login rewards. Playing is always more valuable than simply opening the app. --- # Weekly Loop Every week introduces: * Weekly Missions * Featured Hero * Featured Weapon * Double Mastery Event (optional) * Community Goal Weekly rewards include: * Cosmetics * Banners * Titles * Profile Frames Never gameplay items. --- # Long-Term Progression Every player progresses through five independent systems. --- ## 1. Player Level Purpose Overall experience. Unlocks * Profile icons * Titles * Nameplates * Cosmetic rewards Never increases combat strength. --- ## 2. Hero Mastery Each hero has Mastery Levels. Example Hanuman Disciple ↓ Warrior ↓ Guardian ↓ Champion ↓ Avatar Rewards * Character cosmetics * Animations * Voice lines * Hero banners No gameplay buffs. --- ## 3. Weapon Mastery Every weapon tracks * Eliminations * Accuracy * Wins * Usage Unlocks * Weapon skins * Kill counters * Weapon titles * Visual evolution effects No damage increase. --- ## 4. Legend Progression (Previously called Karma.) Tracks the player's overall journey. Includes * Wins * Revives * Assists * Distance traveled * Hero usage * Weapon diversity Rewards * Prestige titles * Lobby profile upgrades * Loading card cosmetics Legend Progression never affects gameplay. --- ## 5. Season Journey This is Astra's seasonal progression. Every match grants Journey XP. Journey unlocks * Character cosmetics * Weapon skins * Barrier skins * Loading screens * Music * Emotes * Player banners No gameplay rewards. --- # Seasonal Model Each season lasts Approximately 10 weeks. Every season has * New cosmetic theme * New featured hero * New cosmetic collections * New map event * New Journey rewards Core gameplay remains stable. --- # Season Themes Instead of random themes, Astra uses mythology-inspired eras. Examples: Season 1 Age of Creation --- Season 2 Wrath of Rudra --- Season 3 Ocean Churning --- Season 4 Mahabharata --- Season 5 Ramayana --- Season 6 Age of Guardians Each season updates: * Main menu visuals * Music * Cosmetic collections * Seasonal events * Featured Hero * Featured Weapon skins The map receives only minor visual changes unless a major update is planned. --- # Challenges Challenges exist to encourage players to explore different playstyles. Categories: Daily Weekly Seasonal Hero Weapon Event Examples: * Win one Duo match. * Eliminate five opponents using Garuda Wing. * Deploy barriers ten times. * Heal teammates for 500 HP. * Reach the final circle three times. Rewards are cosmetic progression only. --- # Collection System Players gradually complete cosmetic collections. Collections include: * Hero Sets * Weapon Sets * Barrier Sets * Banner Sets * Profile Frames Completing an entire set grants an exclusive cosmetic badge or animation. No gameplay bonuses. --- # Return Incentives Players should return because they are working toward meaningful goals. Examples: * Complete Hero Mastery. * Finish Season Journey. * Unlock a cosmetic collection. * Improve ranked statistics (future). * Participate in limited-time events. Astra does **not** rely on daily login rewards as its primary retention mechanic. --- # Live Events Occasional events provide variety without affecting competitive balance. Examples: Festival Event Temple Anniversary Community Milestone Season Finale Rewards remain cosmetic. --- # Social Retention (Phase 2) Future systems include: * Ashrams * Friend Challenges * Community Events * Duo Missions * Seasonal Competitions These increase retention through social interaction rather than gameplay power. --- # Hard Rules for Retention The following rules govern all future progression systems: * Progression must never provide combat advantages. * Every match must contribute toward at least one permanent progression goal. * Players should have multiple parallel goals rather than one long grind. * Missing a day must never permanently disadvantage a player. * Seasonal rewards should encourage participation, not punish absence. * Cosmetic prestige is the primary long-term motivation. --- # Success Metrics The meta system is considered successful if it achieves: * Average daily play session: **20–40 minutes** * Average matches per session: **2–4** * High return rate driven by mastery and seasonal progression * Cosmetic engagement without pay-to-win perception * Sustainable content cadence with one major season every 10 weeks --- # 🔒 Final Meta Philosophy Astra is designed around the principle: > **Players return because they are building their legacy, not because they are afraid of missing power.** The game rewards: * Mastery * Identity * Collection * Achievement * Community It never rewards spending money or excessive grinding with competitive advantages. This philosophy ensures that retention is driven by **long-term player investment in their personal journey**, while maintaining a fair and competitive multiplayer experience for every match.

Again, I think Claude is **100% correct**. This is a classic production inconsistency. We have two documents saying: **AR-015 (Gameplay):** > Five Barrier Families **AR-018 (Production):** > Ten Barrier Types Both cannot be true. Since **gameplay design always takes priority over production estimates**, AR-018 must be corrected. I would actually go one step further. --- # AR-024 — Barrier System Asset Structure (LOCKED) **Status:** APPROVED **Priority:** MEDIUM --- # Final Decision Astra launches with **5 Core Barrier Families**. There will **not** be 10 gameplay barrier types. Future content expands through **cosmetic variants**, not new gameplay mechanics. --- # Barrier Philosophy The Barrier System is a tactical tool, not a collectible system. Every barrier should be instantly recognizable. Every barrier should have: * A unique silhouette * A unique tactical purpose * Clear strengths * Clear weaknesses Five is the ideal number. Beyond that, players begin to memorize exceptions rather than strategies. --- # Launch Barrier Families ## 1. Shila-Stambh **Role:** Standard Cover * Flat stone wall * General-purpose barrier * Balanced durability * Best for rotations and healing --- ## 2. Vajra Dome **Role:** Defensive Cover * Circular energy dome * Excellent for Duo revives * Protects from multiple directions * Small footprint --- ## 3. Vana Barrier **Role:** Natural Cover * Sacred roots and vegetation * Irregular shape * Strong in jungle environments * Excellent for ambushes --- ## 4. Varuna Wall **Role:** Vision Control * Flowing sacred water * Distorts visibility * Used for crossing open terrain * Supports tactical repositioning --- ## 5. Rudra Pillars **Role:** Aggressive Cover * Three stone pillars * Encourages peek-and-shoot gameplay * High skill ceiling * Favours experienced players --- # Gameplay Rule Only these five barrier mechanics exist. Future updates will **not** introduce: * Fire barriers * Ice barriers * Electric barriers * Poison barriers * Damage-dealing barriers Those would increase balancing complexity and reduce readability. --- # Cosmetic Expansion Instead of creating new mechanics, Astra expands visually. Example ## Shila-Stambh Variants * Ancient Granite * Temple Marble * Black Basalt * Lotus Stone * Golden Shrine * Crystal Temple * Forgotten Ruins * Sacred Sandstone Gameplay Exactly identical. --- ## Vajra Dome Variants * Lightning Dome * Celestial Dome * Solar Dome * Moon Dome Same gameplay. Different appearance. --- ## Vana Barrier Variants * Banyan Roots * Sacred Bamboo * Lotus Vines * Ancient Jungle Same gameplay. --- ## Varuna Wall Variants * River Spirit * Ocean Wave * Crystal Water * Monsoon Veil Same gameplay. --- ## Rudra Pillars Variants * Temple Columns * Obsidian Pillars * Golden Pillars * Rune Stones Same gameplay. --- # Production Impact Production planning changes from: ❌ 10 gameplay barriers To: ✅ 5 gameplay systems * Unlimited cosmetic variants This significantly reduces: * Animation work * Programming complexity * QA effort * Network testing * Balance testing * Bug surface area --- # Asset Taxonomy Barrier assets are structured as follows: ```text Barrier Family │ ├── Gameplay Blueprint (1) │ ├── Animation Set (Shared) │ ├── Collision Profile (Shared) │ ├── VFX Profile (Shared) │ └── Cosmetic Variants ├── Material ├── Mesh Details ├── Audio Variant └── Visual Effects ``` One gameplay blueprint. Many visual appearances. --- # Revised Production Estimate Replace ```text Barrier Types 10 ``` With ```text Barrier Families 5 Cosmetic Variants Unlimited ``` Production estimates become: | Asset | Count | | ------------------------- | ----: | | Gameplay Barrier Families | 5 | | Shared Animation Set | 1 | | Shared Placement System | 1 | | Shared Damage System | 1 | | Shared Networking System | 1 | | Launch Cosmetic Variants | 10–15 | --- # Future LiveOps Every season can introduce: * New barrier skins * New material themes * Seasonal visual effects * Limited-time cosmetics Without changing gameplay balance. This keeps LiveOps sustainable while preserving competitive integrity. --- # Hard Rules Preserved This decision reinforces: * **Hard Rule #001** — Simplicity over unnecessary complexity. * **Hard Rule #003** — Strong silhouette readability. * **Hard Rule #005** — Fair competitive gameplay. * **Hard Rule #011** — Tactical tools support gunplay instead of replacing it. --- # 🔒 Final Decision Astra Version 1.0 launches with: * **5 Gameplay Barrier Families** * **1 Shared Barrier Framework** * **Unlimited Cosmetic Variants** No additional gameplay barrier types will be introduced unless they create a genuinely new tactical role that cannot be achieved by the existing five families. --- ## One recommendation I'd add I would add one production rule to the Asset Taxonomy: > **A cosmetic variant may change only visuals, audio, and non-gameplay effects. It must never change collision, dimensions, hitbox, deployment speed, health, lifetime, or gameplay behavior.** This guarantees that when a player sees a premium or seasonal barrier skin, they can rely on it behaving exactly like its base family. That consistency is essential for competitive fairness and keeps the game readable even as the cosmetic catalogue grows.

I actually think this is **one of the best ideas we've had**, and I would go further than Claude. The Relic Codex shouldn't just be a gallery. It should become Astra's equivalent of a **Pokédex + Weapon Encyclopedia + Achievement System**. It creates long-term engagement **without touching competitive balance**, which fits our philosophy perfectly. So my answer is: > **✅ Adopt it. Expand it. Lock it.** --- # AR-025 — Relic Codex System (LOCKED) **Status:** APPROVED **Priority:** LOW (Gameplay Impact) / **HIGH (Retention & Collection)** --- # Philosophy The Relic Codex is **Astra's permanent knowledge archive**. Players never keep Relics after a match. Instead, they keep **their knowledge** of them. This creates permanent progression without permanent power. --- # Core Principle > **Power disappears. Knowledge remains.** When a match ends: * Relics disappear. * Runes disappear. * Weapons disappear. The Codex remains. --- # Purpose The Codex serves four purposes: 1. Collection 2. Lore 3. Learning 4. Mastery It never changes gameplay balance. --- # Discovery System Every Weapon Relic starts as: ```text ??????? Unknown Relic ``` When found for the first time: ```text Discovered Solar Crystal ``` The Codex permanently unlocks its page. --- # Codex Categories The Codex contains: ## Weapon Relics Every Relic in the game. --- ## Runes Every Rune. --- ## Catalysts Every Catalyst. --- ## Avatar States Every Avatar awakening. --- ## Ancient Relics (Lore) World collectibles. Not gameplay items. --- # Every Relic Page Contains ## Artwork High-quality concept render. --- ## Name Example Solar Crystal --- ## Description Example > A fragment of condensed solar Prana recovered from forgotten temples. --- ## Gameplay Effect Example Improves weapon stability. --- ## Compatible Weapons Icons * Surya Stambh * Garuda Wing etc. --- ## Discovery Count Example Found 127 times --- ## Match Usage Example Equipped 95 matches --- ## Win Rate Example Win Rate 18% This is personal data. Not global statistics. --- ## Kills Example Kills while equipped 426 --- ## Damage Total Damage 32,500 --- ## Lore Every Relic contains mythology. Example Who forged it? Why it exists? Where it came from? --- ## Visual Evolution Gallery Concept ↓ 3D Model ↓ Avatar Appearance --- # Rarity Progress Every Relic has Collection Status ```text Found ✓ Mastered ✓ Completed ✗ ``` Completion has no gameplay reward. --- # Research Progress Players unlock: Common ↓ Rare ↓ Epic ↓ Legendary Knowledge pages. The deeper they explore, the richer the lore becomes. --- # Codex Completion Completing collections rewards: * Profile Frames * Titles * Loading Screens * Music * Backgrounds * Lobby Decorations Never combat bonuses. --- # Search System Players can filter by: * Weapon Family * Relic Type * Rarity * Element * Hero Affinity * Discovery Status Making the Codex useful, not just decorative. --- # ProjectOS Integration ProjectOS automatically tracks: * Discovery % * Completion % * Missing Relics * Most Used Relics * Least Used Relics * Balance Statistics This helps designers identify: * Ignored Relics * Overpowered Relics * Underused builds The Codex becomes a LiveOps balancing tool. --- # Seasonal Expansion Every season adds: * New Weapon Relics * New Rune entries * New Lore pages * New Collections Old entries remain. The Codex grows over time. --- # Collection Progress Example ```text Weapon Relics 58 / 60 Runes 20 / 20 Catalysts 9 / 10 Avatar States 10 / 10 Overall 97% ``` A satisfying long-term goal. --- # Completion Rewards 100% completion grants: * "Archivist of Astra" title * Animated profile frame * Codex completion banner * Lobby monument No gameplay advantage. --- # UI Layout ```text RELIC CODEX ------------------------------------- Weapon Relics Runes Catalysts Lore Collections Statistics ------------------------------------- Selected Relic Artwork Description Stats Lore Gallery Progress ``` Clean and easy to navigate. --- # Technical Storage The database stores only: * Discovery flag * Discovery date * Usage count * Personal statistics * Completion status The actual Relic remains match-only. --- # Hard Rules Preserved The Codex complies with: * ✅ Hard Rule #005 — Identity over Power * ✅ Hard Rule #006 — No competitive advantage * ✅ Hard Rule #007 — Cosmetics-only monetization * ✅ Hard Rule #011 — Gun skill decides matches No gameplay values are unlocked. --- # Future Expansion The same framework can later support: * Hero Codex * Weapon Codex * Creature Codex (if added) * World Lore Codex * Achievement Collections One unified knowledge system. --- # 🔒 Final Decision The **Relic Codex** is adopted as a permanent meta-progression feature. It serves as Astra's living encyclopedia, tracking discoveries, lore, personal statistics, and collection progress while granting only cosmetic and prestige rewards. Players grow their understanding of Astra's world—not their combat power. --- ## One improvement I would add I wouldn't call it **Relic Codex**. I'd call it: # **Akashic Codex** In Indian philosophy, the **Akashic Records** represent the universal repository of knowledge and memory. It perfectly matches Astra's theme: * You don't keep the Relic. * You keep the **memory** of discovering it. * The Codex becomes the player's personal archive of everything they have learned about Astra. It's a stronger thematic fit, gives the system a unique identity, and leaves room to include heroes, weapons, world lore, and collectibles under one unified knowledge archive instead of limiting it to Relics alone.