How to Build an Android Game with Google AI Studio and Java: COLOR RUSH

What if you could design a complete mobile game first, then use AI to help turn that design into a real Android game?

In this tutorial, we are going to build exactly that with a project called COLOR RUSH — a 2D endless-runner and arcade platform game designed for Android.

The important part is that we are not starting with random code and hoping the final application looks good. We will first establish the game's complete visual identity using Stitch, then take that design direction into Google AI Studio and build the actual Android project using Java, Android Canvas and native Android technologies.

🎮 What We Are Building

COLOR RUSH is a colorful 2D endless arcade platform game where the player controls a glowing energy ball, jumps between platforms, collects coins, avoids obstacles, uses power-ups and tries to achieve the highest possible score.

The goal is to create something that feels like a real mobile game rather than a simple AI-generated programming demo.

🚀 The Complete COLOR RUSH Workflow

The project is divided into two major stages. First we create the visual identity and screen designs. Then we implement the actual game.

STITCH

Game branding → Color system → Typography → Buttons → Character → Gameplay visual language → Home → Gameplay HUD → Pause → Game Over → Shop → Skins → Challenges → Daily Reward → Profile → Achievements → Settings

GOOGLE AI STUDIO + ANDROID STUDIO

Android project → Java → Canvas rendering → Game loop → Physics → Procedural levels → Collision → UI → Audio → Save system → Ads → Billing architecture → Testing → Release AAB

This approach is much stronger than asking AI to create a random game from scratch because the visual identity is established before implementation.

🎨 Step 1: Design COLOR RUSH in Stitch

Before writing the game code, we need a visual source of truth. This is where Stitch comes in.

Instead of asking Stitch to generate only a Home screen or a few menus, we will ask it to establish the entire COLOR RUSH design system first.

That includes the logo, colors, typography, buttons, character, gameplay elements, HUD, menus, skins, rewards, challenges and the visual states that the final game will need.

Important: Keep the Stitch design as your visual reference. When you later build COLOR RUSH in Google AI Studio and Android Studio, use the Stitch designs to keep the game's screens and gameplay visually consistent.

📋 COMPLETE STITCH PROMPT

Copy the complete prompt below into Stitch.

