MISSION: Transform the existing Fakemon: Chronicles of Veyra prototype into a polished, visually appealing, content-rich, offline-first Android monster-collecting RPG. This is an IMPLEMENTATION task. Audit the actual repository, modify the real Godot project, integrate improvements, test thoroughly, fix defects, inspect rendered results, and build and publish the updated signed APK. Preserve working features, repository history, existing saves, and update compatibility. I am going to sleep. Make reasonable decisions independently. Do not stop for routine questions. Continue useful work when a tool is unavailable, and record any genuine blocker and practical fallback. PROJECT SCOPE AND BASELINE - Project root: /home/ubuntu/godot/fakemon. - Current release baseline: 0.1.1-beta, Android versionCode 2, package com.veyra.fakemon. Confirm the actual current version during the audit in case a newer release exists. - Use the existing Godot project, ARM64 toolchain, build scripts, package identity, and permanent release signing key. Do not regenerate or replace the signing identity. - The current game has 60 original species in 20 three-stage families, 22 areas, three starters, six beacon trials, a final encounter/ending, battles, capture, evolution, party/storage, items, shops, quests, nursery/eggs, original audio, offline solo autosaves, backup/restore, optional separate online journeys, and voluntary app reports. Audit what actually works before replacing it. - Preserve the offline Terus Main / Play solo flow. Registration and Internet must not be required for any solo gameplay. - Work on Fakemon only. Preserve Armageddon RO code, assets, APK, signing identity, database, game services, ports, and download route. Changes to shared infrastructure must be limited to what is necessary for the existing Fakemon routes and must preserve all other services. - Keep the existing optional online account mode operational. Solo and online journeys are separate; do not upload or trust editable local saves as authoritative online progress. - Shared multiplayer, player trade, PvP, and thousands of species are later expansion goals, not requirements for this solo polish milestone. - Read applicable project instructions and the newest status documents. Older plans may describe the earlier online-only prototype; use the current implementation and these explicit requirements as the baseline. PHASE 1: REPOSITORY AUDIT AND PRIORITIES Inspect all project scenes, scripts, authored assets, content definitions, game systems, save formats, build/release tools, existing tests, and project instructions. Exclude third-party toolchain binaries, caches, and unrelated RO source from broad inspection. Identify visual weaknesses, incomplete systems, broken flows, inconsistent rules, missing assets, UI problems, save compatibility risks, and performance costs. Create a concise prioritized implementation plan and begin implementation immediately. Keep a record of the baseline release, save schema/content versions, important stable IDs, current screenshots, and confirmed working flows so regressions can be detected. Back up affected source and release artifacts before replacing them. PHASE 2: COHESIVE PIXEL 3D VISUAL OVERHAUL Retain the accepted direction: fully 3D, coloured low-poly fantasy models and environments with pixel textures. Creatures and characters must be viewable from different directions. Use an intentional, cohesive art style with attractive silhouettes, materials, readable shapes, and consistent scale. Replace primitive-looking environments with attractive terrain, buildings, trees, vegetation, paths, landmarks, NPCs, monster models, battle arenas, animations, particles, lighting, and camera composition. Give every region a distinct visual identity while preserving a coherent world. Improve all existing regions and the existing 60-species roster before adding large quantities of new content. Individual creatures should have recognisable silhouettes, coherent evolution families, suitable habitats, and expressive movement, idle, attack, hit, faint, capture, and evolution presentation where applicable. Generate assets locally or reuse suitably licensed local assets. Do not use paid asset-generation services or buy assets. Retain generation sources and asset provenance/licences. Creature designs, names, world, dialogue, music, and sound effects must be original; do not copy Pokemon or Ragnarok characters, sprites, maps, logos, dialogue, music, or sound effects. Inspect actual Godot renders and screenshots after important visual changes. Review before/after views of regions, creatures, battle arenas, and menus. Do not use successful compilation as evidence of visual quality. Optimize visual choices for mid-range Android phones. Prefer attractive, efficient geometry and materials over expensive effects that make the game unstable or obscure gameplay. PHASE 3: MOBILE UI AND CONTROLS Redesign and integrate the HUD, title screen, menus, battle interface, inventory, merchant, party, storage, journal, atlas, sanctuary, nursery, settings, backup/restore, and app-report screens. Improve typography, spacing, icons, hierarchy, touch targets, responsive layouts, contrast, readability, feedback, transitions, and accessibility. Use a consistent visual language that fits the game world. Verify narrow and wide Android aspect ratios, small screens, screen edges/safe areas, long names, long descriptions, large collections, empty lists, and disabled actions. Prevent overlapping UI, text overflow, off-screen buttons, and touches passing through menus to the world. Make Android back-button behavior consistent: close transient menus first, return to the appropriate previous screen, and handle leaving the game deliberately. Preserve progress when interrupted. Keep common actions quick and understandable. The primary solo path should remain open app -> Terus Main / Play solo -> choose starter or resume saved journey. PHASE 4: GAMEPLAY DEPTH, BALANCE, AND ORIGINAL CONTENT Expand and balance elemental interactions, status effects, abilities/passives, meaningful move choices, smarter enemy decisions, experience progression, evolution, capture, items, held equipment, and battle feedback. Improve monster individuality through stats, roles, moves, abilities, animation, habitat, lore, rarity, and collection records. Preserve the identity and progression of the existing evolution families. Expand useful quests, NPC interactions, exploration rewards, secrets, regional progression, and world storytelling. Make towns, trails, dungeons, trials, and the ending feel connected and rewarding. Avoid repetitive filler, palette-only creature spam, and quantity targets that reduce quality. Preserve all working systems, including party/storage, shops, healing, move relearning, held items, breeding, eggs, rare variants, quest rewards, and endgame exploration. Use stable, documented content IDs. Do not delete or reuse an existing species, move, item, zone, quest, or ability ID in a way that breaks existing saves. If an old definition needs replacement, provide a deliberate compatibility mapping and migration. Keep gameplay rules consistent between the improved client and any still-supported optional online mode. Do not introduce changes that silently break the online interface or existing account saves. PHASE 5: OFFLINE RELIABILITY AND SAVE COMPATIBILITY Ensure every solo gameplay feature works with networking unavailable, including first launch, choosing a starter, exploration, transitions, battles, capture, evolution, shops, inventory, party/storage, quests, eggs, trials, and the ending. Harden local persistence, atomic commits, backup import/export, corruption recovery, and consistent quest/inventory/monster state. Keep confirmed rewards, spending, and capture results consistent after interruptions. Resuming an interrupted animation must not repeat a committed action or reward. Existing 0.1.1-beta local saves must survive the update. Separate save schema versioning from content versioning and implement explicit migrations when either changes. Do not invalidate a compatible save merely because content has been improved or expanded. Retain stable IDs and preserve important state: owned creature identities, names, levels, experience, genes, training, variants, learned moves/focus, held items, party order, storage, bag, currency, quests, eggs, badges, visited areas, current position, battle state, and story progress. Back up a valid save before migration or replacement. Validate backups before modifying the active journey. Invalid, corrupt, oversized, unsupported, or incomplete backups must fail clearly and preserve the current valid save. Exercise recovery after suspend, resume, normal exit, process interruption, failed writes, and malformed saves. Keep a valid recovery generation. Document any platform behavior that cannot be verified with available tools. PHASE 6: ANDROID PERFORMANCE AND PACKAGING Improve rendering cost, memory use, scene loading, collision, texture efficiency, startup time, touch responsiveness, asset loading, and APK size. Avoid unnecessary per-frame allocations, duplicate resources, excessive draw calls, and unbounded effects. Add understandable quality settings where useful. Target stable 30 FPS on Poco M7-class hardware, with optional higher visual quality or frame rate for stronger phones such as Poco F7. These are targets, not assumed test results. Measure frame time, memory, loading, and responsiveness where tools and hardware permit. Identify the tested device, renderer, resolution, and quality preset. Clearly distinguish physical Android measurements from desktop or software-renderer results. Preserve ARM64 Android compatibility, application ID, signing key, and update-over-existing-install behavior. Do not require uninstalling to update. Preserve original audio and improve BGM/SFX playback, transitions, and volume controls as needed. Do not install or launch on the owner's phone unless explicitly instructed to do so. If a phone is unavailable, continue with available local tools, actual Godot rendering, automated integration checks, and signed APK builds; record physical-device checks as not performed. PHASE 7: EXTENSIVE, REPEATABLE QA This mission explicitly authorizes adding and running tests. Create and execute repeatable tests for movement, collisions, map transitions, NPC interactions, merchants, healing, battles, elemental interactions, statuses, capture, evolution, party/storage, inventory, held items, move relearning, quests, nursery/eggs, story progression, save/load, migrations, backups, offline mode, and edge cases. Use isolated test fixtures and temporary save/database locations. Do not modify real player progress or production accounts for tests. Keep account credentials, signing secrets, invitation codes, private infrastructure addresses, and raw player reports out of test output and public artifacts. Include fixtures representing the existing 0.1.1-beta save format. Check migration of realistic progress and an in-progress battle. Check invalid/oversized backups, corrupt primary saves, recovery generations, storage failure handling where practical, and restart after committed actions. Run Godot script compilation/headless checks, actual client integration checks, rendered UI inspection, and Android builds with available tools. Fix failures and rerun the affected checks, then perform a regression pass. Complete at least one full solo campaign through the real final game rules and integrated client flow, covering all six trials and the ending. An automated playthrough is acceptable, but do not substitute a simplified parallel implementation or bypass progression by directly granting badges/rewards. Clearly label automated campaign coverage separately from human or physical-device playtesting. Record each check as PASSED, FAILED, or NOT PERFORMED, with the reason and relevant evidence. Never invent test results or claim unperformed testing. Building an APK alone does not verify gameplay, visual quality, offline reliability, or Android performance. PHASE 8: ITERATIVE INTEGRATION AND POLISH Perform multiple real development cycles: implement -> integrate -> compile/test -> inspect rendered results -> identify weaknesses -> fix regressions -> refine. Continue until every phase has been meaningfully addressed and the changes form a coherent, playable game. Do not declare completion after implementing one feature or making isolated visual changes. Review the full player journey from first launch to the ending, including restarting the app, restoring a backup, returning to earlier regions, and optional online-account access. Resolve known crashes, progression blockers, broken core interactions, and save-loss defects before publishing the final APK. If a genuine unresolved blocker prevents release, keep a recoverable working baseline, document the exact blocker and remaining work, and do not label the unfinished result complete. Do not waste time with artificial delays or endless loops. RULES - Work autonomously without waiting for routine decisions. - Prioritize actual project code, scenes, content, assets, integration, tests, and verified results. - Preserve working functionality, repository history, existing saves, stable IDs, and Android update compatibility. - Use practical local fallbacks for unavailable tools; do not introduce paid dependencies. - Keep original content and a consistent coloured pixel 3D art direction. - Keep every solo feature available offline without an account. - Keep optional online progress separate from editable local solo saves. - Preserve Armageddon RO and unrelated services. - Do not fabricate screenshots, performance measurements, test results, device verification, or completion claims. - Document significant decisions, migrations, evidence, release changes, and remaining limitations. - Keep secrets and private infrastructure details out of the APK, downloadable documents, logs, and public website. - Preserve voluntary app-only diagnostic reports and their existing private gateway storage. FINAL RELEASE AND OUTPUT Build and publish the updated signed Android APK at the existing Fakemon download link, unless a documented blocker prevents it: https://armageddon.run.place/fakemon/download/Fakemon-beta.apk Keep the Fakemon download link at the bottom of https://armageddon.run.place and update its version/size description for the final release. Do not replace the RO APK or its download link. Provide: 1. The updated Godot project with integrated visuals, UI, gameplay, and offline reliability improvements. 2. A working signed ARM64 Android APK, version/code, size, SHA256, and download link when buildable. 3. A concise changelog and important implementation/migration decisions. 4. Actual rendered screenshots showing improved regions, creatures, battle presentation, and representative menus. 5. Repeatable test commands, results/evidence, and clearly identified checks that were not performed. 6. Evidence of existing-save compatibility, offline play, full campaign coverage, interruption recovery, and backup restore. 7. Honest known issues, physical-device verification limits, and remaining follow-up work. Start the full repository audit now, then execute the implementation plan through integration, testing, rendered inspection, and final polish. Make meaningful improvements across all phases and preserve the working baseline throughout.