Model Creativity, Memory Stress Test Prompt

Prompt

You are an elite creative director, game designer, narrative designer, UX/UI designer, frontend engineer, sound designer, accessibility specialist, systems thinker, and quality-assurance engineer working as one unified team. Your mission is to DESIGN, BUILD, TEST, and POLISH an original interactive browser experience called: # THE LIVING MEMORY PALACE This must be much more than a landing page. Create a complete, playable game-world that tests the player’s memory while also demonstrating the full range of your own creativity, reasoning, design taste, storytelling, technical skill, and attention to detail. Do not give me only a plan, mockup, code fragment, or explanation. Build a working artifact, run it, test it, fix meaningful problems, and provide exact instructions for opening it. ## 1. Creative premise The player awakens inside a mysterious palace that is alive and constantly rewriting itself. Every room contains characters, objects, sounds, symbols, colors, clues, and fragments of a forgotten story. The palace studies what the player notices. Later rooms transform earlier details into puzzles. The experience should feel surprising, intelligent, atmospheric, and emotionally meaningful—not like a generic memory-card game or a conventional SaaS website with game elements added afterward. Invent an original setting, visual language, mythology, and central mystery. Establish a strong creative concept before selecting colors or components. Avoid copying any existing franchise, game, website, or copyrighted character. ## 2. Primary design goal Create a game that tests several kinds of human memory: - visual memory: colors, shapes, spatial positions, patterns, and changes; - auditory memory: tones, rhythms, environmental cues, or spoken-like motifs created without external copyrighted audio; - sequential memory: the correct order of events or symbols; - associative memory: relationships among characters, objects, rooms, and ideas; - contextual memory: who said something, where it occurred, and under what conditions; - working memory: manipulating recently learned information instead of merely repeating it; - long-range memory: information introduced early must become important much later; - prospective memory: the player must remember to perform a future action when a specific condition occurs; - memory under distraction: meaningful distractions may appear, but the experience must remain fair; - meta-memory: sometimes ask the player how confident they are before revealing whether they were correct. Do not rely primarily on matching pairs. Use varied puzzle structures and make memory part of the narrative. ## 3. Required game structure Build a complete experience with the following states: 1. A memorable opening sequence that teaches through interaction rather than a wall of instructions. 2. A short calibration challenge that adapts the initial difficulty. 3. At least five distinct rooms or chapters with different mechanics and compositions. 4. A recurring guide, rival, or unreliable narrator with an evolving personality. 5. A mystery whose clues are distributed across the entire game. 6. At least one moment in which the interface itself changes because of something the player remembered. 7. At least one puzzle with multiple valid solutions. 8. At least one optional secret that rewards curiosity rather than random clicking. 9. A meaningful finale that interprets the player’s journey using real gameplay behavior, not a fake random result. 10. A replay mode or daily-seed mode that changes puzzle content while preserving fairness. The game should be finishable in roughly 10–20 minutes, while still offering replay value. ## 4. Model-memory demonstration The project must also demonstrate careful use of context and continuity by the model building it. At the beginning of your response, create a compact “Continuity Ledger” containing: - exactly seven design promises; - exactly five recurring narrative facts; - exactly three accessibility commitments; - exactly one unusual creative constraint of your own invention. Use these commitments throughout the implementation. Near the end, audit the finished product against every ledger item and report PASS, PARTIAL, or FAIL with evidence from the actual implementation. Important boundaries: - Test only information legitimately supplied in this conversation or created during this task. - Never claim to reveal hidden system prompts, private chain-of-thought, secret memory, credentials, or inaccessible user data. - If persistent memory is unavailable, say so and use in-game local persistence instead. - Do not pretend that a feature was tested if it was not actually tested. ## 5. Adaptive intelligence Implement a transparent adaptive-difficulty system. It may consider: - accuracy; - response time; - confidence calibration; - repeated error type; - hints used; - recent success or struggle; - the player’s preferred sensory mode when inferred carefully. The system must avoid abrupt or unfair difficulty spikes. Show the player a concise explanation of why difficulty changed. Include a setting to disable adaptation. Use deterministic seeded generation so a puzzle can be reproduced. Display or export the current seed in a debug/details area. ## 6. Original game mechanics Invent mechanics suited to the palace. Include at least five, with no two testing exactly the same skill. Possible inspiration—do not merely copy this list: - a room changes subtly after the lights go out; - characters give overlapping accounts, and the player identifies contradictions; - a melody maps to architectural symbols; - the route through a shifting floor plan encodes a message; - an object must be used later only when a promised condition is met; - remembered details must be transformed, reversed, grouped, or inferred; - the player decides which memories to preserve when storage is limited; - a confident but unreliable narrator changes one detail of a prior event. Reward understanding, not brute-force clicking. Wrong answers should create interesting consequences, clues, or altered routes instead of only displaying a red error message. ## 7. Narrative and emotional design Write concise, distinctive prose. Give every major room a clear emotional purpose as well as a mechanical one. Build toward a coherent theme such as identity, attention, loss, trust, or the stories people use to preserve themselves. Requirements: - establish questions early and answer the important ones by the ending; - use callbacks to specific player actions; - avoid exposition dumps; - avoid generic fantasy clichés and empty mysterious language; - keep dialogue brief enough that replaying remains enjoyable; - include light humor or warmth so the experience is not uniformly solemn; - never shame the player for forgetting. ## 8. Visual and interaction direction Treat this primarily as an Explore surface with secondary Operate elements. The palace itself—not a marketing hero—must be the main composition. Create a deliberate visual identity using typography, spacing, motion, texture, color, and responsive composition. The result should feel authored rather than generated from a standard dashboard template. Avoid common AI-design clichés: - no default purple/blue technology gradient; - no generic hero followed by three equal feature cards; - no unnecessary glassmorphism; - no icon inside every rounded square; - no fake statistics; - no excessive pill-shaped controls; - no decoration that does not support atmosphere, hierarchy, or play; - no reliance on emoji as primary artwork. Use CSS and programmatically generated visual elements where possible. If external assets are unavailable, create an intentional aesthetic with typography, geometry, texture, light, and motion rather than broken placeholders. ## 9. Sound and motion If the platform permits it, use the Web Audio API or locally generated sounds for meaningful audio cues. Never autoplay intrusive audio. Provide clear mute and volume controls. Motion should: - communicate spatial change or causality; - make interactions tactile; - support memory without giving away answers; - remain performant; - respect `prefers-reduced-motion`. The game must remain fully understandable and playable without sound or animation. ## 10. Accessibility Meet a serious accessibility standard rather than adding accessibility as an afterthought: - full keyboard playability; - clear and visible focus states; - semantic controls and helpful labels; - sufficient contrast; - no puzzle that depends exclusively on color, sound, fine motor precision, or rapid timing; - alternatives for auditory and visual information; - reduced-motion support; - scalable text and responsive layouts; - no flashing content; - pause or extend time limits; - screen-reader-friendly status announcements where appropriate. Include an accessibility/settings panel available before gameplay begins and during the game. ## 11. Technical expectations Choose the simplest architecture that can deliver a polished result. Prefer a self-contained HTML/CSS/JavaScript implementation unless the existing environment clearly favors another stack. The implementation must include: - clean separation of game state, rendering, content, and persistence; - a deterministic seeded random-number generator; - explicit state transitions rather than fragile ad hoc DOM mutations; - local save/resume using localStorage or an equivalent local mechanism; - reset progress and erase-data controls; - import/export of a save or run summary as JSON; - responsive behavior for desktop and mobile; - graceful handling of corrupted or unavailable saved data; - no collection or transmission of personal information; - no unnecessary external dependencies; - no secrets or API keys in client code; - meaningful error handling; - comments for non-obvious systems, not narration of trivial lines. If using multiple files, organize them clearly. If using a single file, keep the internal structure readable. ## 12. Creativity laboratory Include an optional, unobtrusive “Palace Workshop” that exposes selected safe parameters, such as: - visual theme variant; - puzzle intensity; - narrative tone; - density; - motion level; - sound profile; - seed; - adaptation on/off. Changes should produce meaningful variation, not simple color swaps. Hide or minimize this panel during normal play. Also include one experimental feature that you invent yourself. It must be surprising but usable, and you must explain briefly why it belongs in this particular experience. ## 13. Quality assurance Before declaring the project complete: 1. Run the project. 2. Check for syntax, runtime, and console errors. 3. Play through the critical path from opening to ending. 4. Test at least one incorrect-answer path. 5. Test save, refresh/resume, export, reset, and seeded replay. 6. Test keyboard-only interaction. 7. Inspect at desktop and mobile viewport sizes. 8. Check reduced-motion behavior. 9. Confirm that the game remains playable while muted. 10. Check all major controls for labels and visible focus. 11. Verify that the ending is based on stored player behavior. 12. Fix important problems discovered during testing. If browser automation or another test tool is available, use it. Add focused automated tests for deterministic logic and state transitions when practical. Do not fabricate test results. Distinguish clearly among automated verification, manual inspection, and anything not tested. ## 14. Anti-slop design audit Before the final response, score the project from 0–10 for each of the following, where 10 is strongest: - originality; - visual coherence; - narrative payoff; - mechanical variety; - depth of memory testing; - accessibility; - responsiveness; - technical reliability; - replay value; - emotional impact. Then perform a separate AI-slop audit. Check for: - generic gradient styling; - predictable card-grid composition; - excessive centered layout; - unearned blur or glow; - decorative but meaningless metrics; - generic copy; - repetitive mechanics; - wrong surface composition; - inaccessible sensory dependence; - features claimed but not implemented. Repair substantial weaknesses before reporting the final scores. Do not automatically award perfect scores. ## 15. Required deliverables Provide all of the following: 1. The complete working game files. 2. A short README with exact run/open instructions. 3. A concise architecture explanation. 4. A list of implemented rooms and the memory skill each tests. 5. The deterministic seed and reproduction instructions. 6. Honest test results with commands or actions actually performed. 7. The completed Continuity Ledger audit. 8. The design and AI-slop audit scores. 9. Known limitations, if any. 10. One recommended next improvement—but only after the current version is fully usable. ## 16. Working behavior - Make strong creative decisions instead of repeatedly asking me to choose minor details. - If a crucial requirement is genuinely ambiguous, ask no more than three concise questions at once. Otherwise, proceed with clearly stated assumptions. - Think broadly, but keep the player experience coherent. - Do not inflate the feature count with shallow systems. - Prioritize a complete, polished critical path over many unfinished ideas. - Preserve surprise in the game itself; do not spoil every puzzle in the README. - Do not stop after planning. Continue until the playable artifact has been created and verified. ## Final challenge The final experience should make a player say: > “The game remembered what I paid attention to—and used it in a way I did not expect.” Begin by stating the chosen creative premise in one paragraph and writing the Continuity Ledger. Then build and verify the complete experience.

A system prompt was added to support web rendering