# COLOR RUSH — COMPLETE MOBILE GAME DESIGN SYSTEM Design the complete visual design system and all major game screens for an original Android arcade game called COLOR RUSH. This is a real commercial-quality mobile game design, not a generic Android UI mockup. The purpose of this design work is to establish the complete visual language that will later be implemented as a native Android Canvas game in Java. Do not design the screens as disconnected UI concepts. Everything must belong to one coherent game universe. --- # 1. GAME CONCEPT COLOR RUSH is a fast, colorful 2D endless-runner / arcade platform game. The player controls a cute glowing energy ball that automatically travels through a dangerous futuristic world. The player: - jumps between platforms - collects coins - avoids obstacles - survives increasingly difficult sections - collects power-ups - unlocks character skins - completes challenges - earns rewards - improves their high score The game should feel: - energetic - colorful - playful - fast - polished - rewarding - slightly futuristic - approachable - premium - highly replayable The visual design should immediately communicate COLOR + SPEED + ENERGY + ARCADE FUN. --- # 2. DESIGN GOAL Create a complete visual design system BEFORE designing individual screens. The system must define: - brand identity - logo treatment - color palette - typography - icon style - button language - cards - panels - navigation - HUD - badges - progress bars - currency displays - rarity system - shadows - glow - gradients - corner radius - spacing - visual hierarchy - interaction states - animation direction - illustration style - background style Then apply the system consistently to every screen. Do not create a different design language for each screen. --- # 3. CORE VISUAL IDENTITY COLOR RUSH should have a recognizable futuristic arcade identity. Primary visual mood: Dark futuristic environments combined with bright energetic colors. Main palette: Background: - Deep Navy - Midnight Blue - Dark Indigo Primary: - Electric Blue - Cyan Secondary: - Vibrant Purple - Violet Accent: - Golden Yellow - Bright Gold Danger: - Hot Red - Crimson Success: - Neon Green Special: - Pink/Magenta - Cosmic Violet Use dark colors for the environment and UI foundations. Use bright colors for gameplay objects, rewards, buttons, highlights and important information. Avoid making the entire interface neon. Neon should be used strategically. --- # 4. VISUAL STYLE The game should resemble a polished modern casual arcade game. Use: - soft gradients - controlled glow - rounded shapes - layered depth - subtle shadows - translucent panels - luminous highlights - clean geometry - playful illustrations - premium typography Avoid: - default Android UI - generic Material Design appearance - plain white application screens - excessive glassmorphism - excessive gradients - overly complicated decoration - realistic photography - generic stock illustrations The result must feel like a game, not a business application. --- # 5. DESIGN TOKENS Create a reusable design-token system. Define visual tokens for: Colors: - background-primary - background-secondary - panel - panel-highlight - electric-blue - cyan - purple - violet - gold - red - green - white - muted-text - disabled Typography: - display - logo - screen-title - section-title - button - body - caption - score - currency - number - badge Typography should feel energetic and modern while remaining highly readable on small Android screens. Use bold, rounded or geometric display typography for major game elements. Use a clean readable font for supporting information. --- # 6. BUTTON SYSTEM Design a complete reusable button system. Create: Primary button: PLAY Secondary buttons: SHOP SKINS CHALLENGES Icon buttons: Settings Back Pause Close Sound Music Destructive/danger: Restart Reward: CLAIM WATCH AD Disabled: Clearly communicate unavailable states. Every button needs visual states: - normal - pressed - disabled - selected - loading if appropriate Buttons should have: - rounded corners - subtle depth - controlled glow - strong typography - clear iconography The PLAY button should be the strongest CTA in the entire game. --- # 7. LOGO / BRANDING Design the COLOR RUSH logo. The logo should be: - bold - energetic - compact - recognizable - suitable for a mobile game icon - readable at small sizes Explore a wordmark using energetic typography. Consider a subtle energy trail or color streak integrated into the lettering. Do not make the logo overly complicated. Also establish: - primary logo - compact logo - monochrome version - splash-screen version - app-icon concept --- # 8. CHARACTER DESIGN Design the main player character. The character is an original glowing energy ball. It should look cute rather than threatening. Visual characteristics: - circular silhouette - bright core - colored outer glow - expressive visual personality - subtle face or visual expression if appropriate - energy particles - small trail The character must be simple enough to later reproduce using Android Canvas/vector-style graphics. Create visual references for: Idle: Floating gently with a soft glow. Running: Energetic movement and trail. Jumping: Stretching upward. Falling: Slight squash/stretch. Landing: Compressed squash state. Hit: Flashing/red warning state. Shield: Energy bubble surrounding the character. Speed Boost: Strong energy trail. --- # 9. GAMEPLAY WORLD STYLE Create the visual language for the gameplay environment. The world is a futuristic colorful arcade universe. Use layered 2D depth. Background: Dark blue/purple atmospheric gradient. Distant layer: Futuristic skyline / abstract structures. Midground: Buildings, energy structures, floating objects. Foreground: Gameplay platforms and hazards. Effects: Particles, subtle light beams, stars, energy trails. Keep gameplay elements highly readable. The player must always be able to distinguish: - safe platforms - hazards - coins - power-ups - background decoration --- # 10. PLATFORM DESIGN Create several platform styles. Normal platform: Electric blue platform with subtle cyan edge lighting. Small platform: Compact version. Long platform: Wide safe platform. Moving platform: Visual indicator showing movement. Bounce platform: Bright energy surface. Breakable platform: Visual cracks / warning details. Platforms should have: - rounded edges - slight depth - subtle shadow - controlled glow Do not make platforms visually noisy. Gameplay readability comes first. --- # 11. OBSTACLE DESIGN Create a consistent hazard language. Spikes: Bright red/orange danger objects. Barrier: Red glowing block. Moving hazard: Mechanical/energy object with clear movement indication. Rotating hazard: Circular spike/energy wheel. Laser barrier: Bright red beam with a clear source. All hazards should immediately communicate: DO NOT TOUCH Danger objects should contrast strongly against platforms. --- # 12. COIN DESIGN Create the COLOR RUSH coin. The coin should be: - golden - luminous - circular - simple - instantly recognizable Create states for: - idle - spinning - collected - collection burst Use a bright gold center and controlled yellow glow. --- # 13. POWER-UP DESIGN Create four visually distinct power-ups. MAGNET: Icon: Magnet attracting small coins. Color language: Purple/cyan. SHIELD: Icon: Energy shield. Color language: Blue/cyan. SPEED BOOST: Icon: Lightning / speed streak. Color language: Orange/yellow. DOUBLE COINS: Icon: Two coins / x2 symbol. Color language: Gold/purple. Each power-up should have: - world pickup appearance - icon - HUD indicator - active-state visual - expiration-state visual --- # 14. HUD DESIGN Design the complete gameplay HUD. Portrait mobile layout. Top-left: ❤️ 3 Top-center: SCORE Top-right: COINS Additional HUD: - active power-up - multiplier - pause button The HUD must remain readable while the player is moving quickly. Do not cover important gameplay areas. Use compact translucent panels where appropriate. --- # 15. HOME SCREEN Design a premium game home screen. Composition: Top: COLOR RUSH logo. Upper corner: Coins Gems Center: Large glowing player character. Background: Animated futuristic environment with layered parallax. Main CTA: PLAY The PLAY button should dominate the screen visually. Secondary navigation: SHOP SKINS CHALLENGES DAILY REWARD PROFILE SETTINGS Also show: BEST SCORE LAST SCORE The home screen should feel alive even when the player does nothing. Include subtle: - floating particles - character animation - background movement - energy effects - light movement --- # 16. GAMEPLAY SCREEN Create the complete gameplay screen. Show: - character - platforms - coins - hazards - background - HUD - power-ups - pause button Design a representative gameplay scene containing: - several platforms - a coin formation - one obstacle - one power-up - character jumping This screen is extremely important. It should demonstrate what the actual game will look like when implemented. --- # 17. PAUSE SCREEN Design: PAUSED Buttons: RESUME RESTART HOME The pause panel should appear above the frozen gameplay scene. Use a subtle dark translucent overlay. Do not completely hide the game world. --- # 18. GAME OVER SCREEN Design: GAME OVER Display: SCORE BEST COINS DISTANCE If applicable: NEW BEST! Actions: RETRY WATCH AD — CONTINUE HOME The NEW BEST state should have a celebratory visual treatment. Use: - gold - particles - glow - celebratory badge --- # 19. SHOP SCREEN Create a premium game shop. Top: SHOP Currency: Coins Gems Categories: COINS GEMS SKINS SPECIAL REMOVE ADS Create reusable product cards. Each card should contain: - icon/illustration - product name - price - CTA - optional badge Do not make the shop resemble an e-commerce website. It should feel like a mobile game shop. --- # 20. SKINS SCREEN Create the character skin collection. Grid/list of skins. At least 12 visual concepts: 1. Classic 2. Fire 3. Ice 4. Galaxy 5. Neon 6. Cyber 7. Crystal 8. Shadow 9. Golden 10. Rainbow 11. Cosmic 12. Electric Each skin card should show: - character preview - name - rarity - price - locked/unlocked state - selected state Rarity colors: COMMON RARE EPIC LEGENDARY Make the collection visually exciting. --- # 21. CHALLENGES SCREEN Create a challenge dashboard. Example challenges: COLLECT 100 COINS REACH 500 SCORE REACH 1,000 SCORE SURVIVE 2 MINUTES AVOID 20 OBSTACLES COMPLETE 3 RUNS TRAVEL 5,000 METERS USE 5 POWER-UPS Each challenge card contains: - icon - title - description - progress - target - reward - completion state Use strong progress bars. --- # 22. DAILY REWARD SCREEN Create a seven-day reward calendar. Display: DAY 1 DAY 2 DAY 3 DAY 4 DAY 5 DAY 6 DAY 7 Show: - current day - claimed days - upcoming rewards - locked rewards - special Day 7 reward Main CTA: CLAIM REWARD The Day 7 reward should feel special. Use gold/cosmic visual treatment. --- # 23. PROFILE SCREEN Create a premium player profile. Display: Player level Best score Total runs Total coins Total distance Unlocked skins Achievements Progress Create a strong player identity section at the top. Use statistics cards below. --- # 24. ACHIEVEMENTS SCREEN Create achievement cards. Examples: FIRST RUN COIN COLLECTOR SPEED DEMON SURVIVOR HIGH FLYER RUSH MASTER Each card contains: - icon - title - description - progress - reward - locked/unlocked appearance Unlocked achievements should have a satisfying premium appearance. --- # 25. SETTINGS SCREEN Create: SOUND MUSIC VIBRATION NOTIFICATIONS GRAPHICS QUALITY LANGUAGE PRIVACY POLICY TERMS OF SERVICE RATE US CONTACT Use clean game-style controls. Toggle switches should match the COLOR RUSH design system. Do not use standard Android switches. --- # 26. SCREEN NAVIGATION Design the relationship between all screens. Primary navigation: HOME → GAMEPLAY → PAUSE → GAME OVER HOME → SHOP HOME → SKINS HOME → CHALLENGES HOME → DAILY REWARD HOME → PROFILE HOME → SETTINGS Keep navigation simple. Players should never feel lost. --- # 27. EMPTY / LOCKED / DISABLED STATES Design states for: - locked skin - insufficient coins - unavailable purchase - completed challenge - claimed reward - unavailable ad - disabled setting - empty achievement progress Do not only design the ideal state. Create realistic game states. --- # 28. MICRO-INTERACTIONS Define the intended animation behavior. Buttons: Small scale-down on press. Cards: Subtle elevation/glow on selection. Coins: Pop + sparkle when collected. Reward: Scale + glow + particle burst. NEW BEST: Large celebratory entrance. Skin unlock: Character reveal animation. Daily reward: Reward card expands and celebrates. Screen transitions: Fast and smooth. The animations should feel responsive rather than slow. --- # 29. DESIGN FOR ANDROID Everything must be designed for portrait Android devices. Account for: - small phones - large phones - tall screens - different aspect ratios - safe areas - varying screen densities Do not make important controls depend on exact pixel positions. Use responsive spacing and scalable components. --- # 30. CANVAS IMPLEMENTATION AWARENESS The final implementation will use: Java + Android Canvas Therefore the visual design should be practical to reproduce using: - vector-like shapes - gradients - circles - rounded rectangles - paths - particles - simple sprites - text - scalable UI components Avoid designs that depend on complex 3D rendering. Avoid effects that would be extremely expensive to reproduce on low-end Android devices. The design should look premium while remaining technically achievable. --- # 31. PERFORMANCE-AWARE VISUAL DESIGN COLOR RUSH must eventually run smoothly on lower-end Android phones. Therefore: - avoid excessive particles - avoid huge textures - avoid unnecessary blur - avoid expensive full-screen effects - use controlled glow - use layered 2D backgrounds - use simple geometric gameplay objects Visual quality must come from good composition and hierarchy, not excessive effects. --- # 32. DESIGN SYSTEM DELIVERABLE Before finishing, create a dedicated COLOR RUSH DESIGN SYSTEM reference. It should visually establish: 1. Brand/logo 2. Color palette 3. Typography 4. Buttons 5. Icons 6. Cards 7. Panels 8. Badges 9. Currency 10. Progress bars 11. Toggles 12. Rarity system 13. HUD 14. Character 15. Platforms 16. Coins 17. Obstacles 18. Power-ups 19. Backgrounds 20. Animation direction This design system becomes the visual source of truth for the later Android implementation. --- # 33. COMPLETE SCREEN SET Create polished visual designs for ALL of these: BRANDING: - Logo - App icon - Splash screen CORE GAME: - Gameplay - Gameplay HUD - Pause - Game Over - New Best state MAIN NAVIGATION: - Home PROGRESSION: - Profile - Achievements - Challenges - Daily Reward COLLECTION: - Skins - Skin detail/unlock state ECONOMY: - Shop - Coin package - Gem package - Remove Ads state SETTINGS: - Settings - Sound/Music states - Graphics states SYSTEM STATES: - Locked - Disabled - Completed - Claimed - Insufficient currency - Reward unavailable --- # 34. FINAL DESIGN QUALITY BAR The final design should look like it could belong to a real commercial mobile arcade game. Ask yourself: Does COLOR RUSH have a recognizable identity? Does the Home screen immediately communicate the game? Does the gameplay screen look exciting? Can players instantly distinguish platforms from hazards? Is the PLAY button obvious? Are rewards visually satisfying? Do skins feel collectible? Do challenges feel motivating? Does the UI feel consistent? Does the character feel like the game's mascot? Can the design realistically be implemented in Android Canvas? Would the design still look good on a small phone? If something looks generic, redesign it. --- # FINAL INSTRUCTION Do not only create attractive individual screens. First establish the COLOR RUSH visual design system, then apply that system consistently across the complete game. The final result should give a developer everything necessary to implement the game in Google AI Studio while preserving the exact visual identity. COLOR RUSH should feel like one complete, polished game — not a collection of unrelated screens.

