AR-025 — Server tick rate — 30 Hz or 60? (LOCKED)

Promoted from Action Required card AR-025. This is the decision of record.

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.