<role> Actúa como un Senior Creative Technologist, Game Desi...

Prompt

<role> Actúa como un Senior Creative Technologist, Game Designer y Frontend Graphics Engineer especializado en p5.js, simulaciones interactivas, generative art y juegos web de alto rendimiento.Tu trabajo no es producir un demo genérico de p5.js, sino diseñar y construir una experiencia interactiva completa, coherente y técnicamente sólida. Toma decisiones de diseño por iniciativa propia cuando algo no esté especificado, pero mantén siempre la idea central y las restricciones del proyecto. Prioriza: 1. jugabilidad real sobre efectos decorativos; 2. una identidad visual coherente; 3. interacción sensible y satisfactoria; 4. rendimiento real en navegador; 5. compatibilidad entre escritorio y móvil; 6. detalles que hagan que el resultado se sienta como un juego terminado y no como un experimento de código. Antes de implementar, descompón internamente el problema en sistemas independientes y comprueba que las decisiones técnicas sean compatibles entre sí. Después implementa la solución completa y revisa mentalmente los casos extremos importantes antes de finalizar. </role> <project> Create an advanced, polished and genuinely interactive p5.js browser game called:NEBULA RUN The game is an endless sci-fi flight experience in which the player's mouse/finger movement velocity is the central gameplay mechanic. </project> <core_design> The player controls a small futuristic spacecraft travelling through an enormous alien plasma storm. The fundamental interaction is: MOVE SLOWLY → stable flight, lower risk, controlled movement. MOVE NORMALLY → balanced speed and danger. MOVE VERY FAST → rapid acceleration, intense effects, greater score potential. MOVE EXTREMELY FAST → OVERDRIVE, where the environment becomes unstable and dangerous. The important part is that pointer velocity must affect the actual simulation and gameplay. Do NOT create a game where the cursor simply emits particles whenever it moves. Cursor velocity must influence multiple gameplay systems simultaneously. </core_design> <gameplay> Implement a complete endless gameplay loop containing:- spacecraft movement controlled by pointer input; - continuous pointer velocity measurement; - smooth acceleration/deceleration; - procedural endless progression; - survival distance; - score; - combo multiplier; - energy/health; - collectible energy fragments; - hazardous objects; - moving obstacles; - plasma storms; - gravitational anomalies; - near-miss detection; - temporary power-ups; - increasing difficulty; - game-over state; - restart flow; - start/tutorial screen. The risk/reward relationship must be obvious: LOW SPEED: The environment is relatively stable and predictable. HIGH SPEED: The player progresses faster and can gain more score, but hazards become harder to avoid. OVERDRIVE: The spacecraft enters a high-risk state with extreme acceleration, stronger environmental reactions, denser hazards and substantially more intense audiovisual feedback. </gameplay> <velocity_system> Implement a real pointer-velocity system. Do not determine speed using only raw frame-to-frame distance. Use: pointer displacement → elapsed time → instantaneous velocity → smoothing/filtering → normalized gameplay speed The system must handle: - mouse; - touch; - stylus; - pointer acceleration; - rapid changes of direction; - brief stops; - very high movement velocities. Use a stable smoothed velocity value for gameplay rather than noisy raw input. The system should distinguish between pointer SPEED and pointer DIRECTION. Velocity should influence at least: - spacecraft acceleration; - movement/travel speed; - trail length; - particle velocity; - particle density; - hazard spawn rate; - anomaly intensity; - camera motion; - screen distortion; - score multiplier; - OVERDRIVE activation; - audiovisual intensity. </velocity_system> <interaction_examples> These are behavioral examples, not hardcoded numbers: Example A: The player barely moves the pointer. Result: calm spacecraft motion, sparse particles, quiet atmosphere, low hazard intensity. Example B: The player moves the pointer quickly. Result: strong acceleration, longer trails, faster world movement, more intense plasma effects and increased score potential. Example C: The player repeatedly performs very fast movements. Result: OVERDRIVE activates, the storm becomes unstable, visual distortion increases, hazards become more aggressive and the player enters a high-risk/high-reward state. </interaction_examples> <world> Create a procedurally generated endless environment.The environment should stream continuously so the player never reaches an obvious end. Generate multiple biome-like space regions, for example: - CALM PLASMA FIELD - DENSE PARTICLE STORM - GRAVITY ANOMALY - ASTEROID CORRIDOR - ENERGY VEIN - CHAOTIC OVERDRIVE ZONE Transitions must feel continuous rather than like separate levels. Use deterministic/procedural generation where useful so the world feels intentional rather than completely random. </world> <visual_direction> The game should look like a polished experimental indie sci-fi game combined with high-end generative art. Visual identity: - deep-space darkness; - huge volumetric-looking plasma clouds created procedurally; - turquoise/cyan/purple energy phenomena; - layered parallax star fields; - glowing particles; - plasma streams; - energy ribbons; - gravitational distortions; - spacecraft motion trails; - impact particles; - shockwaves; - atmospheric depth; - subtle procedural background motion. The environment must visually communicate SPEED. As velocity increases: - trails become longer; - particle motion becomes more directional; - plasma streams stretch; - the camera responds more strongly; - anomalies become more active; - environmental distortion increases; - brightness and visual intensity increase; - the scene becomes progressively more chaotic. OVERDRIVE should feel like a genuine state transition, not merely a label appearing on the HUD. Avoid the generic “neon particles everywhere” look. Every visual effect should reinforce speed, energy, danger or spatial depth. </visual_direction> <game_feel> Prioritize responsiveness and feedback. Include polished details such as: - easing; - velocity smoothing; - subtle camera inertia; - impact feedback; - near-miss feedback; - energy pickup effects; - dynamic particle reactions; - transition effects; - procedural environmental reactions; - screen shake only when appropriate; - visual/audio confirmation when entering or leaving OVERDRIVE. The game should feel immediately responsive to pointer movement. There should be a strong difference between gentle, normal and extreme pointer movement. </game_feel> <hud> Create a futuristic HUD containing:SPEED ENERGY SCORE COMBO DISTANCE OVERDRIVE The SPEED indicator must update smoothly from the actual measured pointer velocity. The HUD should remain readable without covering the gameplay. Use responsive sizing so it works on both desktop and mobile. </hud> <mobile> Mobile is a first-class platform, not a fallback.Use Pointer Events so the same interaction system can support: - mouse; - touch; - stylus. On mobile: - finger movement velocity must drive the same gameplay system; - prevent accidental page scrolling during gameplay; - support portrait; - support landscape; - make buttons comfortable for touch; - handle device resizing/orientation changes; - adapt rendering resolution for performance; - avoid requiring a physical keyboard or mouse; - preserve the same core gameplay concept. The experience should still feel natural when played with one finger. </mobile> <performance> Target smooth real-time gameplay.Use efficient p5.js rendering and avoid unnecessary allocations inside the main loop. Where appropriate: - reuse particle objects; - use object pooling; - avoid constantly creating/destroying large arrays; - cap expensive effects dynamically; - scale particle counts according to device performance; - adapt pixel density when necessary; - use delta time; - avoid frame-rate-dependent gameplay. The game must remain stable across different refresh rates and FPS levels. </performance> <technical_constraints> Use: - p5.js; - one self-contained HTML file; - no separate JavaScript files; - no separate CSS files; - no build system; - external CDN loading of p5.js is allowed. All game logic, rendering, UI and interaction must live inside the single HTML file. Do not create unnecessary dependencies. </technical_constraints> <architecture> Organize the code internally into clear systems even though everything is contained in one HTML file.At minimum separate conceptually: - initialization; - input/pointer tracking; - velocity calculation; - player; - camera; - particles; - procedural world; - hazards; - collectibles; - power-ups; - collision detection; - scoring; - game state; - OVERDRIVE state; - HUD; - audio; - resize/orientation handling; - rendering. Keep the code readable and maintainable instead of writing one giant undifferentiated loop. </architecture> <game_states> Implement at least: START PLAYING GAME_OVER And support OVERDRIVE as a gameplay state layered on top of PLAYING. The player must be able to restart without reloading the page. </game_states> <audio> If audio is implemented, use browser-safe Web Audio techniques and handle browser autoplay restrictions correctly.Audio intensity should react to gameplay intensity. Calm movement: subtle ambience. High velocity: stronger engine/plasma response. OVERDRIVE: intense but controlled sound design. Audio must never prevent the game from functioning when unavailable. </audio> <polish> Add enough secondary details to make the result feel authored rather than procedurally assembled.Examples: - contextual environmental reactions; - small visual variations; - coherent color progression; - intelligent hazard placement; - subtle background motion; - readable transitions; - satisfying collectible feedback; - visual distinction between different world regions; - meaningful changes during OVERDRIVE. Do not add random effects merely to make the screen busier. </polish> <important_design_rule> The pointer-velocity mechanic is the identity of the entire game. Whenever possible, connect visual, gameplay and audiovisual systems back to player movement velocity. The player should be able to FEEL their movement speed through the simulation. </important_design_rule> <final_quality_bar> Do not produce: - a generic p5.js particle demo; - a static visualization; - a simple cursor-following animation; - a shallow “spaceship with stars” demo; - decorative effects disconnected from gameplay; - a desktop-only prototype with token mobile support. Produce a complete playable mini-game with a coherent mechanic, visual identity, procedural environment, risk/reward system, responsive input and polished presentation. </final_quality_bar> <final_check> Before finishing, verify the implementation conceptually against: - no pointer movement; - very slow pointer movement; - sustained fast movement; - extremely fast movement; - rapid direction changes; - pointer leaving/re-entering the canvas; - touch input; - stylus input; - portrait orientation; - landscape orientation; - browser resizing; - restart after game over; - collision edge cases; - long play sessions; - low FPS; - high particle counts. Make sure no required mechanic exists only visually while being disconnected from the actual game simulation. </final_check> <deliverable> Return the complete working single-file HTML implementation.Do not return pseudocode. Do not omit major systems with comments such as “implement this here”. Do not replace requested systems with simplified placeholders. The result should be immediately runnable in a browser after loading p5.js. </deliverable>

A system prompt was added to support web rendering