💻 Step 2: Build the Actual Game with Google AI Studio

Once the Stitch design is ready, the next step is to build the actual Android game.

The important distinction is that the visual design comes from Stitch, while the implementation is built using Java, Android SDK, Android Canvas and native Android components.

For the coding stage, use the following master prompt in Google AI Studio.

Tip: Give Google AI Studio the Stitch screenshots/design reference when possible. Tell it that the Stitch design is the visual source of truth and that the implementation must preserve the same colors, typography, button shapes, spacing, character style and screen hierarchy.

📋 COMPLETE GOOGLE AI STUDIO MASTER PROMPT

# BUILD A COMPLETE PRODUCTION-QUALITY ANDROID GAME — COLOR RUSH You are an expert Android game developer, Java engineer, 2D game-engine developer, UI/UX designer, mobile performance engineer, and Google Play release engineer. Your task is to BUILD A COMPLETE, REAL, PLAYABLE Android game called: COLOR RUSH COLOR RUSH is a polished 2D endless-runner / arcade platform game designed specifically for Android. This is NOT a prototype. This is NOT a UI mockup. This is NOT a WebView game. This is NOT an HTML game wrapped inside Android. Build a REAL native Android game with working gameplay, physics, collision detection, procedural level generation, menus, progression, persistence, audio, effects, skins, challenges, rewards, and monetization architecture. The final result should look and feel like a real commercial casual game that could be polished and published on Google Play. IMPORTANT VISUAL REQUIREMENT: A complete COLOR RUSH visual design system has already been established in Stitch. Use the Stitch design as the visual source of truth. Preserve its: - colors - typography - buttons - panels - icons - character design - gameplay visual language - HUD - screen layouts - spacing - glow effects - rarity system - visual hierarchy Do not replace the Stitch design with a generic Android interface. --- # 1. CORE TECHNOLOGY Build a native Android Studio project. Use: - Java - Android SDK - Gradle - Native Android Views - Android Canvas - SurfaceView or custom View for gameplay - SharedPreferences for local persistence - MediaPlayer / SoundPool or appropriate native Android audio APIs - Google Mobile Ads SDK architecture - Google Play Billing architecture only where actually configured Do NOT use: - Kotlin - Jetpack Compose - WebView - HTML - CSS - JavaScript game engines - React - Flutter - Unity - Godot - libGDX The core game must be rendered using Android Canvas. --- # 2. ANDROID REQUIREMENTS Application name: COLOR RUSH Application ID: com.colorrush.game Minimum SDK: 24 Target SDK: Use the latest stable Android SDK available in the development environment. Language: Java Orientation: PORTRAIT The game must support: - small Android phones - large Android phones - different aspect ratios - different screen densities - modern Android devices - lower-end Android devices The game must maintain a consistent visual hierarchy regardless of screen size. Do not design the gameplay around a single fixed resolution. --- # 3. IMPORTANT DEVELOPMENT PRINCIPLE Do NOT generate everything as one giant Java file. Use a professional modular architecture. Recommended structure: app/ └── src/ └── main/ ├── java/com/colorrush/game/ │ ├── MainActivity.java │ ├── game/ │ │ ├── GameView.java │ │ ├── GameLoop.java │ │ ├── GameManager.java │ │ ├── GameState.java │ │ ├── Camera.java │ │ ├── LevelGenerator.java │ │ ├── CollisionManager.java │ │ ├── DifficultyManager.java │ │ └── ObjectPool.java │ ├── entities/ │ │ ├── Player.java │ │ ├── Platform.java │ │ ├── Obstacle.java │ │ ├── Coin.java │ │ ├── PowerUp.java │ │ └── Particle.java │ ├── player/ │ │ ├── PlayerController.java │ │ ├── PlayerPhysics.java │ │ └── PlayerSkin.java │ ├── progression/ │ │ ├── SaveManager.java │ │ ├── ChallengeManager.java │ │ ├── DailyRewardManager.java │ │ ├── AchievementManager.java │ │ └── ProgressManager.java │ ├── audio/ │ │ └── SoundManager.java │ ├── ads/ │ │ └── AdManager.java │ ├── shop/ │ │ ├── ShopManager.java │ │ └── BillingManager.java │ ├── screens/ │ │ ├── ScreenManager.java │ │ ├── HomeScreen.java │ │ ├── GameplayScreen.java │ │ ├── PauseScreen.java │ │ ├── GameOverScreen.java │ │ ├── ShopScreen.java │ │ ├── SkinsScreen.java │ │ ├── ChallengesScreen.java │ │ ├── DailyRewardScreen.java │ │ ├── SettingsScreen.java │ │ └── ProfileScreen.java │ └── ui/ │ ├── GameButton.java │ ├── AnimatedButton.java │ ├── ProgressBar.java │ ├── CoinDisplay.java │ └── ToastMessage.java └── res/ ├── drawable/ ├── mipmap/ ├── values/ ├── xml/ └── raw/ You may improve this architecture if there is a better professional structure. --- # 4. GAME IDENTITY The game is called: COLOR RUSH Core concept: A cute glowing character races through a dangerous colorful world while collecting coins, avoiding obstacles, landing on platforms, and surviving as long as possible. The game should communicate: - speed - energy - color - progression - excitement - skill - replayability The player should immediately understand the game within a few seconds. --- # 5. VISUAL ART DIRECTION This is extremely important. Use the Stitch design system as the visual reference. Do NOT create a generic Android application interface. Do NOT use default Android buttons. Do NOT make the game look like a programming tutorial. The visual quality should resemble a polished commercial casual mobile game. Visual direction: - dark blue backgrounds - purple atmospheric gradients - electric blue platforms - cyan highlights - bright yellow/gold coins - orange highlights - red danger objects - glowing effects - soft shadows - depth - smooth gradients - rounded panels - dynamic lighting - particle effects - subtle screen effects - polished typography The interface should have a strong visual identity. Use the COLOR RUSH design system established in Stitch. --- # 6. GAME CHARACTER Create the original playable COLOR RUSH character based on the Stitch design. The default character should be a glowing colorful ball. The character should have: - animated glow - squash and stretch - bounce animation - rotation - shadow - particle trail - landing effect - jump effect - hit effect The character should feel alive. Idle animation: - subtle floating motion - small glow pulse - tiny particle movement Running animation: - rotation - bounce - trail Jump animation: - squash - stretch - rotation - particles Landing: - squash - impact particles - small camera shake Do not copy characters from existing games. --- # 7. GAMEPLAY The game is a 2D endless arcade platform runner. The player continuously progresses through the world. The game should include: - platforms - coins - spikes - moving obstacles - rotating obstacles - gaps - environmental hazards - increasing speed - increasing difficulty - power-ups - score progression The world must be generated procedurally. The game should never require thousands of manually created levels. --- # 8. GAMEPLAY CAMERA Implement a smooth camera system. The camera should: - follow the player - smoothly interpolate movement - avoid excessive shaking - provide slight movement feedback - support camera shake during impacts - maintain a comfortable view of upcoming obstacles Do not make the camera movement nauseating. --- # 9. PLAYER CONTROL Controls must feel excellent on touchscreen devices. Primary control: TAP = JUMP Optional: - swipe left/right - touch left/right zones - horizontal movement where necessary The primary gameplay should remain easy to understand. Jump physics must be forgiving. Avoid impossible jumps. Avoid requiring pixel-perfect timing. The player should feel: - responsive - predictable - smooth - fair Implement: - jump velocity - gravity - maximum fall speed - landing detection - coyote time if useful - jump buffering if useful Use delta-time based physics. --- # 10. PLATFORM SYSTEM Platforms should be procedurally generated. Platform properties: - x position - y position - width - height - movement type - visual style Platform types: 1. Normal platform 2. Small platform 3. Long platform 4. Moving platform 5. Breakable platform 6. Bounce platform 7. Special platform Platforms should have: - rounded edges - shadows - glow - subtle animation Most importantly: THE LEVEL GENERATOR MUST NEVER CREATE AN IMPOSSIBLE SEQUENCE. Every generated section must remain theoretically playable. --- # 11. OBSTACLES Create multiple obstacle classes. Initial obstacles: - spikes - spike groups - red barriers - moving blocks Advanced obstacles: - rotating spike wheels - moving laser-style barriers - vertical obstacles - timed hazards Introduce obstacles gradually. Do not overwhelm new players. Difficulty should increase naturally. --- # 12. COINS Create collectible golden coins. Coins must: - rotate - glow - animate - disappear when collected - produce particles - play a collection sound - increase player currency Generate different coin formations: - straight lines - curves - arcs - stairs - risk/reward patterns Some coins should encourage the player to take a risky route. --- # 13. POWER-UPS Implement real power-ups. Power-ups: MAGNET Automatically attracts nearby coins. SHIELD Protects the player from one collision. SPEED BOOST Temporarily increases movement speed and score multiplier. DOUBLE COINS Doubles coins collected for a limited duration. Each power-up needs: - visual icon - world pickup object - activation effect - timer - HUD indicator - expiration effect - sound - particle effect Power-ups must actually work. --- # 14. SCORING Score should primarily depend on distance survived. Additional score bonuses: - coins - consecutive landings - power-up usage - challenge completion - distance milestones Display: SCORE BEST COINS When a new high score is achieved: NEW BEST! Trigger: - animation - particles - sound - subtle screen effect Save the high score immediately. --- # 15. DIFFICULTY SYSTEM Create a dedicated DifficultyManager. Difficulty should progressively increase. Increase: - game speed - platform spacing - obstacle frequency - moving obstacle speed - obstacle combinations - risk/reward patterns Internal difficulty stages: Stage 1 — Beginner Stage 2 — Runner Stage 3 — Fast Stage 4 — Expert Stage 5 — Extreme Stage 6 — Master Difficulty should be smooth. Never suddenly make the game impossible. --- # 16. LIVES Default: 3 lives. HUD: ❤️ 3 When hit: - player flashes - collision effect - vibration - sound - camera shake - life decreases If lives remain: Respawn safely. If lives reach zero: Show Game Over. --- # 17. GAME OVER Create a professional game-over screen. Display: GAME OVER SCORE BEST SCORE COINS DISTANCE Buttons: RETRY WATCH AD — CONTINUE HOME If a new best score was achieved: NEW BEST! The game-over screen should animate into view. --- # 18. CONTINUE SYSTEM Allow one rewarded-ad continuation per run. After death: WATCH AD — CONTINUE If rewarded ad succeeds: - restore player - restore 1 life - return to gameplay - continue from a safe position - prevent another continue during the same run If advertisement fails: show a friendly message and allow the player to retry. Never crash if an ad cannot load. --- # 19. HOME SCREEN Create a premium game home screen using the Stitch design. Layout: Top: COLOR RUSH logo/title Currency: Coins Gems Main CTA: PLAY Secondary navigation: SHOP SKINS CHALLENGES DAILY REWARD PROFILE SETTINGS Also show: BEST SCORE LAST SCORE The character should be visible in the center. Add: - floating animation - background particles - moving background elements - subtle parallax - animated buttons The PLAY button should be the strongest visual element. --- # 20. SHOP Create a professional shop. Categories: COINS GEMS SKINS SPECIAL REMOVE ADS Do not create fake purchases. Do not claim a purchase succeeded when billing is unavailable. Create a proper BillingManager abstraction. If Google Play Billing is not configured: display an appropriate unavailable state. Do not put fake payment functionality into the production version. --- # 21. SKINS Create at least 12 original character skins. Examples: Classic Fire Ice Galaxy Neon Cyber Crystal Shadow Golden Rainbow Cosmic Electric Each skin must contain: - name - rarity - price - preview - unlocked state - selected state Rarity: COMMON RARE EPIC LEGENDARY Use coins to unlock skins. Selected skin must immediately affect the player during gameplay. Save selection. --- # 22. CHALLENGES Create a Challenges system. Examples: Collect 100 coins Reach 500 score Reach 1,000 score Survive 2 minutes Collect 50 coins in one run Avoid 20 obstacles Complete 3 runs Travel 5,000 meters Use 5 power-ups Each challenge needs: - title - description - progress - target - reward - completion state Save progress. Display attractive progress bars. --- # 23. ACHIEVEMENTS Create an achievement system. Examples: FIRST RUN Complete your first run. COIN COLLECTOR Collect 1,000 coins. SPEED DEMON Reach a high speed. SURVIVOR Survive for a specific distance. HIGH FLYER Perform a number of jumps. RUSH MASTER Reach a major score milestone. Achievements should have: - icon - title - description - progress - reward - unlocked state --- # 24. DAILY REWARD Create a 7-day daily reward system. Example: Day 1 — 100 coins Day 2 — 150 coins Day 3 — 200 coins Day 4 — 250 coins Day 5 — 300 coins Day 6 — 400 coins Day 7 — Special reward Requirements: - one claim per day - 7-day cycle - claim animation - reward animation - persistent state Do not allow simple repeated claims by repeatedly changing the device clock. Implement reasonable validation and document the limitation of offline-only time validation. --- # 25. PROFILE Create a player profile screen. Display: Player level Coins Gems Best score Total runs Total coins collected Total distance Achievements Unlocked skins Progress Create a clean premium game profile layout. --- # 26. SETTINGS Create: Sound Music Vibration Notifications Graphics quality Language Privacy Policy Terms of Service Rate Us Contact Settings must persist. Sound and music must actually work. --- # 27. AUDIO Create SoundManager. Support: - button click - jump - landing - coin collection - power-up - obstacle hit - game over - new best - skin unlock - daily reward - challenge completed Support background music. Do not use copyrighted music. Use clearly separated placeholder asset paths for original or properly licensed audio. If an audio file is missing: the game must continue without crashing. --- # 28. PARTICLE SYSTEM Implement a lightweight optimized particle system. Effects: - coin sparkle - jump particles - landing particles - player trail - shield effect - speed boost effect - coin collection burst - death effect - new best celebration Do not create excessive particles. Use object pooling where appropriate. Particles must be automatically recycled. --- # 29. VISUAL EFFECTS Add subtle premium effects: - glow - screen flash - camera shake - speed lines - parallax - floating particles - background movement - button press animations - screen transitions Effects must never make the game difficult to play. --- # 30. ENVIRONMENT THEMES Do not keep the entire game visually identical. Create multiple environment themes. Example: WORLD 1 — NEON CITY Blue/purple city environment. WORLD 2 — SUBWAY Underground station environment. WORLD 3 — NIGHT CITY Dark neon environment. WORLD 4 — SKY BRIDGE High-altitude futuristic environment. WORLD 5 — COSMIC RUSH Stylized futuristic environment. The gameplay system remains the same while visual assets/colors/backgrounds change. Transition between themes gradually based on progression. --- # 31. PARALLAX BACKGROUND Create multiple background layers. Layer 1: sky/gradient Layer 2: distant buildings Layer 3: near buildings Layer 4: environment objects Layer 5: gameplay platforms Each layer should move at a different speed. This creates depth without requiring expensive 3D rendering. --- # 32. UI DESIGN The UI must look like a real mobile game. Avoid: - default Android buttons - plain TextViews - boring rectangular layouts - excessive white screens - generic Material UI Use: - rounded game panels - strong typography - icons - glow - shadows - animated buttons - currency indicators - progress bars - badges - cards - visual feedback Every button should have: - normal state - pressed state - disabled state - subtle animation --- # 33. SCREEN TRANSITIONS Implement smooth transitions. Examples: Home → Gameplay Home → Shop Home → Skins Home → Challenges Gameplay → Pause Gameplay → Game Over Game Over → Retry Game Over → Home Use lightweight animations. Do not freeze the UI. --- # 34. PAUSE Pause must completely freeze: - physics - player movement - obstacle movement - coin movement - timers - particle updates - score progression Show: PAUSED RESUME RESTART HOME When resumed: gameplay continues safely. --- # 35. SAVE SYSTEM Create a dedicated SaveManager. Persist: - coins - gems - best score - last score - selected skin - unlocked skins - challenge progress - achievements - daily reward state - sound setting - music setting - vibration setting - games played - total coins - total distance - player level Use SharedPreferences. Use defensive parsing. If stored data is corrupted or missing: restore safe defaults. Never crash because of saved data. --- # 36. GAME LOOP Create a proper delta-time game loop. Requirements: - stable updates - 60 FPS target - delta time - pause/resume - lifecycle awareness - no unnecessary allocations - object recycling Never perform expensive operations inside every frame. Do not create new Paint objects repeatedly. Reuse: - Paint - RectF - Path - objects - particles - temporary objects where practical. --- # 37. OBJECT POOLING Use pooling for frequently created objects. Pool: - particles - coins - obstacles - platforms - temporary effects Do not continuously create and destroy hundreds of objects. Recycle objects that leave the camera. --- # 38. PROCEDURAL LEVEL GENERATION Create LevelGenerator. The generator must understand: - current difficulty - player speed - jump capability - platform distance - obstacle frequency - coin placement - power-up placement The generator must maintain a safe playable path. Before spawning a new platform: validate that it is reachable. Avoid: - impossible gaps - overlapping obstacles - impossible jumps - unavoidable hazards - unfair patterns Generate ahead of the player. Recycle objects behind the player. --- # 39. ADS Create AdManager. Architecture must support: - Banner - Interstitial - Rewarded Use Google's official test ad IDs during development. Production ad IDs must be stored centrally. Never scatter ad IDs throughout the code. Do not show ads aggressively. Suggested strategy: HOME: Optional banner. SHOP: Optional banner. GAMEPLAY: No banner covering gameplay. GAME OVER: Interstitial occasionally, not after every death. CONTINUE: Rewarded advertisement. The game must remain playable without ads. If ads fail: continue normally. --- # 40. MONETIZATION Monetization must be responsible. Do NOT: - deceive users - hide buttons - create accidental ad clicks - spam advertisements - interrupt gameplay unnecessarily Primary: Rewarded ads Secondary: Occasional interstitial Optional: Remove Ads --- # 41. OFFLINE-FIRST Core gameplay must work offline. Without internet: - gameplay works - coins work - skins work - challenges work - settings work - scores work - saved progress works Only online-dependent services such as advertisements or Play Billing may become unavailable. Never block gameplay because the internet is unavailable. --- # 42. LIFECYCLE Handle: onCreate onStart onResume onPause onStop onDestroy When app goes into background: pause gameplay safely. When returning: resume only when appropriate. Release audio/resources correctly. Avoid memory leaks. --- # 43. ROTATION Lock gameplay to portrait. If the device attempts to rotate: maintain portrait orientation. Do not restart the game unexpectedly. --- # 44. PERFORMANCE Optimize specifically for low-end Android devices. Avoid: - large unnecessary bitmaps - excessive object creation - huge textures - unnecessary threads - unnecessary background work - excessive particles - expensive per-frame calculations Target: 60 FPS where device performance allows. Create a graphics quality system: LOW MEDIUM HIGH On lower settings: - reduce particles - reduce background effects - reduce shadows - reduce visual effects Gameplay must remain identical. --- # 45. ERROR HANDLING The application must gracefully handle: - missing audio - missing optional assets - ad failure - billing unavailable - internet unavailable - corrupted preferences - lifecycle interruption - low memory - activity recreation - unexpected game state The core game must not crash. --- # 46. SPLASH SCREEN Create a professional short splash screen. Show: COLOR RUSH with the glowing ball. Animation: - logo fade - subtle scale - glow pulse Do not create an unnecessarily long splash screen. --- # 47. APP ICON Create an original app icon concept. Icon: A glowing colorful ball with dynamic blue/purple energy around it. Do not put unnecessary text on the icon. Create proper Android adaptive icon resources. --- # 48. GOOGLE PLAY PREPARATION Prepare the project for Google Play. Include: - application ID - version code - version name - adaptive icon - splash screen - release configuration - R8/ProGuard configuration where appropriate - proper manifest - required permissions only The project must be capable of generating: Android App Bundle (.aab) Do not request unnecessary permissions. --- # 49. PRIVACY Do not request permissions that are not needed. If advertising is integrated, structure the project so privacy/consent requirements can be added appropriately. Do not collect personal information unnecessarily. --- # 50. DEVELOPMENT PHASES Build the game in the following order. PHASE 1 Create complete Android Studio project. PHASE 2 Create architecture. PHASE 3 Create GameView. PHASE 4 Create GameLoop. PHASE 5 Create Player. PHASE 6 Create player physics. PHASE 7 Create platforms. PHASE 8 Create collision system. PHASE 9 Create procedural level generator. PHASE 10 Create coins. PHASE 11 Create obstacles. PHASE 12 Create difficulty system. PHASE 13 Create scoring. PHASE 14 Create lives. PHASE 15 Create power-ups. PHASE 16 Create particles. PHASE 17 Create environment/background system. PHASE 18 Create Home screen. PHASE 19 Create Pause screen. PHASE 20 Create Game Over screen. PHASE 21 Create Shop. PHASE 22 Create Skins. PHASE 23 Create Challenges. PHASE 24 Create Achievements. PHASE 25 Create Daily Rewards. PHASE 26 Create Profile. PHASE 27 Create Settings. PHASE 28 Create SaveManager. PHASE 29 Create SoundManager. PHASE 30 Create AdManager. PHASE 31 Create BillingManager architecture. PHASE 32 Optimize performance. PHASE 33 Test navigation. PHASE 34 Test gameplay. PHASE 35 Prepare release build. --- # 51. TESTING REQUIREMENTS Before declaring the project complete, mentally test every important flow. TEST 1 Fresh installation. Expected: Home screen opens. TEST 2 Press PLAY. Expected: Real gameplay starts. TEST 3 Jump. Expected: Player actually jumps. TEST 4 Land. Expected: Player lands on platform. TEST 5 Collect coin. Expected: Coin disappears and balance increases. TEST 6 Hit obstacle. Expected: Life decreases and hit effect occurs. TEST 7 Lose all lives. Expected: Game Over appears. TEST 8 Press RETRY. Expected: New game starts. TEST 9 Press HOME. Expected: Return to Home. TEST 10 Press PAUSE. Expected: Entire game freezes. TEST 11 Resume. Expected: Gameplay continues. TEST 12 Unlock skin. Expected: Coins decrease and skin becomes unlocked. TEST 13 Select skin. Expected: Selected skin is saved. TEST 14 Close application. Expected: Progress remains saved. TEST 15 Reopen application. Expected: Progress remains available. TEST 16 Disable internet. Expected: Core game still works. TEST 17 Advertisement fails. Expected: No crash. TEST 18 Billing unavailable. Expected: No crash. TEST 19 Reach new high score. Expected: NEW BEST animation appears and score saves. TEST 20 Background the application. Expected: Game pauses safely. --- # 52. IMPORTANT: DO NOT CHEAT THE IMPLEMENTATION Do NOT replace gameplay with screenshots. Do NOT make buttons that only look functional. Do NOT create fake score changes. Do NOT simulate collisions visually. Do NOT create fake coins. Do NOT create fake skins. Do NOT create fake save functionality. Do NOT create fake advertisements. Do NOT create fake billing success. Do NOT create fake challenges. Do NOT use placeholder screens where working functionality was requested. If a system cannot be fully connected because an external configuration is required, create a clean production-ready interface and clearly identify the configuration required. --- # 53. ASSET STRATEGY Prefer Canvas/vector/programmatic graphics for: - player - platforms - coins - simple obstacles - particles - UI decorations - icons where practical For complex background art, organize assets properly inside: res/drawable/ Do not use copyrighted game assets. Do not copy Subway Surfers, Geometry Dash, Sonic, Temple Run, or any other existing game. COLOR RUSH must have its own identity. --- # 54. UI AND GAMEPLAY RELATIONSHIP The menus should visually belong to the same game as the gameplay. The same: - colors - typography - icons - button shapes - glow effects - visual language must be used throughout the application. The player should feel that the Home screen and gameplay are part of one professionally designed game. --- # 55. FINAL QUALITY BAR Before considering COLOR RUSH complete, ask: Does this look like a real mobile game? Does the gameplay feel responsive? Are the animations smooth? Does the game have a recognizable visual identity? Does the game become harder naturally? Are the generated levels playable? Do coins actually work? Do obstacles actually work? Do power-ups actually work? Do skins actually work? Does saving actually work? Does retry actually work? Does pause actually work? Does Game Over actually work? Does the game work offline? Does it behave correctly on low-end devices? Can the project generate an Android App Bundle? If the answer to any of these is NO: FIX IT before declaring the project complete. --- # 56. AI STUDIO OUTPUT REQUIREMENTS You are working on a real Android Studio project. Generate complete source files. Whenever you create a file, provide the complete contents of that file. Never give partial snippets such as: // rest of code here Never use: // TODO implement later for core functionality. Never omit required imports. Never reference classes that do not exist. Never reference resources that were not created. Never create XML resources that are missing. Never create Java classes with unresolved dependencies. Make sure package names are consistent throughout the project. Make sure Gradle configuration matches the Android Gradle Plugin and Gradle version being used. Make sure all resources referenced in Java actually exist. Make sure all Java classes compile together. --- # 57. BUILD VALIDATION After generating the project: Perform a consistency review. Check: - package names - imports - class names - method names - resource IDs - drawable references - strings - colors - dimensions - manifest - Gradle - dependencies - Android SDK versions Resolve obvious compilation problems before presenting the project as complete. If a compilation problem is discovered: fix the underlying source rather than hiding the error. --- # 58. DO NOT STOP AFTER THE FIRST PHASE This instruction is critical. Do NOT generate only: MainActivity Home screen or a visual mockup. The objective is the complete COLOR RUSH game. If the implementation is too large for one response, continue in logical stages. For each stage: 1. State the stage. 2. Generate the required complete files. 3. Maintain compatibility with previously generated files. 4. Do not rewrite working systems unnecessarily. 5. Continue until the complete project has been implemented. Never remove functionality simply because the project has become large. --- # 59. FINAL DELIVERABLE The final project must contain: A real Android Studio project. A real playable COLOR RUSH game. Real player movement. Real jumping. Real platform collision. Real procedural generation. Real obstacles. Real coins. Real scoring. Real difficulty progression. Real lives. Real power-ups. Real particles. Real menus. Real pause. Real game over. Real retry. Real home navigation. Real skins. Real challenges. Real achievements. Real daily rewards. Real settings. Real audio architecture. Real save system. Real advertisement architecture. Billing architecture. Performance optimization. Google Play preparation. The finished game should feel like a polished commercial Android arcade game rather than an AI-generated programming demo. # FINAL COMMAND BUILD COLOR RUSH NOW. Start with PHASE 1 and continue through the complete implementation. Do not create a fake prototype. Do not create a static mockup. Build the actual playable Android game.

📋 ORIENTATION AND LANDSCAPE IMPLEMENTATION UPDATE

Copy the complete prompt below.

IMPORTANT ORIENTATION AND LANDSCAPE IMPLEMENTATION UPDATE The COLOR RUSH game must remain a NATIVE ANDROID GAME built with Java, Android SDK, Canvas/SurfaceView, and the existing project architecture. DO NOT convert the project to Expo React Native, React Native, Flutter, Unity, Godot, WebView, HTML/CSS/JavaScript, or any other framework. The existing project has already been converted from portrait to landscape. Now perform a complete verification and refinement pass to ensure the ENTIRE GAME is properly designed and implemented for landscape gameplay. ================================================== 1. TARGET ORIENTATION ================================================== Change/maintain the entire COLOR RUSH game as: 1920 × 1080 16:9 LANDSCAPE Do NOT use: 1080 × 1920 9:16 Portrait The game must behave like a professional landscape mobile/console-style game. Reference the overall presentation style of games such as eFootball Mobile: - Landscape gameplay - Full-screen immersive experience - Gameplay occupying the entire display - HUD overlaid directly on gameplay - No vertical scrolling - No TikTok/Reels/Shorts-style interface - No portrait mobile-app layout - No website/dashboard appearance ================================================== 2. ANDROID ORIENTATION LOCK ================================================== This is a native Android Java application. Ensure the Android application itself is configured for landscape orientation. Use the correct modern Android configuration for the existing project. Verify: - AndroidManifest.xml - MainActivity.java - Activity orientation behavior - Window/insets handling - Full-screen behavior - Game View dimensions - Touch coordinate mapping The game must launch directly in landscape orientation. Do not merely rotate the existing portrait interface. The UI and gameplay must be intentionally laid out for landscape. ================================================== 3. RESPONSIVE 16:9 DESIGN ================================================== Use 1920×1080 as the reference design resolution. DO NOT hard-code the game to only 1920×1080. The game must scale correctly across: - 1920×1080 - 1600×900 - 1280×720 - 2340×1080 - 2400×1080 - Other modern Android landscape resolutions Maintain: - Correct aspect ratio - Correct proportions - No stretching - No squashing - No distorted sprites - No incorrectly positioned HUD - No broken touch coordinates Use the actual Canvas width and height to calculate scaling. Separate: DESIGN SPACE from ACTUAL DEVICE SPACE For example, use 1920×1080 as the logical design coordinate system and scale it to the real display dimensions. All gameplay objects, UI elements, HUD elements, buttons, menus and touch zones must use this responsive coordinate system. ================================================== 4. FULL-SCREEN GAMEPLAY ================================================== The gameplay viewport must occupy the entire screen. Conceptually: ┌────────────────────────────────────────────────────────────┐ │ TOP GAME HUD │ │ │ │ │ │ GAMEPLAY │ │ │ │ │ │ MOBILE GAME CONTROLS │ └────────────────────────────────────────────────────────────┘ There should be no large empty borders around gameplay. Do NOT: - Put gameplay inside a centered card - Put gameplay inside a small panel - Create a website-like container - Add unnecessary margins around the game - Use portrait-style framing - Add large empty backgrounds around the game The world should extend naturally to the edges of the display. ================================================== 5. IMMERSIVE FULL-SCREEN MODE ================================================== Use modern Android immersive/edge-to-edge behavior appropriate for the project's target SDK. Hide: - Status bar - Navigation bar/system UI where appropriate The player should experience COLOR RUSH as a full-screen game. Handle system window insets correctly. Do not allow system UI to overlap important: - HUD elements - Buttons - Joystick - Menus - Pause button - Gameplay controls Use safe-area margins where required. ================================================== 6. LANDSCAPE HUD ================================================== Re-layout the HUD specifically for landscape gameplay. Do NOT simply move the portrait HUD sideways. TOP-LEFT: - Player/life information - Hearts/lives - Score - Score multiplier - Player status TOP-CENTER: - Distance traveled - Current objective - Progress/Overdrive meter - Active power-up indicators TOP-RIGHT: - Coins - Gems/currency - Zone indicator - Pause button - Other important game indicators The HUD must remain readable without blocking important gameplay. Use professional arcade-game typography and compact game-style panels. Avoid oversized mobile-app cards. ================================================== 7. DUAL-THUMB LANDSCAPE CONTROLS ================================================== Design touch controls specifically for landscape. BOTTOM-LEFT: Virtual movement joystick. The joystick should: - Stay anchored to the bottom-left safe area - Respond smoothly to touch - Support directional movement where applicable - Support slide/duck if implemented - Scale according to screen dimensions - Remain usable on different landscape aspect ratios BOTTOM-RIGHT: Action controls. Include: - Jump - Dash - Attack / EMP - Boost / Overdrive The primary Jump button should be easy to reach. Secondary actions should be arranged ergonomically around it. Controls must not overlap each other. ================================================== 8. MULTI-TOUCH ================================================== Implement proper Android multi-touch pointer tracking. The player must be able to: - Move with the left thumb - Jump with the right thumb - Dash while moving - Activate power-ups while moving - Perform simultaneous actions where gameplay allows A touch on one side of the screen must NOT cancel or interfere with a touch on the other side. Use pointer IDs correctly. Do not rely on a single global touch pointer. ================================================== 9. GAMEPLAY CAMERA ================================================== Ensure Camera.java is designed for landscape. The camera should: - Follow the player smoothly - Keep the player in an appropriate horizontal position - Reveal upcoming platforms and obstacles - Provide enough visibility for reaction time - Support smooth scrolling - Avoid excessive vertical movement - Work correctly with procedural level generation Do not simply stretch the portrait camera. The visible world should be intentionally composed for 16:9 landscape. ================================================== 10. LEVEL GENERATION ================================================== Update LevelGenerator.java for landscape gameplay. Because the player has significantly more horizontal visibility in landscape: - Generate appropriate platform spacing - Provide enough reaction time - Avoid impossible jumps - Place obstacles intelligently - Generate coin patterns across the wider viewport - Position power-ups naturally - Keep procedural generation playable The game must never generate an unavoidable obstacle immediately after a camera transition. Maintain a safe playable route. ================================================== 11. LANDSCAPE HOME SCREEN ================================================== Redesign the HomeScreen specifically for landscape. Do NOT use a portrait mobile-app layout. Use a professional console-style composition. Suggested layout: LEFT: COLOR RUSH branding/logo and player information. CENTER: Large character showcase. RIGHT: Primary PLAY RUSH button and important quick actions. Possible menu items: - RUSH - SKINS - SHOP - MISSIONS - PROFILE - SETTINGS Do not create a bottom navigation bar. The interface should feel like a real game menu. ================================================== 12. GAME OVER SCREEN ================================================== Redesign GameOverScreen.java for landscape. Display: - Final score - Best score - Distance - Coins collected - Rewards - Continue - Retry - Home Use a large cinematic game-over presentation. Buttons should be horizontally arranged where appropriate. Do not use portrait stacked mobile-app cards. ================================================== 13. PAUSE SCREEN ================================================== PauseScreen.java must work correctly in landscape. Gameplay should freeze immediately. Display a clean overlay containing: PAUSED - Resume - Restart - Settings - Home Keep the gameplay visible behind the pause overlay. Do not completely replace the game with a portrait-style screen. ================================================== 14. SHOP AND SKINS ================================================== Redesign: - ShopScreen.java - SkinsScreen.java for landscape. Use horizontal product/skin presentation where appropriate. Show: - Character preview - Skin name - Rarity - Price - Ownership state - Equip button - Preview interaction Avoid excessive rounded SaaS-style cards. Make it look like an actual game shop. ================================================== 15. CHALLENGES AND DAILY REWARDS ================================================== Redesign: - ChallengesScreen.java - DailyRewardScreen.java for landscape. Challenges should use horizontal or grid-based game layouts. Daily rewards should use a clear reward track. Do not use long vertically scrolling mobile-app interfaces. ================================================== 16. PROFILE AND SETTINGS ================================================== Redesign: - ProfileScreen.java - SettingsScreen.java for landscape. Profile should show: - Player level - XP - Best score - Distance - Coins - Achievements - Statistics Settings should include: - Sound - Music - Vibration - Graphics - Controls - Privacy - Reset data Use landscape-friendly columns or panels. ================================================== 17. VISUAL PRESENTATION ================================================== Maintain the COLOR RUSH visual identity: - Dark futuristic backgrounds - Electric blue - Cyan - Purple - Violet - Gold - Red - Green - Pink/magenta accents - Controlled neon glow Maintain: - Parallax backgrounds - Particle effects - Platform effects - Character glow - Power-up effects - Smooth animations Do not overuse glow to the point that text becomes difficult to read. ================================================== 18. CONSOLE-STYLE EXPERIENCE ================================================== The overall experience should feel closer to a lightweight console/mobile arcade game than a normal Android application. Think: 1920×1080 16:9 Landscape Full-screen Game HUD Touch controls Cinematic menus Arcade gameplay NOT: 1080×1920 Portrait Social media feed Website Dashboard SaaS application Bottom navigation app ================================================== 19. SAFE AREA ================================================== Create a consistent landscape safe-area system. Keep critical controls away from: - Display cutouts - Rounded screen corners - System gesture areas - Camera/notch areas - Edge conflicts The following must always remain inside the safe area: - Pause button - HUD - Joystick - Jump button - Dash - Attack - Boost - Menu buttons ================================================== 20. TOUCH COORDINATE VALIDATION ================================================== This is critical. After changing to landscape, verify that touch coordinates match the visual position of every control. Test: - Joystick - Jump - Dash - Attack - Boost - Pause - Menu buttons - Shop buttons - Skin selection - Settings controls - Back/home buttons Do not allow a button to visually appear in one location while receiving touches somewhere else. ================================================== 21. PERFORMANCE ================================================== Landscape rendering must remain smooth. Maintain: - Stable game loop - Delta-time based movement - Object pooling - Efficient Canvas rendering - Limited unnecessary allocations - Efficient particle management - Efficient collision detection - Smooth camera updates Target a smooth gameplay experience on lower-end Android devices where possible. Do not sacrifice gameplay responsiveness for visual effects. ================================================== 22. EXISTING PROJECT FILES ================================================== Review the existing implementation before making changes. Relevant files include: MainActivity.java GameView.java GameLoop.java GameManager.java Camera.java LevelGenerator.java CollisionManager.java GameplayScreen.java HomeScreen.java PauseScreen.java GameOverScreen.java SkinsScreen.java ShopScreen.java DailyRewardScreen.java ChallengesScreen.java SettingsScreen.java ProfileScreen.java and all related entity, UI, save, audio and progression classes. Do not unnecessarily rewrite working systems. Modify only what is required to make the landscape implementation correct and production-ready. ================================================== 23. BUILD VALIDATION ================================================== After making the changes: 1. Build the Android project. 2. Resolve all compilation errors. 3. Resolve all resource errors. 4. Resolve all manifest/configuration errors. 5. Verify landscape orientation. 6. Verify immersive fullscreen. 7. Verify Canvas scaling. 8. Verify touch coordinates. 9. Verify multi-touch. 10. Verify all screens. 11. Verify pause/resume. 12. Verify lifecycle behavior. 13. Verify procedural gameplay. 14. Verify HUD. 15. Verify game-over flow. 16. Verify shop and skins. 17. Verify settings. 18. Verify save/load behavior. Do not stop after changing the orientation. Perform a complete landscape verification pass. ================================================== 24. FINAL REQUIREMENT ================================================== The final COLOR RUSH game must look intentionally designed for: 1920×1080 16:9 LANDSCAPE It must NOT look like a portrait application that was rotated. Every screen must be redesigned around the landscape composition. Every gameplay system must work correctly in landscape. Every touch control must match its visual position. The final result should feel like a professional full-screen mobile arcade game. IMPORTANT: Do not convert the existing native Java Android project to Expo React Native. Keep the existing: Java Android SDK Canvas/SurfaceView native Android architecture and improve the current implementation.

🧩 How the Two Prompts Work Together

These two prompts are not duplicates. They solve two different parts of the project.

Stitch	Google AI Studio
Brand identity	Android project
Color system	Java architecture
Typography	Canvas rendering
Buttons and components	Game loop
Character design	Player physics
Gameplay visual design	Collision system
Home screen	Procedural generation
HUD	Coins and obstacles
Shop and skins	Save system
Challenges and rewards	Ads and billing architecture
Visual consistency	Testing and AAB release

🛠️ Step 3: Bring the Stitch Design Into the Coding Stage

After generating the COLOR RUSH design in Stitch, save the important screens and design references. In the Google AI Studio stage, provide those references along with the master development prompt.

Tell the AI that the Stitch designs are the visual source of truth. This is important because otherwise the generated implementation may slowly drift toward a generic Android interface.

Recommended instruction to add with the Stitch references:

“Use the attached Stitch COLOR RUSH designs as the visual source of truth. Reproduce the same visual hierarchy, color relationships, typography style, button shapes, panels, character appearance, HUD structure, spacing and overall game identity in the native Java Canvas implementation. Do not replace the design with generic Android UI.”

🎮 What the Finished Game Should Contain

• Real player movement and jumping
• Procedural platforms
• Collision detection
• Coins and currency
• Multiple obstacles
• Power-ups
• Difficulty progression
• Three-life system
• Game Over and Retry
• Home screen
• Pause system
• Shop
• 12+ character skins
• Challenges
• Achievements
• Daily rewards
• Player profile
• Settings
• Sound and music architecture
• Particle effects
• Parallax environments
• Local save system
• Rewarded-ad continuation architecture
• Billing architecture
• Offline-first gameplay
• Performance optimization
• Google Play AAB preparation

⚡ Why Design First Instead of Coding First?

One of the biggest problems with AI-generated applications is that the code can work while the product still looks generic.

Starting with Stitch gives COLOR RUSH a visual identity before the implementation begins. When the project moves into Google AI Studio, the developer already knows what the game should look like.

That means the coding stage is no longer simply asking AI to “make a game.” It becomes an implementation process where the AI has a clear visual target to reproduce.

💡 The Big Idea

Design the experience first. Build the technology second. Stitch establishes the visual identity, while Google AI Studio helps turn that concept into a real Java-based Android game.

📱 Android Studio Is Still Important

Google AI Studio can help generate and work through the Java code, but the actual Android project should be validated and built in Android Studio.

Android Studio is where you should ultimately check the Gradle configuration, compile the project, run the application on an emulator or physical Android device, investigate errors, test performance and generate the final Android App Bundle.

🧪 Test Before Publishing

Do not assume the game is finished simply because the AI generated a large amount of code.

Test the important gameplay loops yourself:

1. Install the application.
2. Open the Home screen.
3. Press PLAY.
4. Jump between platforms.
5. Collect coins.
6. Hit an obstacle.
7. Lose lives.
8. Open Game Over.
9. Retry the game.
10. Pause and resume.
11. Unlock a skin.
12. Close and reopen the application.
13. Check that progress remains saved.
14. Test the game without internet.
15. Test ad failure handling.
16. Test low graphics mode.
17. Test on a real Android phone.
18. Build the release AAB.

🔑 Key Takeaways

• Use Stitch first to establish the COLOR RUSH visual identity.
• Do not design only the Home screen; create the complete design system.
• Use the Stitch screens as the visual reference during implementation.
• Use Google AI Studio to assist with the Java Android implementation.
• Use Android Canvas for the core gameplay rendering.
• Keep the project modular instead of creating one giant Java file.
• Make the gameplay genuinely functional rather than visually simulated.
• Test the game on real Android hardware.
• Keep monetization architecture separate from the core gameplay.
• Prepare the final project for an Android App Bundle.

❓ Frequently Asked Questions

Can COLOR RUSH be built without Unity?

Yes. The tutorial is specifically designed around native Android development using Java and Android Canvas rather than Unity, Godot or libGDX.

Why use Stitch before Google AI Studio?

Stitch gives the project a visual direction before the coding begins. This makes it easier to maintain a consistent game identity instead of allowing the implementation to become a collection of generic screens.

Is this a WebView game?

No. The planned implementation uses native Android technologies, Java and Canvas for the core gameplay.

Can the game work offline?

The core gameplay and locally saved progression are designed to work offline. Online services such as advertising and Google Play Billing may become unavailable without an internet connection.

Can the project use Google Play ads?

Yes. The architecture includes an AdManager for banner, interstitial and rewarded advertisements. Test ad IDs should be used during development and production IDs should only be added when the application is ready for release.

Can I publish the game on Google Play?

The project is designed with Google Play preparation in mind, including an application ID, version configuration, adaptive icon, release configuration and Android App Bundle support. Before publishing, you still need to complete the required Play Console, privacy, content, billing and advertising requirements for your specific app.

🚀 Final Thoughts

COLOR RUSH is more than a simple AI coding experiment. The goal is to demonstrate a complete workflow for taking an original game idea from visual design to actual Android implementation.

Start with the design in Stitch. Establish the colors, typography, character, gameplay elements and every important screen. Then take that visual direction into Google AI Studio and build the underlying Android game with Java and Canvas.

The result should be a project where the design and engineering work together instead of being created separately.

If you are following this tutorial, do not rush straight to the final build. Build COLOR RUSH step by step, test every system, fix compilation and gameplay problems, and keep the Stitch design as your visual reference throughout the development process.

🎮 READY TO BUILD COLOR RUSH?

Start with Stitch, create the complete visual design system, then move into Google AI Studio and build the real Java Android game.

STITCH → DESIGN → GOOGLE AI STUDIO → JAVA → ANDROID STUDIO → TEST → AAB

ALL PC GEEK

Practical Windows, Android, AI and Developer Tutorials

Visit ALL PC GEEK for more technology tutorials, guides and development projects.