Majutori development worklog (example)

The following is a copy of our most current worklog. This example will be left here for anyone interested in the project or anyone interested in observing my workflow and developmental descision-making. This was partially generated using A.I. assistance - overall direction of development and game planning was made strictly by the human brain and mind, and this worklog and the accompanying development guide (only viewable by development staff) would not have been possible without elaborate creative foundations and over 20 years of experience in the genre.

This worklog is subject to be erased from this project to preserve privacy and confidentiality - for any reason, at any time. Anyone found copying these assets or ideas will be met with swift and responsive retatalitory/defensive litigation.

Worklog mandate

• Record what work occurred, why it occurred, which canonical assets or design systems were involved, what failed, what changed, what was installed, and what was observed at runtime.

• Preserve proposals, supplied code, user installation, compilation, runtime testing, approval, rejection, and supersession as distinct states.

• Use exact local timestamps where evidence survives. Use date-level entries when the hour was not preserved. Never invent precision.

• Keep the authoritative current design in the Development Guide; use this document to explain the path, evidence, and labor that produced it.

Operating principles carried forward

• Keep the dream large, but keep the active milestone small.

• Build foundations carefully enough that future mechanics do not require reckless rewrites.

• Avoid temporary workarounds when a responsibility split or canonical-owner correction is the actual issue.

• Record each stable checkpoint before moving to the next feature.

• Prefer explicit Script, Object Event, Shader, room, and system ownership with professional neutral code comments.

• Follow Curtis’s binding Majutori development and design rules as strictly as possible unless he explicitly authorizes a specific exception.

Chronology precision and evidence hierarchy

• Exact time: directly recoverable from conversation timestamps, video/capture filenames, or document metadata.

• Date-level: the day or date range is preserved, but the original hour is not. These entries explicitly say “time not preserved.”

• Runtime checkpoint: the user installed or observed the work in GameMaker; compilation and visual behavior may be separately recorded.

• Historical reconstruction: assembled from protected documents and conversation continuity. No missing hour is guessed.

Expanded project timestamp ledger

This ledger is the high-density index. The detailed chronological narrative that follows preserves the full labor record, design reasoning, failures, and follow-up items.

Part I — Detailed Chronological Development Record

Project chronology — earliest preserved foundation through current checkpoint

Dates below reflect available chat timestamps, uploaded capture metadata, document-version history, and the preserved development record. Exact times are included only when recoverable; older entries remain day-level rather than receiving invented timestamps.

ERA I / PROJECT CHARTER AND PREPRODUCTION / JUNE 6–JULY 13, 2026

June 6, 2026 and early information-sheet foundation

• Created and maintained an early information sheet for a “T” or “M”-rated 2D creature-catching video game, with the project still unnamed and code-named Majuu-Majuu.

• Recorded that brainstorming is encouraged and that the final title may change as story, tone, and market positioning evolve.

• Defined the initial core loop around catching, battling, and trading original creatures.

• Planned the first generation of original creatures as 200 total creatures.

• Planned 20 Affinities as the type system, with 200 creatures evenly divisible across them.

• Established an experimental creature level cap of 200, subject to later balancing and testing.

• Defined a five-part rating philosophy: playability, visual design, audio design, control, and replayability.

• Planned RPG and adventure mechanics including gender selection, appearance customization, clothing customization, unlockable clothing, NPC encounters, exploration, and world progression.

• Defined the beginning-of-game Tamer identity concept: new Tamers receive a forearm-mounted PDA-like device with encyclopedia and communication functions.

• Recorded PDA features including creature encyclopedia, Tamer ID, online contacts, friend requests, remote trading, remote battles, messaging, proximity voice, and profile/stat display.

• Recorded visible Tamer ID information such as name, gender/appearance sprite, badges, origin city, online battle count, victories, win ratio, trades, co-op sessions, mystery gifts, play time, and Tamer Reputation.

• Planned three save slots with displayed save information such as Name, Play Time, Location, Creatures, Badges, Date Saved, and screenshot.

• Planned overwrite confirmation text: “Overwrite this save? Are you SURE?”

• Planned local storage and Interdimensional / Multidimensional Storage concepts for creature and item management.

Early GameMaker technical planning before the current narrator checkpoint

• Selected GameMaker Studio as the active implementation environment.

• Recorded IDE version 2026.0.0.16 and runtime 2026.0.0.23 during active coding/debugging.

• Adopted a fixed 60 FPS target as a global development rule.

• Adopted naming conventions: obj_ for objects, scr_ for scripts, spr_ for sprites, snd_ for sounds.

• Established that code should use headers and professional neutral comments for staff readability.

• Chose to use explicit object and event names in instructions because the user benefits from clear naming and step-by-step guidance.

• Moved toward complete event rewrites rather than tiny patches when the full structure is unclear.

• Established that no shortcuts or unstable workaround-style fixes should become the foundation for future systems.

• Set the project goal of stable locked 60 FPS and reliable foundations from the ground up.

• Planned a top-down GBA-style grid movement system inspired by Pokémon rather than freeform movement.

• Defined tile size macro as TILE_SIZE = 16.

• Selected camera visibility of 26 by 15 tiles, producing camera dimensions of 416 by 240 at the native tile scale.

• Defined Direction enum values: Right, Up, Left, Down.

• Defined PlayerState enum values: Idle, Walking, Running, Talking, Menu, Cutscene.

• Defined GameState enum values: Boot, StudioLogo, PublisherLogo, Intro, MainMenu, SaveSelect, Options, Gameplay, Pause, Dialogue, Battle.

• Defined LogoState enum values: Studio, Publisher, Finished.

• Defined NewGameFlowStep enum values: Inactive, OpeningCutscene, NarratorIntro, CharacterSetup, OriginSelect, StorySetupCutscene, Gameplay.

July 4–5, 2026: early GameMaker foundations, movement, startup, and text architecture lessons

• Explored initial GameMaker movement and collision using an object originally named Tamer_male_obj.

• Moved toward renaming the player object to obj_player to match the project naming convention.

• Discussed freeform movement, then shifted the plan to grid-based movement for a GBA Pokémon-style overworld.

• Discussed collision with tilemaps and early PlayerCollision logic using tilemap_get_at_pixel, while later recognizing that grid movement would likely require a more deliberate collision foundation.

• Encountered errors during early movement conversion, including undefined variables and duplicate macro/script conflicts.

• Discussed sprite origin and collision-mask planning, including bottom-center origins and the desire to align the player visually with animated ground tiles.

• Planned future bump animation when colliding with barriers.

• Planned that the player should have no diagonal movement for classic top-down grid traversal.

• Established the room/camera distinction: room size is world/map size, while camera size determines visible area.

• Discussed initial room size of 1280 by 1280 as a map-space size rather than screen resolution.

• Started boot-sequence planning with obj_game as a persistent bootstrap object.

• Planned room flow: rm_boot -> rm_logo -> rm_intro -> rm_menu, later expanded by New Game rooms.

• Created or planned obj_logo_controller for studio and publisher logo sequence.

• Planned logo fade timing at 60 FPS, including 60-frame fade durations and 240-frame hold durations.

• Planned first-ever startup sequence behavior: unskippable studio logo, publisher logo, and opening/pre-title cutscene on first run, skippable on later boots.

• Established a need for startup_config.ini to store install-level flags independently of save data.

• Recorded the distinction between first-ever startup flags and per-save file data.

• Began recognizing the importance of separating flow controllers from rendering controllers and text state controllers.

July 6, 2026: logo, image-layering, GIMP, and title-presentation planning

• Worked on a game logo workflow using a 3840 by 2160 white background in GIMP.

• Planned layer order for logo work: background underneath, waffle layer above, footprint layer above the waffle.

• Asked how to scale an image layer without resizing the background canvas.

• Asked how to re-center an image layer after scaling.

• Asked how to center text accurately above a logo in GIMP.

• Clarified that the user needed exact keystrokes and deselection instructions due to difficulty following earlier vague instructions.

• Recorded the user’s GIMP version as 3.2.4 during troubleshooting.

• Asked about font availability in GIMP and later searched for retro game / pixel / video-game fonts for title-screen use.

• Requested larger title-style retro game fonts suitable for a title screen.

• Rejected initial font suggestions and requested more options, showing strong visual taste and unwillingness to settle for assets that do not match the desired identity.

• Asked for a quick copyright check on provided image assets during logo work, reflecting concern about asset legitimacy.

July 11, 2026: AI/code disclosure, legal-development questions, SFX sourcing, and genre research

• Asked how much the developer is legally entitled to disclose on Steam if ChatGPT generated or assisted with GameMaker Studio code.

• Asked how using ChatGPT as the only programming assistant might affect reception and criticism if no human programmer is hired.

• Asked whether there is proof of games succeeding or failing because of ChatGPT involvement.

• Clarified a development-use distinction: ChatGPT is being used for code generation, debugging, revision, and learning assistance, not as runtime AI inside the shipped game.

• Explored Pokémon / creature-catching patents and legal mechanics, including mechanics around throwing orb-like capture items.

• Asked how long Pokémon has existed and researched major Pokémon-style competitors/IPs.

• Asked whether Temtem is on Xbox and whether it supports crossplay.

• Investigated high-quality Pokémon Crystal-style sound effects, especially text/selection sounds.

• Identified interest in SFX_READ_TEXT_2 or a similar “tiny ping” text/confirm sound effect.

• Wanted to avoid BGB recording as an asset-capture method and requested alternative sources for the desired SFX.

• Clarified that social networking sites such as Facebook, Instagram, TikTok, etc. should be avoided completely when searching for SFX sources.

• Used foobar2000 for audio conversion planning and discussed conversion from FLAC to WAV for GameMaker asset implementation.

• Clarified FLAC bit depth as 16 bits per sample and learned that bitrate alone is not the same as bit depth.

• Asked about dither when converting audio and clarified that dither is not simply masking lossy audio loss; it is mainly for reducing quantization distortion when lowering bit depth.

July 12–13, 2026: creature concepts, animal research, naming, and tonal identity

• Researched serval wildcat uniqueness, hearing, and differences from domestic black cats.

• Researched black jaguar uniqueness, jaw strength, and evolutionary characteristics.

• Requested lists of words related to “dark,” “umbral,” “goth,” evil, and mischievous traits for creature naming.

• Developed the evolution line Malefelyne -> Ebonearr -> Umbrawn.

• Clarified that Malefelyne and Ebonearr are inspired by black domestic cats and serval wildcats, while Umbrawn is inspired by a black jaguar.

• Assigned the line’s type identity around Ambiguous and Umbral Affinities.

• Corrected Ebonear to Ebonearr with two r’s at the end.

• Selected Umbrawn as the final evolution’s name from image/concept work.

• Asked about the Japanese word “Majuu” and its meaning as supernatural beast / magical beast / demon beast depending context.

• Wrestled with whether Majuu-Majuu fit the game’s tone because the user wants mystery and wonder without the title becoming too overtly dark.

• Explored literal translations of “Creature Catcher” and two-word monster/creature-capturing title ideas similar to Majuu Majuu.

• Connected the game inspiration to memories of playing Pokémon late at night, learning about grandmother’s favorite animals, finding animals in the backyard, and discovering something hidden that might be caught or might jump at the player.

• Stated the desire for a cinematic epic story with a very human element and a single-player script that can be heartbreaking and evocative.

• Researched animals that visually or behaviorally share affinity with grass, hiding, ground-level flight, and natural camouflage, supporting the broader creature-inspiration pipeline.

ERA II / FIRST PLAYABLE FOUNDATIONS / JULY 14–15, 2026

July 14, 2026: audio assets, opening flow, New Game structure, and MP4 implementation

• Imported or planned audio assets including snd_intro_magnet_train, snd_sfx_run, snd_music_title_screen, and snd_music_introductions.

• Used “1-75. Magnet Train.flac” as placeholder intro/cutscene music.

• Used a Crystal title-screen track as title-screen music reference/placeholder.

• Imported “Introductions” as placeholder music intended for narrator text, character setup, and origin city selection.

• Discovered that GameMaker music assets should use Stereo when the source file is stereo, after an audio issue with the Introductions track.

• Planned MP4 playback using an Included File placeholder named intro_placeholder.mp4 / intro_placeholder.mp4.mp4 depending project file naming.

• Separated two different MP4/cutscene roles: pre-title cinematic before the main menu and New Game opening cutscene after selecting New Game.

• Clarified the New Game flow: Main Menu -> New Game -> Opening MP4 cutscene -> Narrator / introductory text -> Gender selection / name selection / customization -> Origin city selection -> story setup cutscene -> starting apartment / laboratory gameplay.

• Clarified that the Introductions music should begin at narrator text and continue through character setup and origin city selection, stopping when the origin city is confirmed.

• Created or used rm_opening_cutscene for the New Game opening cutscene.

• Created or used rm_narrator_intro for the narrator introduction step.

• Planned that the first opening cutscene viewing should be required and later New Game attempts may skip it for quality of life.

• Used startup_config.ini to store OpeningCutsceneSeen separately from IntroSequenceSeen.

• Implemented or planned obj_opening_cutscene_controller to open the placeholder MP4, track video completion, handle skip input when allowed, fade to black, update OpeningCutsceneSeen, and call scr_new_game_flow_advance().

• Implemented or planned Async Social Event handling for video_start and video_end callbacks.

• Encountered a placeholder visual issue where the opening cutscene displayed “Opening cutscene video could not be played.”

• Separated the MP4 visual-message issue from the narrator text box issue; the cutscene could still advance to the narrator phase even when placeholder video rendering was not clean.

July 14–15, 2026: main menu, title music, neon affinity ring, and central New Game flow

• Built a temporary main menu controlled by obj_menu_controller.

• Main menu options included New Game, Load Game, Multidimensional Storage, Settings, and Quit to Desktop.

• Planned Load Game to appear only after saved progress exists in future versions.

• Set temporary game title display to “(Codenamed) Majuu-Majuu.”

• Created title-screen music startup with optional delay when intro skipping plays snd_sfx_run.

• Used global.titleMusicInstance so menu music can be stopped cleanly when New Game is selected.

• Implemented title flicker timing to simulate a neon sign startup effect.

• Built a decorative rotating neon affinity ring around the title and selected menu item.

• Defined affinity colors for all 20 Affinities: Ambiguous, Aerial, Combat, Fire, Water, Ice, Grass, Insect, Arachnid, Rock, Earth, Electric, Poison, Drake, Psionic, Spectral, Metal, Umbral, Sprite, and Cyber.

• Added a dialogue input lock in obj_menu_controller so menu navigation pauses when a text box is active.

• Moved New Game selection from direct rm_game loading to scr_new_game_flow_start().

• Created obj_new_game_flow_controller as a persistent central owner of the New Game sequence order.

• Created scr_new_game_flow_get() to return or create the New Game flow controller.

• Created scr_new_game_flow_start() to reset flowStep and enter OpeningCutscene.

• Created scr_new_game_flow_set_step() to route each flow step to its assigned room.

• Created scr_new_game_flow_advance() to move from OpeningCutscene to NarratorIntro, then CharacterSetup, OriginSelect, StorySetupCutscene, and Gameplay.

• Established that individual rooms should not decide the entire New Game sequence; the centralized flow controller owns the sequence.

• Used rm_game as a temporary placeholder target for CharacterSetup, OriginSelect, StorySetupCutscene, and Gameplay until those rooms/systems are built.

July 15, 2026: narrator identity, text box failure, and final working text box architecture

• Wanted the narrator identity to display as “???” until a specific future line reveals or contextualizes the narrator identity.

• Identified a visual flash / black hitch when narrator identity changed, suggesting rendering/transition responsibility needed a cleaner foundation.

• Re-emphasized that even simple systems like dialogue must be stable, optimized, reliable, and foundational, not workaround-based.

• Started implementing narrator intro dialogue in rm_narrator_intro via obj_narrator_intro_controller.

• Created narrator lines and used scr_textbox_start("Narrator", narratorLines).

• Created scr_input_confirm_pressed() for dialogue confirm input using Enter, Space, Z, E, left mouse, and gamepad gp_face1.

• Created scr_input_confirm_down() to detect held confirm input and prevent carried input from instantly advancing lines.

• Created scr_textbox_start() to create an obj_textbox_controller, support a string or array of strings, set textboxActive true, set textboxFinished false, set speakerName, store textLines, set lineIndex to 0, set currentLine, reset visibleCharacters, and establish input locks.

• Created scr_textbox_is_active() to report whether the text box is active.

• Created scr_textbox_is_finished() to report whether the current dialogue sequence completed.

• Created obj_textbox_controller Create Event to initialize textboxActive, textboxFinished, speakerName, textLines, lineIndex, currentLine, visibleCharacters, textSpeed, inputLockFrames, and waitingForConfirmRelease.

• Created obj_textbox_controller Step Event to handle typewriter progress, input lock, confirm-release gating, completing the current line, advancing to the next line, and ending the sequence.

• Attempted to draw the text box directly from obj_textbox_controller Draw GUI / Draw GUI End events.

• Observed black screen after New Game opening cutscene despite music playing correctly.

• Observed that the narrator room and/or diagnostic text could exist while the text box did not appear.

• Used diagnostic output to confirm the text box state could be active: textboxActive 1, textboxFinished 0, speakerName Narrator, currentLine set, and visibleCharacters advancing.

• Identified a serious pasted-code mistake where obj_textbox_controller Draw GUI contained Create Event initialization code rather than drawing code.

• Tried moving drawing into Draw GUI End to prevent draw-order covering, but this alone did not solve the final issue.

• Recognized that the architectural issue was not simply the border drawing code or room order.

• Tried a separate persistent obj_ui_controller to draw UI globally, but this still did not produce the needed visible text box in the narrator scene.

• Reached the successful architecture: obj_textbox_controller stores and advances dialogue state only; scr_textbox_draw() draws the active text box; obj_narrator_intro_controller Draw GUI draws the narrator background and calls scr_textbox_draw() last.

• Confirmed that this final solution displayed the text box correctly after the New Game opening cutscene.

• Removed or cleaned the white development text “Opening cutscene video could not be played” from the opening cutscene Draw GUI event.

• Established the protected lesson: scene controller owns scene/background drawing; obj_textbox_controller owns dialogue state and input; scr_textbox_draw() renders active dialogue; scene controller calls scr_textbox_draw() last.

July 15, 2026: working narrator text example and immediate text box result

• Custom narrator lines were tested: “Hello, and welcome to the world of Majuu-Majuu.”

• Custom narrator lines were tested: “Here on Earth, most human beings live in peace with the Majuu.”

• Custom narrator lines were tested: “When young boys and girls come of age, around 20 or so, they usually set off on adventure with the goal of becoming a Creature Tamer.”

• The text box is intended to appear across the bottom of the screen with a basic border and a white background so text remains readable.

• The visual target is close to Pokémon Diamond, Pearl, and Platinum / Generation IV dialogue-box style, while the current rendering is code-drawn and functional before later graphic polish.

• Confirmed that graphics or text-box images are not required for the basic working foundation; they can be added later for polish.

• Confirmed that the black-screen/no-textbox problem was not caused by room order.

• Confirmed that the final arrangement is reusable for narrator text, NPC dialogue, signs, item messages, prompts, and later UI dialogue.

July 15, 2026: comparison to Pokémon text systems and future text-engine roadmap

• Compared the working text box architecture to the general text-engine pattern used in early Pokémon generations: scene/script requests a message, text system stores and advances message state, a window/text renderer displays the box and characters, and scene resumes when the message finishes.

• Noted that Generation I and II used tile-based text boxes and tilemap rendering, while the GameMaker system uses Draw GUI and code-drawn rectangles/text.

• Noted that Generation III’s formal window/text-printer model is conceptually close to the final architecture, because it separates message data, text printer state, window ID/layout, and rendering.

• Noted that Generation IV is the primary visual target for proportions and presentation, especially Diamond/Pearl/Platinum style bottom text boxes.

• Identified future text-system features: automatic word wrapping by pixel width, scrolling two-line behavior, pause commands, sound commands, color commands, player-name insertion, choice menus, yes/no prompts, text speed options, different window skins, animated Gen IV-style border graphics, and message queueing.

• Separated the complete destination feature list from the practical implementation roadmap.

• Recommended not building every Pokémon-like text feature immediately before surrounding systems exist.

• Recommended Phase 2 soon: better Gen IV-style box proportions, automatic word wrapping, continue arrow animation, text speed variable, message queueing, reusable dialogue calls, and yes/no prompt foundation.

• Recommended later phases for choice boxes, color commands, sound commands, pause commands, player-name insertion, window skins, animated border graphics, sound ticks per character, and Options menu text speed/window style.

• Clarified that player-name insertion should wait until name entry/player profile exists.

• Clarified that window skins and text speed settings should wait until Options menu implementation.

• Clarified that choice menus and yes/no prompts become urgent before New Tamer setup, origin city selection, starter choice, save overwrite prompts, shops, and NPC decisions.

July 15, 2026: development-strategy feedback and personal working pattern analysis

• Analyzed the user’s project not merely as a Pokémon-like game but as an attempt to capture a specific emotional memory: late-night discovery, childhood wonder, animals in the backyard, family nostalgia, danger in the bushes, and something strange hidden off-screen.

• Identified the user’s strongest design anchor as discovery, creature fantasy, and memory rather than a mechanical checklist alone.

• Identified the user’s strongest development strengths: taste instincts, refusal to settle for weak presentation, recognition of architectural problems, constant testing, serious production mindset, and clear emotional direction.

• Identified the user’s major development risks: scope creep, trying to perfect future systems before present systems exist, debugging fatigue, copy/paste/event-placement complexity, and insufficient checkpoint discipline.

• Recommended splitting work into Creative Direction, Technical Foundation, and Production Scope.

• Recommended a next milestone of a single playable intro slice rather than the whole Generation 1–4 feature set.

• Defined a practical vertical slice: boot sequence, main menu, New Game cutscene, narrator text box, basic character setup placeholder, origin city selection placeholder, small starting room, player movement, one NPC, one sign, one item pickup, and one save test.

• Highlighted that the user’s unique identity should remain childhood discovery, animals, human story, hidden things, and the emotional reason for the adventure, not just imitating Pokémon mechanics.

July 15, 2026: ChatGPT Work continuation, structured dialogue, and title presentation

Session-continuity marker: the regular ChatGPT development conversation was archived and active development continued in ChatGPT Work. This v1.1 section records the post-archive work and supersedes any earlier paragraph that describes the former single-speaker dialogue model as the current implementation.

• Continuity objective: preserve prior design decisions, code ownership, debugging lessons, stable checkpoints, and the user’s foundation-first development requirement while moving to the Work-based chat.

• Quality requirement reaffirmed: compilation is the first validation gate, followed by runtime behavior, architectural review, regression testing, and avoidance of unnecessary per-frame work.

• Development rule reaffirmed: even simple systems such as dialogue must be reusable, stable, optimized, and reliable from the ground up; scene-specific workarounds are not acceptable foundations.

Stable narrator script checkpoint

The following introduction was compiled and runtime-tested as structured dialogue. Speaker identity is intentionally hidden through “I’m the director.” and changes on the next entry.

• ???: “...”

• ???: “Oh... hello!”

• ???: “It's nice to finally meet you! I'm glad you're here.”

• ???: “Hmmm? Yeah, YOU - I'm talking to YOU!”

• ???: “Good. Now that I've finally gotten your attention, introductions are in order.”

• ???: “Who am I?”

• ???: “Well, don't worry about that. It's unimportant for now.”

• ???: “...”

• ???: “Ugh, you really want to know? All will be revealed in due time.”

• ???: “...”

• ???: “If nothing else, you're remarkably tenacious.”

• ???: “Well, to ease your curiosity for now, let's just say...”

• ???: “I'm the director.”

• Director: “For now, don't worry so much about who I am.”

• Director: “We'll get to know me another time, when it's more appropriate.”

• Director: “When? Oh - after you've proven yourself, of course.”

• Director: “I'll let you know when that is, but for now, my new friend, you've got a long way to go.”

• Director: “Let me be the first to welcome you to the wonderful world of Majutori!”

Structured dialogue foundation and black-flash correction

• Syntax cleanup: replaced a smart opening quotation mark that GameMaker could not parse as a normal string delimiter, restored missing commas between array entries, and removed the trailing comma after the last entry.

• Paging foundation: added scr_textbox_build_pages() to wrap by measured pixel width and group the result into two-line pages before typewriter playback.

• Controller layout state now includes currentPages, pageIndex, currentPage, textboxTextWidth, textboxLinesPerPage = 2, font/layout values, typewriter state, and confirm-input protection.

• Speaker requirement: display “???” through “I’m the director.”, then display “Director” beginning with “For now, don’t worry so much about who I am.” and for all remaining entries.

• Rejected first approach: splitting the introduction into two independent text-box sequences changed the speaker but destroyed and recreated the controller at the handoff, producing a visible black flash.

• Root cause analysis: the flash was a lifecycle/ownership discontinuity, not a text-rendering effect. A continuous scene should not be reconstructed merely to change dialogue metadata.

• Created scr_dialogue_entry(_speakerName, _text) as the structured dialogue data contract, returning a struct with speaker and text fields.

• Created scr_dialogue_validate(_dialogueEntries) for one-time sequence validation before playback, keeping malformed-data detection out of the per-frame Step path.

• Created scr_textbox_load_entry(_controller, _entryIndex) to centralize entry loading, speaker assignment, page rebuilding, and page/typewriter reset behavior.

• Reworked scr_textbox_start(_dialogueEntries) to accept structured entries, reject a new request while dialogue is active, reuse an existing inactive controller, load the first entry, and return a direct controller reference or noone on failure.

• Reworked obj_textbox_controller to advance pageIndex first and entryIndex second, so a wrapped entry completes all prepared pages before the next speaker/text entry is loaded.

• Reworked obj_narrator_intro_controller to construct narratorDialogue from scr_dialogue_entry() calls and retain textboxController directly instead of repeatedly searching for an instance.

• Removed the temporary End Step / two-controller speaker-change workaround. The narrator scene, box, and controller now remain continuous while speaker metadata changes per entry.

• Optimization result: validation and word wrapping occur when a sequence or entry is loaded, not every Step; controller creation/destruction is avoided during a continuous sequence; the narrator flow uses a direct reference for completion checks.

Majutori title and BoldPixels integration

• Title decision: Majutori, pronounced “mah-joo-tor-ee,” became the official working game title; the temporary “(Codenamed) Majuu-Majuu” menu string was retired.

• Imported BoldPixels.ttf as the GameMaker Font asset fnt_title_main at 64 pt with bold, italic, anti-aliasing, and SDF disabled for a crisp pixel-title presentation.

• Updated obj_menu_controller Create Event to set gameTitle = “Majutori”, titleFont = fnt_title_main, and retain menuFont = -1 as a deliberate temporary menu-item font placeholder.

• Updated the Draw GUI Event to select titleFont and draw the title at the font asset’s native size rather than enlarging the default font with draw_text_transformed(). Existing flicker and rotating affinity-ring effects were preserved.

• Debugging lesson: the runtime error “Variable obj_menu_controller.titleFont not set before reading it” identified an uninitialized instance variable. The fix required titleFont = fnt_title_main in the Create Event and the font asset name to match exactly.

• Asset record: BoldPixels version 1.6; creator metadata YukiPixels; embedded source URL https://yukipixels.itch.io/boldpixels; embedded license CC BY-SA 4.0. Credit and final license-compliance review are required before release.

• A separate Majutori Asset Attribution Register was opened so third-party assets and future credit obligations can be tracked as development continues.

Post-change verification

• Dialogue verification: compilation stable; narrator identity changes at the required line; desired output achieved; no black flash at the speaker transition.

• Title verification: the title screen displays Majutori in fnt_title_main; compilation and runtime behavior confirmed stable; title flicker, ring animation, music startup, and menu layout remain functional.

• Checkpoint labels: Structured narrator dialogue stable. Speaker transition stable. Two-line page preparation stable. Majutori title-font integration stable.

ERA III / FRONT-END, INPUT, AND SAVE ARCHITECTURE / JULY 16–17, 2026

July 16, 2026: menu audio, title recovery, and centralized input

This section continues the ChatGPT Work development record after the v1.1 narrator/title checkpoint. Every completed stage below reached a stable compilation checkpoint; runtime checks are identified separately.

• Added snd_ui_cursor_move as the dedicated main-menu navigation sound and kept it separate from selection confirmation and cinematic-skip audio.

• Prepared and implemented a reverb-treated menu-confirmation prototype as snd_ui_menu_confirm. Confirm playback is tracked independently from snd_sfx_run, which remains the opening-cutscene skip/run effect.

• Reworked obj_menu_controller audio ownership so cursor sounds are stopped before replay during rapid navigation, selection confirmation uses its own tracked sound instance, and Quit to Desktop waits for confirmation audio or a bounded failsafe before closing.

• Recovered the correct Majutori title presentation after an accidental Draw GUI copy restored the obsolete code-name display. The working Create/Draw contract again uses gameTitle = "Majutori" and fnt_title_main.

• Filled the formerly blank scr_input_update foundation and created the on-demand persistent obj_input_controller, whose Begin Step event updates shared input state once per frame.

• Added scr_input_get_controller(), scr_input_menu_vertical_pressed(), and scr_input_cancel_pressed() so menus consume centralized intent rather than performing their own repeated keyboard/gamepad scans.

• Centralized menu navigation supports Up/Down, W/S, gamepad D-pad, and left stick input; opposing directions cancel, and held navigation uses an 18-frame initial delay with a 6-frame repeat interval at the fixed 60 FPS project rate.

• Kept confirm, held-confirm, and cinematic-skip semantics separate so Escape, Start, Back, and similar skip inputs cannot accidentally advance ordinary dialogue or confirm menu choices.

• Replaced obj_menu_controller's hard-coded vertical keyboard block with the shared menu-navigation result. Compilation remained stable and keyboard/controller input was reported to work as desired.

July 16, 2026: transactional three-slot save-system foundation

• Added SAVE_SCHEMA_VERSION, SAVE_SLOT_COUNT = 3, SAVE_SLOT_NONE, SaveSlotStatus, and SaveSelectMode to scr_globals as the public constants and enumerations for save persistence and slot-screen behavior.

• Created the on-demand persistent obj_save_controller. It owns activeSlot, activeData, saveSelectMode, cached slot status/summary/message arrays, an operation lock, cache readiness, and lastError diagnostics.

• Defined a versioned default-save schema containing metadata, Tamer identity, origin city selection stored under the existing origin field, New Game/story progression, location, party, inventory, and storage. Save data stores logical string identifiers rather than runtime asset handles.

• Implemented structural/type validation for all required save fields, slot ownership, non-negative playtime, schema compatibility, collection arrays, and recognized New Game flow identifiers.

• Implemented slot filenames, complete-file reading, slot recovery order, summary construction, cache refresh, active-save clearing, protected new-slot creation, and validated existing-slot loading.

• Implemented a protected write transaction: validate runtime data, serialize JSON, write a temporary file, read and validate that temporary file, preserve a valid primary as .bak or quarantine an invalid primary as .rejected, then rename the verified temporary file into the primary filename.

• Failed write transactions restore the previous updatedAt timestamp, attempt to restore the preserved primary, remove temporary debris, release the operation lock, and return false with a diagnostic instead of pretending the save succeeded.

• Loading from a valid temporary or backup recovery source heals it back into a verified primary file before that data becomes the active runtime save.

• The first persistence self-test exposed a GameMaker runtime inconsistency: file_text_close() reported failure on the readback handle even though the file had been read and could be deleted. The text-file path was not allowed to become a false-success workaround.

• Replaced complete-file text persistence with matched buffer APIs: buffer creation/string writing/buffer_save for writes and buffer_load/string reading/buffer deletion for reads. This preserved explicit resource cleanup and removed dependence on the inconsistent close result.

• Final diagnostic output: "[SAVE SYSTEM TEST] PASS: Save serialization and readback passed." The temporary self-test invocation was removed afterward, while scr_save_run_self_test() was retained as an opt-in diagnostic.

July 16, 2026: persistent New Game checkpoints and save-selection staging

• Audited all New Game transition callers with project-wide literal search after Feather Find Usages incorrectly returned zero references. The only external advance callers are obj_opening_cutscene_controller Step and obj_narrator_intro_controller Step; set-step calls remain centralized.

• Added scr_new_game_flow_step_to_id() and scr_new_game_flow_id_to_step() so saves use stable identifiers such as opening_cutscene and narrator_intro rather than enum numbers that could change when the enumeration is edited.

• Classified NewGameFlowStep.Inactive as runtime-only and removed it from the persistent identifier mapping; it cannot be accepted as a playable save checkpoint.

• Added scr_new_game_flow_checkpoint(). It validates the active slot/data, skips redundant disk writes when the desired checkpoint is already committed, writes changed progression transactionally, invalidates stale summary cache, and restores the prior in-memory step after failure.

• Extended obj_new_game_flow_controller with a centralized blocked-transition state, pending step, diagnostic message, carried-input protection, Retry handling, Cancel-to-menu recovery, and a Draw GUI save-error overlay.

• Refactored scr_new_game_flow_set_step(), start(), and advance() to return Boolean transition results. Room routing remains centralized and unsupported steps return false instead of silently mutating flow state.

• Centralized Introductions music synchronization by destination: it is ensured for NarratorIntro, CharacterSetup, and OriginSelect, and stopped for the opening cutscene and steps after origin city selection. This also supports loading directly into a middle setup step.

• Added scr_new_game_flow_resume_active() to validate the active save, translate its stored checkpoint, and enter that step through the same centralized flow router used by natural progression.

• Created rm_save_select and placed one non-persistent obj_save_select_controller instance in the room. The screen supports New Game and Load Game modes, three cached slot panels, preferred initial slot, entry-input locking, shared navigation, cancellation, and clear slot-state messages.

• Added scr_save_format_play_time() and a GUI-relative slot renderer showing slot number, Empty/Valid/Corrupt/Unsupported status, Tamer/setup state, origin city, playtime, recovery availability, and screen-level error/instruction text.

• Completed save-screen confirmation logic for protected new-slot creation or validated loading, prepared-slot retry without duplicate work, confirmation audio, and title-music shutdown only after slot activation and flow-transition acceptance.

• Staging safeguard: rm_save_select remains unreachable and the main menu still uses the previously working direct New Game route. The final checkpoint call, caller return handling, and menu reroute will be connected atomically rather than leaving an intermediate build with no active save slot.

Asset attribution and release-clearance updates

• BoldPixels/fnt_title_main remains governed by the previously recorded YukiPixels CC BY-SA 4.0 attribution and license-compliance requirement.

• snd_ui_cursor_move uses an independently created CC0 Pokémon-style recreation rather than extracted Pokémon audio. Preserve its exact source/creator/license metadata in the asset register even if attribution is not legally required.

• snd_ui_menu_confirm was derived for prototyping from a Dragon Ball Hoi-Poi Capsule activation recording and is not release-cleared merely by providing credit. It must be replaced with an original/licensed equivalent or separately licensed before any public or commercial build.

• The downloaded Pokémon Emerald sound archive remains internal reference/placeholder material only; extracted franchise audio is not the intended release asset path.

• Previously identified Pokémon/Crystal music and other franchise-derived cutscene/title placeholders remain subject to final replacement or documented licensing review. The end-of-development credits list must distinguish assets that require attribution from assets that are not legally cleared for release.

Post-change verification through the v1.2 pause point

• The save serialization/readback self-test passed after the buffer-based file foundation replaced the inconsistent text-close path.

• Centralized menu input compiled and was reported to behave as desired.

• Each save controller, schema, validator, transaction, cache, flow mapping, checkpoint helper, save-error UI, save-select controller, and flow-return refactor stage reached a stable compilation checkpoint.

• The existing direct Main Menu -> Opening Cutscene -> Narrator -> rm_game route was exercised after the Boolean flow refactor and appeared to retain the required behavior and Introductions music state.

• Checkpoint labels: Menu audio separation stable. Central input foundation stable. Save serialization transaction self-test passed. Save schema and slot cache stable. Flow serialization/resume foundation compiled. Save-selection screen staged and compiled. Final end-to-end slot integration pending.

July 16, 2026 continuation: completed save integration, deletion, and presentation redesign

This live continuation records verified work completed after the original v1.2 staging snapshot. Earlier staged statements remain in the document as historical context and are not the current implementation state.

• Completed the atomic Main Menu, save-selection, and New Game flow connection. New Game and Load Game now enter rm_save_select in their respective SaveSelectMode values instead of bypassing slot activation.

• Confirmed that title music remains active while moving from rm_menu into rm_save_select and stops only after a selected slot is successfully activated and the requested flow transition is accepted.

• Completed and exercised checkpoint-based New Game entry and saved-game resumption. Loading a save whose stored checkpoint is CharacterSetup correctly returns to the Tamer Registration screen rather than restarting the opening sequence.

• Added protected save deletion to both New Game and Load Game slot screens. Valid, corrupt, and unsupported occupied slots may request deletion; empty slots report that no data exists to remove.

• Deletion uses a dedicated confirmation state with No selected by default, a separate target-slot value, carried-input protection, Cancel handling, and a save-layer deletion function followed by cache/status refresh.

• The deletion confirmation remains vertically navigated and blocks all underlying save-slot input while active. Successful deletion clears any matching prepared/active runtime attachment without confusing that runtime state with committed slot data.

• Runtime tests for the integrated slot flow and deletion behavior were reported successful, with compilation stable at each checkpoint.

July 16, 2026 continuation: main-menu and save-screen presentation decisions

• The main menu now uses six entries in this order: New Game, Load Game, Multidimensional Storage, Mystery Gift, Settings, and Quit. Mystery Gift is a planned entry; Quit replaced the longer Quit to Desktop label.

• Added fnt_ui_main for menu and interface text using Pixelify Sans Medium at 24 px, character range 32–127, with anti-aliasing and SDF disabled. fnt_title_main/BoldPixels remains the Majutori title font.

• Both New Game and Load Game save screens are intentionally heading-free; screenTitle and screenInstruction remain initialized as empty strings while the active SaveSelectMode still determines slot behavior.

• Approved redesign direction: replace the three stacked horizontal slot bars with three tall side-by-side cards. Slot 1, Slot 2, and Slot 3 will be centered at the top of their respective cards, with all card information centered vertically beneath the heading.

• Approved empty-slot visual: the static ambiguous silhouette asset spr_save_silhouette_ambiguous, 128 by 192 pixels, with Middle Centre origin at 64,96. The save-screen Create Event references only this static sprite.

• Rejected and retired the experimental animated/shedding silhouette direction. No production code should reference spr_save_silhouette_ambiguous_shed or revive the discarded animation without a new deliberate art review.

• Selected Pixelorama as the primary zero-cost pixel-art and sprite-animation tool. Krita remains a secondary option for larger illustrations. Complex 2D animation is postponed until it is genuinely required and can be authored with adequate control.

• Planned card information includes a years/months/days/minutes/seconds playtime display, one Maju discovered/captured line, and 20 Battleground Badges arranged as two rows of ten beneath the proposed heading ~ Battleground Badges ~.

• The current save schema does not yet contain discovered-count, captured-count, or badge-ownership fields. These values must not be faked in the renderer; they require a controlled schema-version upgrade, validation, and migration plan after the visual shell is stable.

July 16, 2026 continuation: horizontal menu-input foundation

• Extended obj_input_controller with independent horizontal pressed, held, and repeat-frame state plus horizontal initial-delay and repeat-interval settings. The existing vertical and Cancel state remains intact.

• Replaced scr_input_update with a complete version that preserves vertical navigation and adds Left/Right, A/D, gamepad D-pad Left/Right, and left-stick horizontal-axis support. Opposing horizontal inputs cancel one another.

• Horizontal held navigation uses the same fixed-60-FPS behavior as the vertical foundation: an 18-frame initial delay and a 6-frame repeat interval.

• Added scr_input_menu_horizontal_pressed(), which exposes -1 for left, 1 for right, and 0 when no horizontal menu movement occurred during the frame.

• obj_input_controller Create, scr_input_update, and scr_input_menu_horizontal_pressed() are now connected to the save-selection Step Event. A runtime failure exposed that the actual input-controller Create Event still contained the older vertical-only initialization; after restoring the horizontal fields in the verified obj_input_controller asset, Left/Right and A/D slot navigation ran without the missing-variable crash.

Current live GameMaker checkpoint after the v1.2 snapshot

• Boot, logo, pre-title intro, main menu, slot selection, transactional save creation/loading/deletion, New Game opening cutscene, narrator dialogue, and Tamer Registration entry are established working foundations.

• obj_save_select_controller Create has been replaced as one complete Event and compiles with heading-free presentation state, fnt_ui_main card scales, static ambiguous-silhouette configuration, deletion state, slot-cache state, and interface audio intact.

• The save-selection Step Event now uses scr_input_menu_horizontal_pressed() for the three primary slots while retaining scr_input_menu_vertical_pressed() for the vertically arranged No/Yes deletion choices. Horizontal slot navigation has been runtime-tested successfully.

• The save-selection Draw GUI Event still renders the older stacked horizontal panels. Because the slot indices are drawn vertically, verified Left/Right input currently makes the highlight appear to move up and down. This expected visual mismatch will disappear when the renderer is replaced with three side-by-side vertical cards.

• Save-mechanics expansion is intentionally paused at this safe checkpoint while the save-screen presentation is redesigned. Existing transactional persistence and deletion behavior remain protected from visual changes.

Current implementation-instruction standard

• When one GameMaker Event or Script is being changed, provide one complete, uninterrupted replacement for that entire Event or Script rather than asking the user to find and splice several distant code fragments.

• Instructions should explicitly identify the asset and Event, say to use Select All before replacement, avoid ellipses inside production code, and end with a single compile checkpoint before the next change.

• This procedure supports accurate learning and reduces copy/paste risk in long 400–500-line Events, especially because the user has disclosed mild dyslexia and benefits from precise, low-ambiguity implementation steps.

Live asset and attribution notes after the initial v1.2 snapshot

• Pixelify Sans Medium/fnt_ui_main, the Jersey font variants, Press Start 2P, and all other imported font candidates must retain their source and license records for final release-credit review; selecting a font in GameMaker does not remove its license obligations.

• The static ambiguous silhouette is the only approved save-card silhouette. The separate Majutori Asset Attribution Register records the retired animation experiments so they are not accidentally treated as active production assets.

July 16–17, 2026 continuation: completed vertical save-card presentation

This live continuation supersedes the earlier renderer-staging notes as the current presentation state while leaving those earlier entries intact as a record of how the implementation was reached.

• Replaced the former stacked horizontal save bars with three tall, side-by-side save cards. Slot 1, Slot 2, and Slot 3 are centered at the top of their respective cards, and the card contents follow a centered vertical layout.

• Both New Game and Load Game use the heading-free card presentation. Their shared appearance does not alter SaveSelectMode; the selected mode still controls whether an empty slot is created or an existing valid slot is loaded.

• Confirmed the static ambiguous silhouette as the sole active save-card figure. The discarded shedding-pixel animation direction remains retired; complex sprite animation will be authored later in Pixelorama only when a production feature genuinely requires it.

• Added progressive playtime presentation with six possible units: years, months, days, hours, minutes, and seconds. Seconds are always visible, while each longer unit remains hidden until the accumulated playtime reaches that unit.

• Added the current encyclopedia placeholders on one centered line as Maju discovered: -- | Maju captured: --. These remain honest presentation placeholders until the save schema gains validated discovery and capture fields.

• Added the centered heading ~ Battleground Badges ~ and a twenty-position badge display arranged as two rows of ten neutral grey circles. Affinity color activation, badge art, trophy rotation, and ownership data remain future systems rather than renderer guesses.

• Horizontal card selection now matches the three-column layout. The earlier runtime mismatch—horizontal input moving a highlight through vertically drawn rows—was eliminated when the completed card renderer replaced the staged layout.

• The user supplied runtime screenshots of the completed three-card screen and confirmed that compilation and behavior were working correctly.

July 16–17, 2026 continuation: three-stage deletion safety and control prompts

• Reordered the deletion choices so Yes - Delete Save appears above No. The No label was simplified, and Yes is the initial selection by deliberate design rather than relying on a default-No safety position.

• Replaced immediate deletion with a three-press confirmation sequence. The first and second Yes confirmations escalate the warning state; the third Yes confirmation performs the protected save deletion.

• Cancel/Back is reversible at every stage. When the warning is escalated, Cancel steps backward by one warning level; at the initial level, Cancel closes the deletion modal without touching the save.

• Split the warning into two centered lines—This save will be permanently deleted. and (This cannot be undone!)—to prevent border overlap and improve the escalation rhythm.

• Finalized restrained warning scales of 1.00, 1.10, and 1.20 instead of doubling the text on every confirmation. Each stage also uses a clearly stronger red treatment.

• Replaced the final warning's pale/white letter outline with a dark-crimson outline so the strongest stage remains urgent without abandoning the red visual language established by the first two stages.

• Added a reusable contextual Back prompt at the bottom of the modal. The keyboard presentation uses separate Esc and Backspace keycaps followed by = Back; the Backspace keycap was widened and spacing was refined for visual legibility.

• Introduced reusable device-aware prompt support for keyboard/mouse, Xbox, PlayStation, Steam Deck, and generic gamepad layouts. Gamepad B/Circle-style cancel input and established keyboard/mouse cancel inputs feed the same logical Back action.

• The contextual button/keycap graphics are procedural interface drawings, so they add no external icon-credit requirement. They are intended for reuse throughout the Main Menu and its submenus where navigation help is useful.

• Extracted the expanding deletion-modal presentation into reusable drawing helpers, including the modal renderer and outlined warning-text support, so the save-selection Draw GUI Event does not have to own every visual detail inline.

• Planned but not yet implemented: two siren-style escalation sounds, with the second warning using the same source at a higher pitch. Audio should be connected only after the final sound asset and its rights status are known.

• The user approved the resulting deletion presentation. Before additional save-mechanics expansion, the current visual and input checkpoint should still receive one complete compile-and-runtime regression sweep.

July 17, 2026: development-workflow feedback request and assessment

The user explicitly requested a candid rating of the current development workflow and then asked that both the request and the assessment be retained in this worklog.

• Overall assessment for the current solo, AI-assisted development stage: 8.3/10. The workflow is unusually deliberate about foundations, testing, presentation quality, and durable continuity for an early project.

• Category ratings: creative direction 9/10; iteration 9/10; runtime verification 8/10; foundational thinking 9/10; documentation 9/10; process accessibility 8/10; change control 7/10; code organization 7.5/10; automated testing 5.5/10.

• Greatest strength: the user works as both director and hands-on tester, judging whether a system functions and whether it communicates the intended feeling. This has produced strong iterative visual and usability decisions.

• Greatest risk: manual state drift—editing the wrong GameMaker Event, retaining an older Event version, or treating a compile/launch check as a full runtime feature test. Earlier input-controller crashes demonstrated this risk clearly.

• Current commercial-production readiness was assessed at approximately 6.5–7/10. The design and foundation discipline are strong; version control, repeatable regression testing, and modular maintenance practices must mature as the project grows.

• Recommended process upgrade: establish Git/version-control checkpoints with small descriptive commits before and after each stable system or visual revision.

• Recommended test vocabulary: report compile, launch, runtime path, and desired output as distinct checkpoints rather than using compilation alone as proof of behavior.

• Recommended regression practice: maintain short reusable checklists for boot flow, Main Menu input, save creation/load/deletion, checkpoint resume, Cancel behavior, and audio cleanup; later add a dedicated test room and automated smoke tests.

• Recommended architecture practice: freeze requirements for one controlled implementation pass, then refactor repeated UI/input/modal drawing after the behavior is stable instead of mixing redesign and cleanup indefinitely.

• Preserved user preference: large complete Event or Script replacements are acceptable when they reduce copy/paste ambiguity. Do not shrink code merely to appear concise or sacrifice correctness; finer optimization and clutter reduction can occur deliberately nearer the final build.

Current live checkpoint and next controlled work

• Protected working foundation: three-slot transactional persistence; New Game/Load Game routing; horizontal three-card selection; static silhouette; progressive playtime text; encyclopedia/badge placeholders; occupied-slot deletion; reversible three-stage deletion safety; and reusable contextual Back prompts.

• Immediate regression test: exercise New Game and Load Game with empty and occupied cards; move through all three cards with keyboard and gamepad; escalate and reverse every deletion stage; delete a test slot; verify cache refresh, Cancel behavior, title music, and save-file recovery guarantees.

• Next data milestone after the visual shell is locked: design a controlled save-schema upgrade for Maju discovered, Maju captured, and twenty badge ownership values, including validation, migration, summary caching, and tests for existing saves.

• Next presentation milestone: connect real Tamer appearance data to valid save cards only after CharacterSetup persists that identity; empty cards continue using the approved ambiguous silhouette.

ERA IV / REGION, MOVEMENT, CAMERA, AND MULTIPLAYER DIRECTION / JULY 17–18, 2026

July 17, 2026: regional geography and world-structure foundation review

The user completed an extensive review lasting more than two hours to establish the foundational geography, progression, route, Battleground, Field Move, and multiplayer-access rules that will guide Majutori world development. This section records the approved direction, the ideas explicitly rejected, and the unresolved systems that must remain open.

Regional identity and physical geography

• The unnamed region is now planned as a large volcanic island centered on a massive ancient caldera and active volcano.

• The volcano's eruption and potential region-wide destruction are major shared story pillars for every origin city.

• The coastal visual direction may draw from Mediterranean and Greek-island environments, especially Corfu, while the inland visual direction remains open.

• Scientific grounding analysis concluded that the island does not need to be continent-sized. A working scale of approximately 8,000 to 15,000 square kilometers, roughly 100 to 160 kilometers at its longest dimension, can support twenty principal cities, towns, and villages plus large wilderness areas.

• A high central summit, provisionally 3,500 to 4,500 meters, can support elevation-based climate transitions, seasonal snow, cold caves, rain shadows, wet windward areas, dry leeward areas, volcanic terrain, rivers, forests, and distinct microclimates.

• Low-elevation permanent glaciers are not the preferred scientific solution for Ice environments. High-elevation snowfields, shaded ice caverns, frost pockets, and Maju-influenced microhabitats are more credible.

• The central Heartwild concept is approved. It surrounds the upper mountain, caldera, and parts of the volcano and is not a twenty-first city, town, or village.

• The Heartwild contains regional water sources, old Maju migration corridors, Mythical Maju habitats, ancient ruins, late-game story areas, and special passages into and out of the endgame region.

• The Majutori League is planned near the mountain summit and requires traversal through the Heartwild after all twenty Battleground Mogul Badges are earned.

• A cable-car area inspired by the Mt. Chimney cable car is planned near the central mountain as a later story-critical special area rather than a principal populated location, and it may also provide a controlled form of regional transit.

Twenty principal locations and the origin city selection system

• The collective word settlement is not approved for routine use. Current writing should say city, town, village, location, or the full phrase cities, towns, and villages as appropriate.

• There are exactly twenty principal cities, towns, and villages, one associated with each Affinity.

• Ten are selectable origin cities. The other ten are reached through regional travel and are generally associated with more demanding middle-to-high-level areas.

• Origin city is a functional term for any of the ten principal cities, towns, or villages selectable as a new Tamer starting point. It does not identify a separate physical, cultural, governmental, or progression class; Monarch Village remains a village while also functioning as an origin city.

• The additional ten locations are not a shared legacy, dormant, derelict, ruined, or reclamation class. Some may be prosperous, modern, small, rural, isolated, industrial, or otherwise individually defined.

• Every principal city, town, and village contains a Tamer Battleground, an Affinity-specific Battleground Mogul, a Medical Lab, and an item-purchasing service.

• The item-purchasing service is mandatory, but its physical form remains undecided: it may be a separate Item Store or a sales counter inside a Medical Lab.

• Every origin city contains the player's starting apartment, a Maju Research facility, and an applicable Maju Researcher who provides the PDA and assists with first-Maju selection.

• Monarch Village is confirmed as one of the ten origin cities and as the Insect-affiliated location. It retains its identity and scale as a village and honors the user's grandmother and her love of butterflies.

• Approved Monarch Village environmental foundations include woodland edges, orchards, streams, protected migration corridors, docile pollinating Maju, and burrowing Maju.

• The ten origin cities must remain equivalently viable through balanced early resources, core services, capture opportunities, first-Badge difficulty, and progression potential.

• Origin cities may differ through local NPCs, unique quests, first-route identity, and early Maju availability. The relationship system is deferred until near the end of development and is not currently a world-structure dependency.

Opening and first-Badge access flow

• The major opening cutscene, narrator sequence, character setup, and central regional conflict remain shared by every Tamer.

• After origin city selection, each origin city receives a short hometown-specific overworld introduction near or inside the starting apartment.

• Each local introduction includes a different Affinity-associated Maju behaving in a quirky, ambient, or disruptive manner. These scenes provide local flavor without changing the main plot.

• The new Tamer then meets the local Maju Researcher, receives the PDA, chooses the first Maju, and learns the catching, battling, exploration, gathering, and cooperative foundations.

• The routes immediately outside the selected origin city are accessible at the beginning.

• The Tamer cannot pass into another principal city, town, or village until the Battleground Badge from the selected origin city is earned.

• The working boundary presentation uses two-story route gatehouses with guards, observation areas or binoculars, and a holographic airline-departure-board-style display that communicates Battle Bands and access requirements.

• After the first Badge, broader travel opens subject to geography, Battle Bands, transit, story-state flags, Badge Count, and Badge Identity.

• A provisional access experiment may test additional inland tiers around five, ten, and fifteen Badges, while retaining multiple viable destinations at each stage. No exact thresholds are locked.

• All twenty Badges are required for full Heartwild and Majutori League access.

Route graph, movement, obstacles, weather, and transit

• The earlier topological-wheel phrase was clarified as a developer-facing node-and-connection graph, not a visibly circular continent. Because wheel geometry is not approved, the term and its implied spokes are retired.

• The preserved principle is that the player should perceive a natural island while the development team perceives a deliberately engineered connectivity graph.

• Geographic pairings between origin cities and interior cities are explicitly rejected and must not be reintroduced.

• Routes should form multiple intersecting paths rather than a single linear sequence, but they must not be forced into a circular structure.

• Four-direction grid movement remains the current prototype baseline. A later statement reopened the possibility of changing movement, so the final movement system is not yet permanently locked.

• World and route designs must remain compatible with the active grid prototype while avoiding assumptions that would make a later approved movement revision impossible.

• Each principal city, town, or village may have one to four direct route or transit connections according to geography and game flow.

• The ten origin cities are generally easier outer or coastal locations, while the additional ten are generally more inland, elevated, or difficult to reach. This is a difficulty gradient rather than a perfect ring or rigid order.

• Approved route families include shoreline trails, ferry crossings, forest roads, open plains, elevated bridges, caravan paths, canyon routes, caves, ruins, farms, preserves, tunnels, and coastal passages.

• Harder alternative routes may provide restrained shortcuts or direct connections. Shortcuts must be monitored carefully so the final map becomes familiar and convenient without becoming overconnected.

• Approximately thirty to thirty-four direct inter-location links may be tested as a planning range, but no fixed thirty-link formula is approved.

• Every major route should contain multiple Maju possibilities and eventually receive a data table with species, conditions, and appearance percentages.

• Base Maju locations are authored and stable. Swarms and migrations are deferred future systems.

• Most Maju captures occur outside populated locations through grass, terrain events, visible encounters, fishing, or other later approved methods. Trades, gifts, Eggs, and rare scripted town encounters remain exceptions.

• Normal Tamer battles must be sought out and do not use a lock-eyes mechanic. Scripted battles remain deliberate event-specific exceptions.

• Ordinary Tamers cannot serve as invisible route obstacles. Alternative obstacles may use terrain, Maju behavior, weather, technology, checkpoints, story events, transit restrictions, or Field Move interactions.

• Routes should have a clear primary path, restrained branches, points of interest, multiple habitats, and return value through gatherables, crafting materials, held items, fishing, quests, or later access conditions.

• Not every route requires a literal loop or a far-side shortcut. Linear bridges, tunnels, mountain paths, causeways, and a possible bicycling route remain valid.

• A constant regional weather system is planned to remain active throughout the game, but weather simulation and gameplay effects require a separate design pass.

• Transit concepts inspired by the S.S. Aqua and Magnet Train may reopen ferries, lifts, rail systems, and other connections as the game progresses. Transit must supplement sound geography rather than repair a weak map.

Affinity influence and Maju ecology

• Affinity should influence the world primarily through the Maju that inhabit an area rather than by turning every city or route into a literal type-themed environment.

• Naturally occurring Affinities may guide broad environmental design when realistic, including Water, Ice, Grass, Insect, Arachnid, Rock, Earth, Fire, Electric, Poison, and Aerial relationships.

• Less naturally environmental Affinities should usually appear through individual Maju, ruins, local technology, folklore, culture, or isolated mysterious phenomena.

• The desired tone is a believable normal world on the surface with a mysterious underlying relationship between Maju, Affinities, history, and the volcano.

• Most Maju remain docile and easily influenced. Hazards should usually result from instinct, ecological scale, disrupted migration, fear, altered habitat, human influence, or volcanic instability rather than inherent evil.

Field Move foundation and Technique Imprints

• Field Moves remain a working system rather than a final lock, but a Maju may currently retain up to five Combat Moves and two separate Field Moves.

• Field Moves occupy their own slots and never overwrite the five Combat Move slots.

• Field Moves may be learned through leveling, Maju Researchers, quests, or instructional items.

• Technique Imprints is the current working replacement name for TM/HM-style instructional items, with provisional Combat Imprint and Field Imprint categories.

• Mandatory Field Move access cannot depend on one exact Maju species or multiple human players.

• Field Moves should improve exploration and route interaction without compensating for poor world connectivity.

• Twenty provisional Affinity concepts were recorded: Ambiguous/Forage Sense; Aerial/Gale Lift; Combat/Heave; Fire/Kindle; Water/Current Ride; Ice/Frostspan; Grass/Vineway; Insect/Pollenwake; Arachnid/Webline; Rock/Stone Anchor; Earth/Burrow Path; Electric/Jumpstart; Poison/Neutralize; Drake/Resonant Roar; Psionic/Teleport; Spectral/Spirit Sight; Metal/Magnetize; Umbral/Shadecloak; Sprite/Glimmerguide; Cyber/Protocol Link.

• Frostspan is the approved working Ice concept for designated lava-related traversal. It creates an insulating crystalline route over approved superheated ground or cooled lava crust and does not unrealistically freeze fresh exposed molten lava.

• All Field Move names, animations, Maju eligibility rules, obstacle types, and balance implications remain provisional until movement and route prototypes exist.

Battleground organization, Battle Bands, and Mogul rules

• Battlegrounds are approved as broader multiplayer anchors rather than simple boss chambers.

• The working internal layout places multiplayer social functions, gathering, and Battle Requests on the first floor.

• Standard Battleground Tamer challenges and the Battleground Mogul are placed on the second floor.

• The standard NPC layout may rearrange according to an active party of one, two, three, or four players so local challenges can support the corresponding formats.

• The campaign Mogul challenge remains a solo one-versus-one Tamer experience even when the player entered the Battleground with a cooperative party.

• Mogul Affinity identity, tactical roles, and Maju party selections remain predetermined.

• Difficulty should use authored Mogul challenge tiers informed by Badge Count, local Battle Band, and an approved range around the challenger's team rather than unrestricted exact one-to-one level mirroring.

• Each Battleground Mogul requires a balanced introductory tier when encountered as the player's first Mogul so no origin city is objectively superior.

• Later challenge should derive from AI, team structure, move selection, held items, format rules, roster depth, and levels together.

• Mogul rematches with alternate rules and formats are retained as a major future Battleground feature.

• Private simulated battles between real Tamers may occur while in a party and normally award no experience. Battleground versions may later use different backgrounds, music, and tentative spectator functionality.

Multiplayer world-access boundaries and personal progression

• The full campaign and every required route must remain completable alone. Multiplayer is optional and should be accessible through the PDA.

• The exact online/offline switch behavior is deferred. A future transition may reposition players to a validated safe point when session state changes.

• No critical route may require multiple human players.

• Each Tamer retains individual quest-state flags, story-state flags, Badge Count, Badge Identity, item-pickup state, route discoveries, and exploration records.

• Quest-state flag is the technical term confirmed for a stored value that records an individual Tamer's quest or event state.

• Joining another Tamer may not reveal unexplored routes, satisfy travel objectives, collect waypoints, complete personal story progress, or grant access to locked areas.

• Rally Travel and related rendezvous mechanics are shelved for now. Any future implementation must validate that every participant has already unlocked the destination.

• If a participant disconnects, battle composition and interaction requirements must adjust at a safe transition, and the remaining players must retain all legitimate progress already earned.

• Further multiplayer geography brainstorming is paused until the movement system and base route prototypes are better defined.

Rejected structures and contradiction resolutions

• Rejected: using settlement as the routine collective term for cities, towns, and villages.

• Rejected: Legacy Settlement, Dormant Legacy Settlement, derelict-town class, and a reclamation phase shared by the additional ten locations.

• Rejected: geographic pairing of each origin city with one interior town.

• Rejected: a wheel, spoke, belt, circular route, or fixed outer/inward/inner network formula.

• Rejected: a mandatory thirty-link network. Thirty to thirty-four remains only a testable planning range.

• Rejected: every destination requiring a literal route loop or every route requiring a far-side shortcut.

• Rejected: different versions of the central conflict for different origin cities. The volcanic catastrophe remains shared.

• Rejected: using ordinary lock-eyes Tamer battles as routine route gates.

• Rejected: mandatory multiplayer route objectives.

• Rejected: generic Mythical Maju investigations triggered by combinations of paired routes or completed reaches. Each Mythical Maju receives individual rules and story relevance.

• Resolved contradiction: the early review reiterated grid movement, while a later note reopened free-direction possibilities. Grid movement remains the current prototype, not an irreversible world-design law.

• Resolved contradiction: item service is mandatory in every principal location, while a separate Item Store building remains optional.

• Resolved contradiction: every origin city shares the main cutscene and conflict but may include a small hometown-specific overworld scene.

• Resolved contradiction: Moguls scale for sustained challenge while preserving predetermined parties through authored tiers rather than unconstrained exact mirroring.

• Resolved contradiction: the completed map should reduce excessive backtracking, but not every destination must be embedded in a literal loop.

Mandatory document-preservation and update protocol

• The Majutori Information Sheet and ChatGPT-Assisted Development Log are cumulative protected master documents.

• Future updates must begin from the latest user-approved original or working version and add material to the applicable existing sections.

• Existing text formatting, page setup, paragraph styles, tables, photographs, image placement, headers, footers, and document identity must remain intact unless the user explicitly requests a redesign or full rework.

• Do not replace either document with a newly styled summary, condensed successor, reformatted template, or structurally redesigned edition merely because the user uses words such as rework when discussing the game design itself.

• Reorganization means moving or inserting information within the protected format, not replacing the document's visual design.

• Optimization means correcting contradictions, reducing duplication where safe, improving placement, and adding clear current-state notes without deleting historical information or altering unrelated presentation.

• Always create a new versioned copy and retain the prior file untouched.

• A generated successor draft previously changed the documents' formatting and omitted the original revised table and photographs from its visible structure. That approach was rejected. The original files remained available, so the information and media were recoverable and were used as the protected base for this corrected update.

• Before delivery, every revised DOCX must be rendered and visually inspected page by page to confirm that the original table, photographs, formatting, and added sections remain intact.

Current live GameMaker checkpoint after the geography review

• The geography and documentation review does not replace the active coding milestone.

• obj_character_setup_controller remains the owner of CharacterSetup in rm_character_setup.

• CharacterSetupStage currently contains NameEntry, AppearanceSelect, Confirmation, Complete, and Error.

• The object currently has Create and Draw GUI Events but no Step Event.

• Draft name and appearance selections must remain transactional until final confirmation and a successful save commit.

• The next controlled CharacterSetup milestone remains NameEntry implementation and validation.

• The Save Select vertical-card presentation, progressive playtime display, reversible three-stage deletion safety, and contextual input prompts remain protected stable foundations.

• The proposed Text Box visual redesign remains a reversible renderer/presentation experiment. The protected ownership architecture remains: scene controller draws the scene, obj_textbox_controller owns state, and scr_textbox_draw renders last.

• No regional movement, Field Move, weather, multiplayer-travel, or world-map implementation should begin until its prerequisites are deliberately selected and the current small coding milestone is completed.

Open world-design follow-up items

• Choose a final collective development term, if desired, for the twenty principal cities, towns, and villages without using settlement.

• Determine the final movement system before detailed multiplayer route geometry is locked.

• Prototype one origin city, one first-Badge gatehouse, and one inland access route before designing the full island map.

• Test Badge Count, Badge Identity, Battle Bands, and authored Mogul challenge tiers together.

• Decide whether Item Stores are separate buildings or Medical Lab counters.

• Determine whether Technique Imprints remains the instructional-item name.

• Prototype Frostspan and at least two non-Ice Field Moves before approving the full twenty-move roster.

• Design the central cable-car area, Heartwild boundaries, and League approach only after the lower-island route graph is stable.

• Return later to constant weather, Maju migrations and swarms, breeding sanctuaries, Mythical Maju requirements, Rally Travel, and spectator features.

• Design and name the twenty cities, towns, and villages only after the regional terrain and route graph provide each location with a distinct identity.

Stable checkpoint: regional foundation recorded

• The volcanic-island regional identity, twenty-location origin city structure, central Heartwild, first-Badge gatehouse rule, solo-completion requirement, individual progression ownership, and rejection of paired/wheel/legacy structures are now documented as the current foundation.

• The regional design remains intentionally incomplete at the map level. The next world-design work should proceed through controlled route and terrain prototypes rather than immediately naming all twenty locations.

• The two protected master documents have been restored to their original visual formats and updated through additions and targeted corrections rather than full reformatting.

Revision notes for v1.3 of this log

• v1.2 preserves the complete v1.1 regular-ChatGPT and early Work history while adding the July 16 menu audio, shared input, save persistence, flow checkpoint, and save-selection development record.

• v1.2 records the verified save-system self-test PASS and the reason matched buffer APIs replaced the unreliable text-close readback path.

• v1.2 updates the current object/script responsibility inventories so scr_input_update is no longer described as blank and the new persistent/input/save/selection controllers are not omitted.

• v1.2 records stable string-based New Game checkpoints, rollback-safe checkpoint writing, saved-step resumption, centralized music synchronization, and dormant transition failure handling.

• v1.2 preserves the original compiled-but-unreachable rm_save_select note as historical staging context and follows it with the completed end-to-end menu/save/flow connection.

• v1.2 expands the asset record to distinguish BoldPixels attribution, the CC0 cursor recreation, and the non-release-cleared Dragon Ball-derived confirmation prototype and franchise audio placeholders.

• The latest v1.2 continuation records the vertical save-card renderer, progressive playtime presentation, reversible three-stage deletion confirmation, contextual control prompts, and the July 17 workflow assessment. The next major record should follow either the save-schema metadata upgrade or the next stable CharacterSetup checkpoint.

• v1.3 preserves every v1.2 chronological entry and the original worklog formatting, then adds the complete July 17 regional world-structure review.

• v1.3 records the volcanic-island caldera, central Heartwild, twenty-Badge League access, ten origin cities, ten additional travel-reached locations, and the rejection of Legacy, dormant, paired-town, reclamation, and wheel-based structures.

• v1.3 adds the first-Badge gatehouse rule, provisional inland access tiers, Battle Band and authored Mogul-tier integration, route and transit constraints, and the complete provisional twenty-Affinity Field Move roster.

• v1.3 records solo-completion, personal quest-state ownership, no multiplayer access bypass, drop-out safeguards, the two-floor Battleground concept, and solo campaign Mogul battles.

• v1.3 establishes the permanent document-preservation protocol: additions and targeted corrections only, original formatting and embedded media protected, prior versions retained, and visual render verification required before delivery.

• The next active coding milestone remains CharacterSetup NameEntry; detailed world-map implementation is not the immediate programming task.

July 17, 2026 continuation: origin city terminology and protected-document synchronization

The user reviewed and manually revised the formatting-preserved Information Sheet and Development Log, then requested a complete terminology and consistency pass without changing either document’s protected visual structure. This continuation records those corrections and preserves the active coding checkpoint.

Terminology and consistency corrections

• Standardized origin city as the human-facing functional term for all ten selectable starting locations throughout the Information Sheet and Development Log.

• An origin city may retain an individual identity as a city, town, or village. The label indicates only that a new player Tamer may begin there; it does not create a separate category of populated location.

• Replaced the former standalone capitalized label and inconsistent starting-location phrases wherever they described the world-design concept rather than a technical identifier.

• Updated related wording for origin city selection, first-Badge access, local introductions, route availability, replayability, regional balance, Mogul challenge tiers, and Monarch Village.

• Existing GameMaker identifiers such as NewGameFlowStep.OriginSelect and the current save-schema field origin remain unchanged. Renaming those identifiers would require a separate coordinated code and schema migration rather than a documentation-only replacement.

• The Information Sheet now consistently reflects Majutori as the official working title; current prose no longer describes the game itself as unnamed, while historical code-name entries remain preserved in the chronological log.

• The current staff listing remains user-controlled: Alesha Ortiz is omitted, while Zuri Fisher and Josef Izquierdo are recorded as pending in their listed development roles.

• The central cable-car special area remains story-critical and may also function as a controlled regional transit method.

Protected-document verification and current development state

• Both updates were made from the latest user-edited formatting-preserved files. Existing formatting, page setup, tables, embedded photographs, and historical sections remain protected.

• The prior versions remain untouched; these revisions are new versioned copies rather than replacements of the user’s source files.

• The active GameMaker milestone remains CharacterSetup NameEntry under obj_character_setup_controller in rm_character_setup. This documentation pass does not authorize movement, world-map, Field Move, weather, or multiplayer-travel implementation.

• The protected dialogue, save-selection, save-persistence, input, deletion-safety, and contextual-prompt foundations remain unchanged by this terminology update.

• Stable checkpoint: origin city terminology synchronized; user-edited staffing and title status synchronized; cable-car transit clarification recorded; protected document formatting retained.

Revision notes for v1.4 of this log

• v1.4 preserves every v1.3 chronological entry and the original worklog presentation while incorporating the user’s latest manual edits and terminology decisions.

• v1.4 standardizes origin city throughout human-readable design prose and explicitly defines it as a starting-point function rather than a special class of city, town, or village.

• v1.4 preserves current technical identifiers including OriginSelect and the save-schema field origin until a deliberate code-migration decision is made.

• v1.4 synchronizes the official Majutori title, current pending staff-role wording, central cable-car transit function, and current CharacterSetup checkpoint.

• Information Sheet v2.0 and Development Log v1.4 remain protected cumulative master documents requiring additions, targeted corrections, retained prior versions, and visual render verification.

July 18, 2026: movement-system, world-representation, and technological benchmark reanalysis

The user supplied the earlier Pokémon Legends: Z-A technology comparison, reopened selected movement questions that had initially been shelved, provided a forest tileset for a concrete tree-collision example, and requested a combined reanalysis plus synchronized updates to both protected master documents. No GameMaker movement code was changed during this documentation pass.

Scope reconciliation and supersession

• The earlier benchmark conversation originally shelved movement implementation, 3D-background selection, camera design, rendering architecture, and all material beyond the replacement technological-superiority comparison.

• The present conversation deliberately reopened movement and world-representation planning. Only the concepts expressly discussed and accepted here move back into active design consideration.

• Detailed hybrid-2.5D production architecture, true elevation, advanced camera behavior, experimental-runtime migration, and complete 3D conversion remain shelved or exploratory rather than approved.

• The July 17 four-direction grid baseline is superseded as current direction but preserved as historical context. The final movement system is still not formally locked.

• Current design priority is fluidity, complete control, systemic environmental interaction, and reliable cross-platform behavior rather than reproducing nostalgic tile-step restrictions.

Approved planning principles for future movement brainstorming

• Use clearly tuned locomotion modes rather than an enormous analog-speed continuum: Walking, Running, terrain-modified movement, and later Riding, Swimming, or comparable traversal states.

• Preserve minimal acceleration and near-immediate stopping during ordinary walking and running. Reserve stronger momentum for ice, wind, knockback, bicycles, currents, downhill travel, moving transport, or Maju-assisted traversal.

• Normalize diagonal speed and maintain analog, keyboard, D-pad, and controller parity under the same simulation rules.

• Prioritize a continuous, responsive movement foundation. The leading candidate combines 360-degree analog direction and eight-direction digital input, but this remains a prototype target rather than final approval.

• Separate movement intention, desired velocity, resolved velocity, facing, aiming, interaction direction, surface, possible world height, movement state, and traversal state so later systems do not force one direction variable to own every behavior.

• Keep movement mechanically consistent across rendering frame rates and platform quality tiers.

• Keep the final Walk/Run input method, directional animation count, and animation blending model open for prototype comparison.

Collision resolution, foot colliders, and the supplied tree reference

• Collision should represent ground-plane physical occupation, not the complete visible sprite. The player and most ground-based Maju should use compact bottom-center foot colliders.

• Collision should resolve motion through wall sliding, corner correction, doorway tolerance, incremental or swept checks, and safe overlap correction rather than simply cancelling all movement.

• The large tree near the bottom of the supplied forest tileset became the reference case. Its broad canopy should not behave as a full rectangular obstacle because the physical trunk and root base occupy only a small part of its visible area.

• The tree collider should be a simplified rounded footprint around the solid trunk and substantial roots. The shadow and canopy should normally remain non-solid.

• The player should be able to use nearly all believable space behind and beneath the canopy while remaining unable to cross the trunk footprint.

• The tree needs a depth pivot near the root base and an independent canopy occlusion region. Depth order, collision, and transparency are separate responsibilities.

• Early prototype behavior may fade the whole tree. The preferred production treatment separates the upper canopy/upper trunk from the lower trunk and roots so the occluding portion fades while the physical base remains readable.

• Pixel-art-compatible alternatives may later include dithered transparency, a local cutaway, or player silhouette rendering.

• Player visibility and hidden-content discovery remain separate. Fading a tree for the local player must not automatically reveal a hidden Maju, item, or special Tamer.

• Maju concealment may later use proximity, approach angle, line of sight, rustling foliage, sound, scanning, movement, weather, time, or species-specific behavior.

Terrain material and traversal reanalysis

• Terrain should modify one shared locomotion controller rather than create unrelated movement engines for every surface.

• A data-driven surface may define speed, acceleration, stopping, traction, footsteps, particles, tracks, noise, visibility, temperature, hazards, weather response, bicycle compatibility, swimming depth, and later-approved properties.

• Grass can affect rustling, concealment, tracks, noise, and species behavior. Mud can affect turning, footprints, sprite accumulation, splash, and attraction or alarm.

• Ice can reduce traction and extend stopping while retaining limited steering. Shallow water can use depth, wakes, ripples, currents, audio, and Maju reactions.

• Slopes may later affect speed, animation, bicycles, wind exposure, rolling objects, and water flow if a height-aware model is approved.

• Traversal should remain expressive but deliberate; contextual vaults, ledge drops, climbing, swimming, bicycles, ferries, lifts, cable cars, gliding, and Maju assistance should exist because routes support them, not because every action game has them.

• Field Moves may later alter the shared terrain/traversal simulation rather than functioning only as environmental keys. Their exact design remains provisional.

Contextual soft-grid and interaction hooks

• The soft grid remains useful as optional assistance and authoring structure, not as a general movement restriction.

• Potential assisted interactions include doors, stairs, fishing points, Field Move targets, ledges, terminals, furniture, transit, and narrow bridges.

• Interaction targeting should consider facing, approach direction, distance, line of sight, obstruction, object priority, and anchor reachability rather than distance alone.

• A temporary Interaction Align state could briefly suspend ordinary input, move to a safe nearby anchor, correct facing, validate collision, and begin the interaction.

• The targeting and alignment ideas are retained as useful architecture hooks. Their strength, frequency, and final feel remain unresolved pending movement prototyping.

• Assistance must never make free movement feel constantly magnetized.

Layered world-representation conclusion

• The user found selecting one pure replacement for the internal grid unnecessarily difficult because rendering, collision, terrain, interactions, AI, encounters, route connectivity, and networking do not require one shared representation.

• Visual tilemaps remain efficient for repeated ground and scenery art without requiring tile-step locomotion.

• Placed instances and simplified shapes are preferred for tree trunks, rocks, ruins, furniture, machinery, bridges, and irregular physical obstacles.

• Tagged tiles and polygonal regions may jointly describe terrain, habitats, weather influence, encounter areas, soundscapes, settlement boundaries, camera zones, and no-spawn spaces.

• Interaction anchors should own doors, conversations, fishing, gathering, Field Moves, transitions, transit, and cutscene positions.

• NPC and Maju movement may begin with waypoints, path graphs, and local steering. A navigation mesh is deferred until behavior proves it necessary.

• The region remains a graph of locations, routes, entrances, and transit links, independent from exact continuous coordinates.

• Spatial chunks, hashes, or lookup cells may organize loading, nearby-entity searches, simulation, and networking without becoming visible movement cells.

• Recommended composite model: tile-assisted visual authoring, shape-based collision, region-based terrain, anchor-based interaction, waypoint/graph AI, regional route graphs, and chunk-based spatial organization.

• Gameplay simulation and rendering should remain separable so movement logic can survive an eventual enhanced-2D or hybrid-2.5D choice.

Multiplayer and possible MMORPG implications

• The active approved scope remains one-to-four-player optional drop-in/drop-out co-operation with complete solo viability and personal progression ownership.

• Player bodies should not be fully solid. The likely direction is soft separation in open areas and pass-through behavior where hard collision could block doors, routes, or other players.

• Tree and foreground-object transparency should be evaluated locally so remote or crowded players do not cause constant global fading.

• Movement state should remain explicit and serializable for later replication: position, direction, mode, traversal, surface, facing or aim, animation, and interaction.

• Simplified deterministic colliders, continuous coordinates, interpolation, spatially limited nearby-entity searches, and client-local occlusion remain compatible with later server-authoritative testing.

• A full MMORPG mode is not a larger four-player lobby. It would require authoritative servers, accounts, persistent databases, interest management, prediction/correction, security, moderation, disconnect recovery, deployment, and live operations.

• MMO compatibility should influence obvious foundational choices without authorizing full live-service scope during the current movement milestone.

Visual technology and 2.5D status

• Enhanced 2D, hybrid 2.5D, and complete 3D remain possible visual directions.

• Hybrid 2.5D remains an attractive exploratory option for the caldera, volcano, bridges, tunnels, slopes, cable cars, waterways, and elevated League, but it is not approved.

• The previously proposed true-elevation, advanced-camera, animation, renderer, and isolated 2.5D prototype plans remain shelved until a deliberate visual-technology review.

• The current movement reanalysis approves renderer-independent architecture principles only and does not authorize migrating the active project to an experimental 3D runtime.

• The stable menu, dialogue, save, input, CharacterSetup, and New Game flow systems should remain independent from any future renderer choice.

• Visual superiority is not defined by polygon count. Advanced 2D may compete through animation, lighting, normal maps, parallax, particles, water, weather, coherent art direction, environmental interaction, and consistent performance.

• Cross-platform quality tiers may scale shadows, lighting, foliage, water, weather, resolution, and post-processing while leaving simulation and gameplay unchanged.

Pokémon Legends: Z-A benchmark combination

• The supplied July 2026 comparison records Z-A as the stronger functioning benchmark because Majutori is still building foundations, while Majutori's projected complete-game scope is broader in regional structure, Origins, Moguls, Maju development, co-operative campaign integration, route agency, and replayability.

• The Z-A working loop was summarized as daytime catching/research/training/resources, nighttime battle/rank progression, major Rogue Mega encounters, collection, side missions, ranked battles, trading, rare hunting, and later endgame content.

• Majutori's projected loop was summarized as Origin selection, first partner and Badge, regional route choice, habitats and communities, catching/training/trading/breeding/battling/quests/co-operation, twenty Moguls, Heartwild, League, collection, rematches, alternate rules, competition, and another-Origin replay.

• The Information Sheet now contains a twenty-objective comparison/evidence chart covering movement, terrain, traversal, ecology, capture, battle breadth, multiplayer, progression, Maju development, replayability, animation, visuals, world cohesion, platforms, accessibility, persistence, competitive longevity, permanent content, narrative personalization, and quality density.

• The comparison is an internal planning framework, not a public superiority claim. All external Z-A facts and comparisons require fresh verification before publication.

• Strategic definition: Majutori should not pursue every benchmark feature plus more. It should pursue coherent higher standards in the areas that reinforce discovery, exploration, relationships, player agency, long-term return value, and technical reliability.

Unresolved decisions and implementation safeguards

• Final movement model remains unresolved despite the continuous 360-degree candidate becoming the leading direction.

• Final Walk/Run controls, interaction assistance, directional animation count, camera model, true elevation, final renderer, Maju navigation, capture integration, and battle integration remain open.

• The active GameMaker coding milestone remains CharacterSetup NameEntry under obj_character_setup_controller in rm_character_setup.

• This documentation pass does not authorize replacing the current player code, rebuilding rooms, implementing 2.5D, beginning multiplayer networking, or creating an MMO backend.

• Movement implementation should begin later through an isolated prototype containing continuous input, foot collision, one reference tree, wall sliding, occlusion fading, several terrain surfaces, one interaction anchor, one roaming Maju, and a multiplayer-spacing simulation.

• Existing protected save, dialogue, input, menu, deletion, CharacterSetup, and New Game flow foundations remain unchanged.

Stable checkpoint: combined movement and benchmark planning recorded

• Leading movement direction recorded without falsely marking it final.

• Responsive locomotion, discrete modes, terrain, foot collision, wall sliding, corner correction, depth sorting, local occlusion, tree concealment, layered world data, nonblocking players, and future networking compatibility recorded.

• Enhanced 2D, hybrid 2.5D, complete 3D, and MMORPG operation correctly separated into later feasibility decisions.

• Information Sheet v2.1 and Development Log v1.5 remain cumulative protected master documents; source files remain untouched.

Revision notes for v1.5 of this log

• v1.5 preserves every v1.4 chronological entry and the original worklog presentation while adding the complete July 18 movement, tree-collision, terrain, world-representation, visual-technology, benchmark, and MMO-scope reanalysis.

• v1.5 records that strict tile-step movement is historical rather than the preferred baseline, while avoiding a false claim that the final movement controller has been approved.

• v1.5 records the supplied forest-tree example as the reference case for realistic footprint collision and local occlusion transparency.

• v1.5 records the layered hybrid world-authoring conclusion rather than forcing every subsystem into one internal grid.

• v1.5 records the twenty technological-development objectives and proof standards added to Information Sheet v2.1.

• v1.5 preserves the current CharacterSetup coding checkpoint and explicitly prevents this planning review from becoming premature movement, 2.5D, networking, or MMO implementation.

July 18, 2026: approved 3D-diorama camera, billboarding, and unified multiplayer objective

The user supplied a complete follow-up design conversation, confirmed a strong preference for a rotatable 3D-diorama presentation, elevated directional billboarding to a critical system, selected a sixteen-direction target for Tamers and Maju, required camera-complete exterior construction wherever practical, clarified contained interior camera freedom, and permanently limited local split-screen to two vertically stacked widescreen viewports. This session updated both protected master documents; no GameMaker code or rooms were changed.

Design status superseding the earlier v1.5 feasibility wording

• The previous v1.5 record correctly preserved hybrid 2.5D, true elevation, advanced camera behavior, and final directional animation as unresolved or shelved at that time.

• The user has now approved a clearer long-term identity: Majutori is a genuine three-dimensional diorama world expressed through a predominantly hand-animated two-dimensional art language.

• This is more specific than a conventional 2D game with 3D backgrounds. Terrain, elevation, architecture, collision, navigation, interiors, and physical world arrangement are three-dimensional; Tamers, Maju, important NPCs, vegetation, props, effects, and decorative details remain 2D sprites wherever convincing.

• Approval of the direction does not authorize an immediate project-wide renderer migration. The active milestone remains CharacterSetup NameEntry, and later camera/movement work must begin in an isolated prototype while preserving stable menu, dialogue, save, input, and flow systems.

Close Orbit View objective

• The immediate camera priority is the close exploration view, provisionally named Close Orbit View. The future expanded aerial or major zoom mode remains separate and later.

• The camera is a player-centered orbit around a raised focus point, not a detached free-flying camera.

• Horizontal orbit supports continuous 360-degree control. Vertical pitch remains freely adjustable only within safe environment-specific limits. Roll remains fixed at zero.

• Eight world-aligned snap angles are separated by 45 degrees. A snap command first aligns to the nearest principal angle and then advances one angle per additional command.

• A dedicated recenter action returns behind the Tamer's movement or facing direction.

• Restrained perspective with an initial field-of-view test around 35-45 degrees and an initial pitch test around 25-30 through 60-65 degrees was recorded as provisional, not locked.

• Manual camera input always overrides automatic following. Automatic follow must remain subtle, configurable, delayed after manual input, and incapable of fighting deliberate player inspection.

Camera-relative freeform movement relationship

• Freeform movement remains the approved companion system. Inputs are interpreted relative to the local camera and then resolved in world space.

• The system reads camera-forward and camera-right vectors, removes vertical pitch, combines them with player input, normalizes the result, and resolves movement through collision and terrain.

• Camera pitch may never change movement speed, and camera rotation may never physically rotate the Tamer.

• Camera yaw, movement direction, world-facing direction, interaction direction, aim direction, and target direction remain separate state values.

• Earlier approved responsive-control rules remain active: tuned Walk/Run and traversal modes, minimal ordinary acceleration, near-immediate stopping, normalized direction, terrain modifiers, foot-based collision, wall sliding, corner correction, and nonblocking cooperative players where needed.

Directional billboarding elevated to a critical foundation

• Majutori will use cylindrical directional billboarding. A sprite plane rotates around the vertical axis to face each local camera while staying upright as pitch changes.

• Artwork selection depends on the relative difference between entity world-facing direction and local camera yaw.

• Tamers, Maju, and important NPCs target sixteen visual directions. Sixteen sectors represent 22.5-degree intervals; the eight camera snap positions remain a separate 45-degree system.

• Directional hysteresis is required to prevent neighboring-frame flicker near sector boundaries.

• One eight-frame action across sixteen directions requires 128 frames before clothing, equipment, terrain, or traversal variants. Production will require animation tiers, controlled mirroring, distance-based simplification, and careful scope management.

• Full sixteen-direction artwork is the target for player Tamers, Maju, Moguls, and important NPCs. Common NPCs may use controlled mirroring only where design symmetry permits; asymmetrical markings, equipment, injuries, horns, tails, and clothing may prevent mirroring.

Visual construction reference

• Strong 2D-sprite candidates: Tamers, Maju, NPCs, grass clusters, flowers, small plants, bushes, decorative rocks, signs, lamps, small furniture, item pickups, particles, weather effects, painted surface detail, some tree canopies, and distant layers.

• Strong 3D-construction candidates: ground surfaces, hills, slopes, cliffs, building shells, interior walls, roofs, bridges, stairs, platforms, caves, doors, entryways, tunnels, large tree trunks, collision-critical rocks, water planes, roads, rails, docks, cable-car structures, and any object that must remain credible from every camera angle.

• Hybrid objects combine simplified 3D structure with layered sprite artwork. Trees remain the reference: a 3D trunk defines volume and collision; sprite planes form branches and leaves; the canopy responds to the camera; a dynamic shadow anchors the tree; foreground foliage fades locally; and the trunk continues to constrain both player and camera.

• Additional hybrid candidates include 3D lamp posts with sprite light effects, 3D building shells with sprite signs and vines, simplified 3D rocks with painted overlays, 3D cliffs with sprite waterfalls, 3D caves with sprite mist and crystals, and simple 3D vehicles with sprite passengers and effects.

Camera-complete exterior environments

• Exterior environments should use camera-complete geometry wherever practical. Buildings need credible backs and sides; roads and rooflines must connect visibly; cliffs and props cannot depend on one fixed camera; and important landmarks should orient the player from multiple viewpoints.

• The bounded island format makes this workload more controllable than an unrestricted continental world. Coastlines, surrounding water, ocean horizons, mountain formations, the central volcano, caldera walls, distant fog, offshore scenery, and authored landmarks provide natural boundaries and controlled sightlines.

• Camera-complete construction requires visual credibility from every permitted angle, not equal detail at every distance. Incomplete backs, exposed voids, unfinished world edges, and impossible geometry must remain hidden or be fully constructed.

Contained interior camera freedom

• The user prefers contrast rather than a universal locked/fixed interior camera: outdoors should feel expansive and freely inspectable; interiors should feel intimate, contained, and compositionally controlled.

• Each interior defines a comfortable operating volume. Horizontal rotation remains available through the widest practical arc, while pitch, orbit distance, and certain rearward angles may be gently constrained.

• Interior cameras should retract near walls, remain inside the room, fade or hide intervening walls, remove ceilings or roofs, preserve chosen yaw where possible, temporarily raise pitch in narrow spaces, restore prior settings after obstruction, and avoid abrupt snapping unless no usable alternative exists.

• Large halls may permit nearly complete rotation. Corridors may use a closer and higher camera. Small bedrooms may shorten the boom, raise pitch, and narrow rearward arcs.

• Room dimensions must be authored for both the player collider and the physical needs of the orbital camera.

Desired and actual camera positions

• The desired position is calculated from player-selected yaw, pitch, distance, focus point, and camera-zone limits.

• The actual position is calculated after testing walls, cliffs, ceilings, terrain, building shells, large solid objects, and room boundaries.

• When obstructed, the actual camera moves toward the player or shifts safely, never passes through geometry, never abruptly teleports, may increase pitch slightly, and returns smoothly after clearance.

• Solid walls, cliffs, ceilings, roofs, and large trunks physically constrain the camera. Tree leaves and lightweight foreground layers may fade. Grass, flowers, particles, and minor decorative sprites should normally be ignored for camera collision.

Occlusion, line of sight, and gameplay revelation

• Three states are now distinguished: rendered, physically visible, and gameplay revealed.

• Camera rotation must not reveal Maju, players, or interiors through buildings, solid cliffs, closed doors, unexplored spaces, concealment systems, ambush logic, or competitive obstacles.

• Interior camera restrictions reduce accidental exposure but do not replace line-of-sight tests, room and portal state, occluder classifications, concealment state, network interest rules, or separate cosmetic-fading and gameplay-reveal logic.

• This distinction is especially important for hidden wild Maju, stealth, ambush behavior, player-versus-player encounters, instanced interiors, and a possible future densely populated online mode.

Unified local split-screen and online cooperative architecture

• Split-screen, cooperative campaign play, and online play are one unified multiplayer system rather than unrelated modes.

• Local split-screen is permanently limited to a maximum of two players. The approved widescreen presentation uses a horizontal divider: Player One receives the full-width upper viewport and Player Two receives the full-width lower viewport.

• Every local Tamer receives an independent orbital camera, camera controls, UI, occlusion, cutaway state, accessibility state, and local directional-sprite selection.

• Two local Tamers may participate together offline where supported or join remote Tamers within the overall one-to-four-player cooperative session limit.

• Camera yaw, pitch, distance, obstruction response, cutaways, faded foliage, camera shake, and accessibility settings remain local presentation data.

• Position, world-facing direction, movement, interaction, targeting, animation, traversal, quest-relevant actions, and relevant Maju/NPC state remain synchronized authoritative world data.

• Three-player and four-player local split-screen are permanently outside the Majutori objective and must not be proposed again.

Implementation safeguards and next prototype gates

• The active GameMaker coding milestone remains CharacterSetup NameEntry under obj_character_setup_controller in rm_character_setup.

• This documentation pass does not authorize replacing current player code, rebuilding rooms, migrating the renderer, implementing split-screen, beginning network replication, or creating an MMORPG backend.

• The future isolated camera/movement prototype should prove: sixteen-direction sprites remain convincing throughout continuous rotation; the pitch range preserves the diorama illusion; repeated 45-degree snaps retain comfortable camera-relative control; interiors support contained rotation; tree and wall occlusion behave smoothly; and one/two-view rendering remains performant.

• Stable save, dialogue, input, menu, deletion, CharacterSetup, and New Game flow architecture remains protected and renderer-independent.

Stable checkpoint: 3D-diorama camera and unified multiplayer direction recorded

• Genuine 3D diorama world with predominantly hand-animated 2D presentation approved as the long-term visual identity.

• Close Orbit View, continuous yaw, context-sensitive pitch, fixed roll, eight snap angles, recentering, manual-input priority, and desired/actual camera positions recorded.

• Cylindrical sixteen-direction billboarding recorded as a critical production requirement.

• Camera-complete exterior construction, hybrid objects, contained interior freedom, smooth camera collision, cutaways, and gameplay-visibility separation recorded.

• Local split-screen permanently limited to two vertically stacked full-width viewports and integrated with the same one-to-four-player online cooperative architecture.

• No implementation work authorized; current CharacterSetup checkpoint preserved.

Revision notes for v1.6 of this log

• v1.6 preserves every v1.5 chronological entry, layout, formatting, and historical decision state while adding the complete July 18 camera, diorama, directional-billboarding, visibility, and unified multiplayer objective.

• v1.6 explicitly supersedes the earlier current-status wording that treated hybrid 2.5D, true elevation, advanced camera behavior, and final directional count only as shelved or unresolved possibilities.

• v1.6 records sixteen sprite directions and eight camera snap angles as separate systems.

• v1.6 records the permanent maximum of two local split-screen players in a vertically stacked full-width widescreen format and prohibits future three-player or four-player local split-screen proposals.

• v1.6 retains MMORPG operation as an exploratory feasibility track and prevents it from expanding the current milestone.

• Information Sheet v2.2 and Development Log v1.6 remain cumulative protected master documents; future updates must begin from these latest user-approved versions.

ERA V / AFFINITY PROCESSION AND VISUAL-EFFECTS RESEARCH / JULY 18–20, 2026

July 18-20, 2026: Main Menu Affinity Procession, hybrid orb renderer, and orbital-layout evaluation

The user temporarily redirected the active implementation focus from CharacterSetup NameEntry to a protected Main Menu visual-development checkpoint. The work established a reusable hybrid 3D/2D Affinity-orb architecture, completed first-pass manifestations for all twenty Affinities, and tested several orbital arrangements before reaffirming the original single-procession composition as the strongest canonical direction.

Main Menu visual checkpoint and protected presentation rules

• The Main Menu now uses a flat deep-charcoal background, plain Majutori title typography, dark polygonal navigation buttons, a twenty-Affinity gradient inside the selected option, and a restrained Affinity-color footer.

• The Main Menu presentation intentionally excludes the former glass treatment, vignette, selection arrows, Affinity acronyms, and duplicate procession.

• The user entered a critical design checkpoint and directed that no unrequested visual changes be made to the Main Menu. Size adjustments to existing assets and objects are permitted only when explicitly requested.

• The selected menu option retains its complete twenty-color Affinity gradient. The title, menu geometry, background, footer, spacing, and current visual language remain protected unless the user authorizes a change.

• The twenty-Affinity display order remains: Ambiguous, Metal, Spectral, Drake, Umbral, Arachnid, Poison, Psionic, Sprite, Combat, Fire, Earth, Rock, Electric, Insect, Grass, Cyber, Ice, Aerial, and Water.

Hybrid three-dimensional sphere and two-dimensional manifestation architecture

• The Affinity Procession now uses one reusable shared UV-sphere mesh/vertex buffer rather than separate sphere geometry for every Affinity.

• Each complete orb unit is layered as: rear procedural manifestation or rear asset, illuminated 3D sphere core, foreground procedural manifestation or front/composite asset, and future Affinity logo/decal.

• The shared sphere core is intentionally asset-ready. Professional transparent artwork can later override procedural manifestations without replacing the procession or sphere renderer.

• The current data model supports logoSprite, logoSubimage, logoScale, rearManifestationSprite, rearManifestationScale, rearManifestationRotationSpeed, frontManifestationSprite, frontManifestationScale, frontManifestationRotationSpeed, compositeManifestationSprite, and related optional fields.

• Specialized future 3D attachments remain optional for Affinities such as Rock, Ice, Metal, or Drake; the common shared sphere remains the default proxy.

• The shader asset shd_affinity_sphere and the renderer scripts scr_affinity_sphere_renderer_create, scr_affinity_sphere_renderer_destroy, scr_affinity_sphere_renderer_begin, scr_affinity_sphere_renderer_draw, and scr_affinity_sphere_renderer_end form the reusable 3D core.

• scr_ui_draw_affinity_asset_layers and scr_ui_draw_affinity_procession_layer own the 2D/3D composition and title-depth relationship.

Three-dimensional sphere debugging and stability milestones

• An early asset-type error occurred when scr_affinity_sphere_renderer_create was accidentally created as a Shader asset. The renderer was corrected by restoring it as a Script asset.

• The GUI-space vertical coordinate required reflection for the 3D world projection: the world Y position is derived from display_get_gui_height() minus the GUI-space state Y.

• Psychedelic internal self-overlap was resolved by enabling hidden-face culling and selecting the outward shell with gpu_set_cullmode(cull_counterclockwise).

• The corrected spheres retain visible roundness, highlight, rim lighting, proper outward-facing surfaces, and no recurring internal-overlap artifact.

• The animation phase was moved to a seamless 36,000-degree master cycle through scr_affinity_animation_phase_wrap, preventing synchronized visible resets when fractional motion multipliers are used.

• User-supplied recordings showed no obvious recurrence of the palette crash, focus-loss reset, sphere-culling failure, or synchronized animation jump during the tested Main Menu cycles.

Complete twenty-Affinity manifestation coverage

• Four procedural prototype-family scripts now provide first-pass exterior manifestations for all twenty Affinities.

• Set 1 covers Fire, Water, Ice, and Grass; Set 2 covers Aerial, Combat, Earth, and Electric; Set 3 covers Rock, Insect, Arachnid, and Poison; Set 4 covers Ambiguous, Metal, Spectral, Drake, Umbral, Psionic, Sprite, and Cyber.

• The central scr_ui_draw_affinity_manifestation_dispatch script provides one stable rear/front interface to all four families.

• The most immediately successful visual identities in the recorded tests included Electric, Arachnid, Ice, Drake, Umbral, Sprite, and Cyber.

• The current procedural art is a development scaffold rather than final production artwork. It proves the renderer, silhouette, motion, and asset-layering requirements while professional manifestation assets remain pending.

• The main visual risk identified after full coverage is excessive reuse of sphere-plus-circular-halo motion language. Fire/Combat/Earth/Rock, several purple Affinities, and several pale-blue Affinities still require a deliberate differentiation pass.

Depth-correct complete-orb compositing

• The former global pass order drew every rear manifestation, then every 3D sphere, then every foreground manifestation. This allowed a farther orb’s foreground artwork to appear over a nearer sphere.

• scr_ui_draw_affinity_procession_layer was restructured so each Affinity is treated as one complete unit: rear manifestation, rear asset, sphere core, foreground manifestation, front/composite asset, and logo/decal.

• Complete units are sorted from farthest to nearest within the title-depth half. Rear-half units render behind Majutori; front-half units render in front of Majutori.

• This preserves physically coherent overlap between neighboring orbs and ensures later professional assets inherit the same depth behavior.

• The per-orb 3D begin/end approach increases state switching but kept the geometry shared. User recordings did not show an obvious new hitch during the tested cycles.

Affinity-specific manifestation motion, scale, and cadence

• scr_affinity_manifestation_motion_phase_get converts the shared manifestation phase into an Affinity-specific behavioral cadence before dispatch.

• Motion profiles distinguish material and metaphysical behavior: Electric is rapid and unstable; Rock and Ice are nearly rigid; Spectral and Umbral drift or counter-rotate; Cyber advances in quantized steps; Psionic remains controlled; Insect is restless; Drake is slow and weighty.

• The approved complete-orb scale was increased from a base radius of 23 to 34.5, an exact 1.5× multiplier. The 3D core, manifestations, future assets, and future decals scale together.

• A 2.0× test was considered but not adopted. The 1.5× result improved readability and presence without overwhelming the title or screen boundaries.

• The procession master orbit speed was later reduced by half, from an average 0.255 degrees per frame to 0.1275 degrees per frame with proportionally reduced variation. Manifestation speed and precession remained energetic.

• The exact single-procession target geometry remains centered at 50 percent of GUI width and 18.5 percent of GUI height, with approximate radii of 35.5 percent GUI width and 14 percent GUI height.

Nested concentric and gyroscopic layout experiments

• A four-ring nested experiment divided the twenty Affinities into four groups of five and placed them on concentric coplanar ellipses.

• The concentric version was visually interesting but read as four crowded horizontal lanes rather than a unified orbital sculpture. Dense left/right clusters weakened the title hierarchy.

• A second experiment extended scr_ui_affinity_procession_states_get with fixed yaw and roll inputs and created scr_ui_affinity_gimbal_procession_states_get for four intersecting gyroscopic planes.

• The gimbal version used shared title-centered pivoting, restrained radius differences, alternating rotation directions, and global depth sorting across all twenty complete units.

• The gimbal result was judged suitable as a possible alternative-title-screen Easter egg but too visually busy for the default Main Menu.

• The user reaffirmed the original single twenty-Affinity procession as the strongest canonical presentation. The actual code reversion was intentionally paused at the time of this backup, so the experimental gimbal implementation may still be the live local state until the user resumes the rollback.

• scr_ui_affinity_nested_procession_states_get is obsolete. scr_ui_affinity_gimbal_procession_states_get may be retained dormant for future Easter-egg testing rather than treated as the canonical path.

Additional Affinity and creature-development research

• Combat Affinity visual research selected the kanji 武 as the strongest authentic martial emblem candidate. The current concept places a partially transparent 武 behind the Combat orb as a unique visual privilege not shared by the other Affinities.

• The Combat, Fire, and Drake color relationships were reviewed to improve separation. Final production artwork and exact mythology-derived Drake treatment remain subject to controlled approval rather than automatic renderer changes.

• Fire-starter creature research explored real animals with direct fire relationships, including Australian firehawk reports and the black kite as a potential biological inspiration. No final fire-starter evolutionary line is locked.

• A possible third Tamer gender/presentation option using the internal term androgynous was explored. Symbol choice and final narrative/UI treatment remain open and should not be recorded as fully implemented.

Development workflow and protected-code rule

• For Majutori coding changes, every coordinated modification must be delivered as a complete paste-ready Script asset or full object-event replacement.

• Partial patches, isolated replacement lines, and “find this and add below it” instructions are prohibited unless a full replacement is genuinely unsafe or impractical and the exception is explained.

• Current exact source blocks should be requested before sensitive rewrites when memory is insufficient, particularly for menu input, audio, save flow, and transition logic.

• Visual feedback recordings are treated as implementation evidence. The user repeatedly supplied video checkpoints to judge scale, pacing, depth, clutter, and title readability before continuing.

Stable checkpoint and next controlled tasks

• Stable renderer checkpoint: shared illuminated 3D sphere core, complete-unit depth compositing, full twenty-Affinity procedural coverage, individualized motion, 1.5× scale, and half-speed master orbit have all been implemented or approved through iterative visual review.

• Canonical composition decision: one twenty-Affinity procession remains the preferred default title-screen arrangement; nested and gimbal variants are noncanonical experiments.

• Immediate paused action: revert the live gimbal Draw GUI path back to the approved single-procession call while preserving the gimbal helper as an optional dormant experiment.

• After the canonical layout is restored, perform one deliberate differentiation pass focusing on unique silhouettes, material-specific motion grammar, reduced halo repetition, Poison bubble refinement, and clearer warm/purple/pale-blue separation.

• Professional transparent manifestation art and Affinity logo/decal assets remain future art-production tasks. The renderer is prepared to accept them without replacing the shared architecture.

• CharacterSetup NameEntry remains a protected pending milestone and should resume after the Main Menu checkpoint is formally locked and documented.

Revision notes for v1.7 of this log

• v1.7 preserves every v1.6 chronological entry, page setup, footer identity, paragraph formatting, and protected historical content.

• v1.7 records the complete July 18-20 Main Menu Affinity Procession renderer milestone, including successful technical fixes, visual evaluation, rejected layout experiments, and the current canonical preference.

• v1.7 distinguishes approved architecture from temporary procedural art and distinguishes the preferred single-procession target from the still-unreverted local gimbal experiment.

• Information Sheet v2.3 and Development Log v1.7 are new versioned backups. The prior v2.2 and v1.6 files remain untouched protected masters.

July 20, 2026: Main Menu chat migration, error record, and architectural enforcement

Errors and rejected actions from the prior chat

• The prior chat violated the established code-delivery rule by creating or offering downloadable .gml files even though Majutori production code must be provided directly in chat unless Curtis explicitly requests a file.

• File delivery was not a harmless presentation difference. It weakened reviewability, made the response diverge from the required paste-ready workflow, and risked allowing an unverified asset to replace the user’s actual current canonical source.

• The prior chat attempted to introduce scr_ui_draw_affinity_manifestation_warm_refinement. This would have created a parallel refinement layer instead of changing the canonical manifestation-family Script that already owned Fire, Combat, Earth, and Rock behavior.

• The prior chat also attempted to modify the central dispatcher so it would intercept Fire, Combat, Earth, or Rock and route them through the new refinement Script. That approach violated the existing dispatcher boundary and would have introduced bypass behavior and duplicate ownership.

• The proposed refinement and dispatcher interception were rejected. scr_ui_draw_affinity_manifestation_warm_refinement must not be created, and the dispatcher must not be altered to intercept those Affinities.

Root causes and production risks

• The core failure was architectural: the response treated a local visual revision as permission to create a new ownership path rather than first identifying and editing the existing canonical owner.

• A secondary failure was continuity: the prior response did not sufficiently anchor itself to the user’s exact latest installed source before proposing a sensitive rewrite.

• Parallel scripts, override branches, compatibility shims, dispatcher exceptions, and duplicate visual ownership increase regression risk, obscure which asset is authoritative, and make later debugging and removal substantially harder.

• Reconstructing or modifying a sensitive Script from an older generated copy can silently remove user-installed changes, approved visual tuning, helper behavior, asset overrides, or draw-state restoration even when the new code appears plausible.

• These errors directly threaten the foundation-first production method. Repetition would accumulate technical debt and could compromise the wider Majutori vision rather than merely affecting one visual effect.

New-chat migration and recovery action

• Development was deliberately migrated to a new chat to restore a clean architectural contract and prevent the rejected implementation from becoming the assumed canonical state.

• The migration brief restated the unified twenty-Affinity procession, approved 1.5× complete-orb scale, half-speed master orbit, individual manifestation motion profiles, complete-orb depth compositing, and the protected title, buttons, background, selected gradient, footer, procession dimensions, and placement.

• The concentric-ring Main Menu remains rejected. The gimbal experiment remains noncanonical and may exist only as a dormant possible future Easter egg.

• The migration brief explicitly prohibited downloadable GML delivery, warm-refinement Script creation, dispatcher interception, workarounds, bypasses, compatibility shims, parallel implementations, and duplicate ownership.

Binding architectural adherence rule

• Curtis reiterated that there is absolutely no room for intentional breaking of Majutori’s development and design rules because doing so would compromise the project’s broader vision.

• Going forward, ChatGPT must follow the binding development and design rules as often and as strictly as possible unless Curtis explicitly authorizes a particular exception.

• No rule may be intentionally ignored, diluted, reinterpreted, or circumvented for convenience, speed, novelty, experimentation, reduced code length, or an assumed improvement.

• Code must be delivered directly in chat. Downloadable .gml files are prohibited unless explicitly requested.

• Every code change must be one complete, uninterrupted, paste-ready replacement for the canonical Script, Object Event, Shader, or asset being changed.

• Partial patches, insertion instructions, isolated functions, ellipses, and abbreviated production code are prohibited.

• When an existing canonical asset owns a behavior, that asset must be modified directly. Workaround scripts, bypass branches, compatibility shims, parallel implementations, duplicate ownership, and dispatcher interception are prohibited unless explicitly approved in a deliberate architecture review.

• The user’s exact current complete code is mandatory before changing a sensitive or recently revised asset. Memory, an earlier assistant-generated version, or a presumed local state is not sufficient.

• Every response must identify the destination asset, exact authorized changes, preserved behavior, and validation checkpoint.

• Development state must remain explicit: proposed, supplied in chat, user-installed, successfully compiled, and runtime-tested are separate statuses and must not be conflated.

Recovery protocol for future continuity or architecture uncertainty

• Stop before speculative coding when ownership, source currency, or the user’s installed state is uncertain.

• Identify the existing canonical owner and reject any impulse to create an adjacent refinement, compatibility, or override layer.

• Request the exact current complete canonical asset and use it as the sole source for the replacement.

• Make only the authorized change, preserve all unrelated code and approved visuals, and return the entire destination asset in one uninterrupted code block.

• Validate at the boundary named by the user: compilation first, then runtime appearance or behavior, then regression checks against protected systems.

Current Fire-only continuation checkpoint

• Fire has already been revised directly inside scr_ui_draw_affinity_manifestation_prototypes, which remains the canonical Script for this manifestation family.

• The approved Fire elements are the upper flames, sparks, embers, and kindling. They must remain visually unchanged.

• The rejected element is the lower Fire effect, which currently resembles a flat ellipse or platform.

• The next authorized revision is Fire only: rear flames behind the lower hemisphere, foreground flames overlapping the lower rim, curved side tongues, irregular broken circular coverage, and no mechanical energy-ring appearance.

• Water, Ice, Grass, helper functions, asset overrides, draw-state restoration, and all unrelated code and visuals must be preserved exactly.

• Before this revision begins, Curtis’s exact current complete scr_ui_draw_affinity_manifestation_prototypes Script must be requested. The response must then return the entire Script as one complete paste-ready code block.

Document filename and metadata policy

• Beginning with Development Log v1.8 and Information Sheet v2.4, filenames use only the document identity and version number.

• Formatting_Preserved, BACKUP, calendar dates, duplicate-download suffixes, and similar filename clutter are removed from current deliverables.

• Creation and modification dates are stored in document metadata. Chronological dates remain inside the worklog where they are necessary to preserve the historical sequence of development events.

Revision notes for v1.8 of this log

• v1.8 preserves the complete v1.7 chronology, page setup, footer identity, paragraph formatting, and protected historical content.

• v1.8 records the prior-chat errors, rejected architecture, migration rationale, strengthened adherence rule, future recovery protocol, and Fire-only continuation checkpoint.

• v1.8 synchronizes the current canonical Main Menu state and removes the stale implication that the gimbal rollback is still pending.

• Development Log v1.8 and Information Sheet v2.4 adopt clean version-only filenames; document dates are maintained through metadata rather than appended to filenames.

July 20, 2026 - 14:36 to 15:52 EDT: Fire Affinity encapsulation trials and connected-shell breakthrough

Session evidence: successive full-procession video captures, Fire-orb reference artwork, the current complete scr_ui_draw_affinity_manifestation_prototypes Script, and runtime visual review.

14:36 EDT - Lower-hemisphere continuity review

• The earlier Fire refinement improved the lower effect but still failed to wrap fully around the bottom of the sphere.

• The controlled task remained Fire-only inside scr_ui_draw_affinity_manifestation_prototypes; the protected procession, sphere, title, menu, orbit, scale, compositing, and other Affinities were not authorized to change.

14:55 EDT - Bottom convergence requirement

• Reference imagery clarified that the left and right lower flame bodies must connect at the six-o'clock region instead of merely curving toward one another.

• The desired result was a closed fiery silhouette around the orb without a flat ellipse, platform, halo, or mechanical energy ring.

15:08 EDT - Full encapsulation and stronger visual weight

• The effect had moved closer to the target but remained lackluster compared with stronger Affinity manifestations.

• The Fire Orb required more mass, brighter heat hierarchy, greater overlap, and clearer whole-orb coverage while retaining a readable spherical core.

15:29 EDT - Rendering-technique correction

• Full-rotation footage showed that adding more individually readable plumes, corona pieces, and convergence tongues increased density without creating unity.

• The visual problem was redefined: Fire must be one interconnected flame entity, not a collection of flames arranged around an orb.

• A standalone design-model pass was approved as a method of thinking, but not as a new permanent object, renderer, dispatcher path, workaround Script, or duplicate owner. Canonical ownership remained unchanged.

15:52 EDT - Connected flame-shell breakthrough

• The connected flame-shell renderer produced a colossal step in the right direction. The orb began to read as engulfed by one continuous flame body rather than surrounded by separate ornaments.

• The complete rotation exposed an artistic conflict between the new connected shell and the older independent tall plume field. The plume field continued to read as a second effect behind the shell.

• The next Fire pass should retain the connected shell and either remove the legacy plume layer or redesign it into a restrained rising vortex/spiral that grows from the same continuous body.

• Current validation state: installed and runtime-observed through full rotation; direction strongly favored; Fire not yet final, protected, or approved as complete.

July 20, 2026 — 17:36 EDT: complete editorial-rebuild directive

• Curtis instructed that all remaining legacy formatting in the Guide and Worklog be discarded as a visual constraint.

• Every original section, table, list, and retained research block was to be repositioned or reformatted for clearer literary flow while preserving substantive information.

• The creature register was protected from content alteration; presentation could be improved only without changing creature data.

• The timestamp log was judged too sparse. The requested replacement was a full chronology of development progress from the earliest recorded project foundation through the current active milestone.

• The new editions were assigned major-version status because they alter document architecture and editorial presentation rather than merely adding a dated update.

2026-07-20 17:48 EDT: Guide v3.0 and Worklog v2.0 editorial rebuild

• Rebuilt typography, hierarchy, headers, footers, spacing, tables, timeline presentation, and document navigation.

• Preserved all existing substantive chronology and appended a dense timestamp ledger with explicit evidence precision.

• Retained the Guide’s images, technical tables, Affinity register, and complete 200-row creature list.

• Prepared both documents for render-and-page review before delivery.

Reusable VFX research objective

• Treat the Fire Orb experiments as a reusable 2.5D/3D VFX research milestone: connected shells, front/rear depth layers, material-specific movement, hot-core hierarchy, silhouette control, complete-orb compositing, and full-rotation validation.

• Later transfer these principles to Affinity battle attacks and status effects, overworld abilities and Field Moves, environmental manifestations and hazards, weather and atmospheric effects, creature abilities and transformations, transitions, and UI manifestations.

• Do not copy Fire literally to other Affinities. Each Affinity must retain its own material behavior, ecology, rhythm, silhouette, color hierarchy, and visual identity.

• Conduct a future twenty-Affinity procession audit one Affinity at a time through its canonical owner. No universal override, duplicate renderer, or dispatcher interception is authorized.

ERA VI / DOCUMENTATION GOVERNANCE AND RESEARCH TRANSFER / JULY 20, 2026

July 20, 2026 - 16:12 EDT: documentation identity and chronology reorganization

• Curtis directed that the Information Sheet become a development guide, while the Worklog become the detailed record of labor, conceptualization, implementation, testing, mistakes, and historical evolution.

• Both documents were authorized for controlled rearrangement to improve section ownership, literary flow, timeline clarity, and navigation while preserving their protected content and visual continuity.

• Exact times are now recorded when recoverable. Day-level historical entries remain explicitly time-not-preserved rather than receiving speculative hours.

• Clean version-only filenames remain mandatory; dates belong in document metadata and internal timelines, not in filenames.

Stable checkpoint: document identities separated

• Development Guide: authoritative current direction, system rules, architecture, terminology, scope, checkpoints, and roadmap.

• Development Worklog: chronological labor, conceptual evolution, experiments, debugging, evidence, failures, validation states, and recovery history.

• Cross-document rule: the Guide governs current implementation; the Worklog preserves how the Guide arrived there.

Revision notes carried forward from v1.9

• Renamed and reformatted the document as the Majutori Development Worklog to distinguish it from the Development Guide.

• Added exact-time entries for the July 20 Fire manifestation trials and the documentation-reorganization session.

• Recorded the connected flame-shell breakthrough, legacy-plume conflict, rising-vortex direction, and reusable VFX research objective.

• Moved the nonchronological v1.2 reference snapshots, architecture summaries, backlogs, risks, and utilization notes into a dedicated appendix so the main chronology reads continuously.

• Added concise headers, page-number footers, current checkpoint front matter, a recent-session index, and a formal timestamp standard.

• Preserved earlier chronological entries as historical records; no earlier version was overwritten.

ERA VII / AFFINITY VFX FOUNDATION PROGRAM / JULY 21, 2026

July 21, 2026 — time not preserved: decoupled architecture reset and clean-shell checkpoint

• Replaced the former three-pass manifestation ownership model with one decoupled architecture: shared sphere geometry, independent material/internal treatment, rear manifestation, front manifestation, independent emblem, and rear/surface/front entities.

• All external manifestations, entities, and emblems were disabled for the clean-shell checkpoint. All twenty material spheres, the single protected procession, title split, menu layout, scale, cadence, and complete-unit depth sorting remained intact.

• The reset explicitly prohibited old/new ownership coexistence, compatibility renderers, dispatcher interception, and silent composite overrides.

July 21, 2026 — Fire New Architecture passes 01–04

• Pass 01 established Fire under the new ownership model; the 19:13 runtime capture showed an architectural improvement but a halo/rim and crown-like silhouette.

• Pass 02 increased buoyancy and asymmetry through a broader mantle, dominant upper tongues, lower skirt, and restrained embers.

• Pass 03 consolidated an attached rear mantle, dominant central plume, subordinate plumes, shoulder licks, lower skirt, and separate rear/front embers.

• Supplemental Spectacle Pass 04 broadened the mantle, introduced a dominant forked plume, strengthened peripheral flames, widened the front skirt, and increased ember activity. The progress remained incremental and did not yet achieve the target of one realistic living fire body.

Strategic methodology decision

• Micro-pass-only development was superseded by a bounded milestone cycle: Behavior/Reference Brief; Material Foundation; Technical Foundation; Exploration Leap; Correction; Emblem Integration; Polish/Optimization; World-VFX Extraction.

• Realism defines behavior while controlled exaggeration improves silhouette, readability, and spectacle without violating material rules or colliding with neighboring orbs.

• Fire, Water, Electric, Ice, Grass, and Arachnid were selected as technology-anchor Affinities. Their shared systems will support the remaining fourteen.

• The program will close only after reusable battle, status, overworld, environmental, weather, transition, capture, aura, and creature-effect packages are extracted and documented; CharacterSetup NameEntry resumes afterward.

July 21, 2026 — technical discovery audit

• Audited scr_affinity_sphere_renderer_create/begin/draw/end/destroy, shd_affinity_sphere, procession states, Main Menu Draw GUI, compositor, registry, dispatcher, Create Event, and Clean Up Event.

• The original UV sphere used 12 latitude and 24 longitude segments: 576 triangles and 1,728 submitted vertices per sphere.

• The major technical gap was transform ownership: the exact sphere world matrix was private inside scr_affinity_sphere_renderer_draw, while manifestations remained outside the 3D session.

• The existing compositor also began and ended a separate sphere session for every orb; the future target is one coherent internal rear-world/sphere/surface/front-world session per complete orb.

July 21, 2026 — projected surface-anchor proof

• Added scr_affinity_orb_transform as the shared canonical owner of phase, radius, rotation, world position, and world matrix.

• Added sphere-local latitude/longitude directions, exact matrix transformation, GUI projection, controlled envelope rendering, and rear/side/front classification.

• The first installation did not compile because the procession-layer contents were accidentally pasted into scr_affinity_sphere_renderer_draw. Duplicate function-name and argument-count errors identified the crossed destination files.

• Restoring the correct complete sphere-draw and compositor assets resolved the compile failure without changing architecture.

Targeted Affinity Script ownership cleanup

• Project-wide search confirmed scr_ui_draw_affinity_orb had no callers and only invoked the obsolete scr_ui_draw_affinity_effect.

• scr_ui_draw_affinity_effect contained the old monolithic twenty-Affinity switch plus scr_ui_manifestation_draw_stream; every helper call was internal to the same obsolete resource.

• Both Script resources were deleted. The 21:45 runtime capture confirmed all twenty spheres, Fire, title layering, menu layout, and complete-unit depth order remained stable.

• scr_ui_draw_affinity_asset_layers was retained as the active canonical GUI-space sprite asset renderer for manifestations, emblems, and rear/surface/front entity assets.

July 21, 2026 — 22:01 EDT: anchor integration runtime validation

• Search showed the proof function existed and was enabled, but only its declaration appeared; no compositor calls were installed.

• A complete compositor replacement restored one shared transform per orb, rear diagnostics before the sphere, side diagnostics after the sphere, front diagnostics after front entities, and the same transform argument into the sphere renderer.

• Runtime footage showed cyan rear anchors, magenta silhouette anchors, lime front anchors, a pale envelope, and center marker moving rigidly with Fire. The projected-anchor proof was accepted as successful.

July 21, 2026 — 22:17 EDT: subdivision-3 icosphere conversion

• Replaced the shared UV sphere with one canonical subdivision-3 icosphere generated from an icosahedron through three normalized midpoint subdivisions.

• The frozen non-indexed mesh contains 1,280 triangles and 3,840 submitted vertices and remains shared by all twenty orbs.

• Runtime footage showed a massive improvement in roundness and a major reduction in visible polygonal angles. The icosphere became the protected default geometry.

• Future LODs remain within the same topology family: subdivision 2 for low/distant use, subdivision 3 for default/Main Menu, and subdivision 4 only for validated close-up use.

• Surface anchors, particle distribution, crawling paths, and Affinity behavior remain mathematical/direction-based rather than dependent on mesh vertices or adjacency.

Display-quality findings and next gate

• Residual motion artifact appears primarily as moving-edge aliasing/shimmer. The uploaded software capture did not show a stable horizontal split characteristic of classic screen tearing.

• Windows Game Options confirmed 'Use synchronization to avoid tearing' is enabled. External phone recording was explicitly declined as unnecessary; future visual review will use direct user observation and uploaded software captures.

• No display_reset() or display_aa code exists. A guarded 4× MSAA preference with 2× and 0× fallback remains the planned quality proof, but no implementation owner has yet been authorized.

• 'Interpolate colours between pixels' remains enabled for current development. Hand-drawn sprite work must later be viewed with filtering both enabled and disabled for artistic and compatibility comparison.

• scr_globals was inspected: it contains project macros and enumerations only. It is not currently a callable runtime graphics-initialization function.

• SHA-256 strings supplied with large text assets were clarified as optional file-integrity fingerprints, not GameMaker code or installation instructions.

Current July 21 checkpoint

• Approved/runtime-observed: clean-shell architecture reset; obsolete renderer removal; shared canonical transform; projected anchor proof; subdivision-3 icosphere; protected procession and menu behavior.

• Provisional: current layered 2.5D Fire manifestation and material shader.

• Next: establish one canonical display-initialization owner and run the guarded MSAA proof; then replace projected markers with true world-space diagnostic geometry and build the generalized hybrid VFX session.

• Fire's 3D Transition Leap, correction, emblem integration, polish, and world-VFX extraction follow. CharacterSetup NameEntry resumes after the bounded Affinity VFX Foundation Program closes.

Revision notes for v2.1 of this Worklog

• Added the complete July 21 Affinity VFX architecture, Fire-pass, technical-audit, failure-recovery, cleanup, runtime-validation, geometry-conversion, and display-quality chronology.

• Updated the front-page active checkpoint and timestamp ledger while preserving all prior historical records.

• Synchronized the Worklog with Development Guide v3.1 and retained explicit supplied/installed/compiled/runtime-tested distinctions.

• Worklog update completed July 21, 2026, 22:49 EDT.

Appendix A — Historical Architecture, Reference Snapshots, and Retained Backlogs

This appendix preserves nonchronological reference material that previously interrupted the dated work sessions. Its content remains historically useful, but its status labels must be read carefully because later checkpoints may supersede earlier snapshots.

Initial v1.2 working checkpoint (historical snapshot)

• Boot, logo, pre-title intro, main menu, New Game opening cutscene, narrator dialogue, speaker transition, and two-line page preparation remain established working foundations.

• rm_menu displays Majutori with fnt_title_main, neon flicker/Affinity rings, title music, centralized vertical navigation, cursor audio, confirmation audio, and protected delayed quitting.

• obj_input_controller now owns a once-per-frame menu navigation/cancel state and supports keyboard plus gamepad directional intent with held-repeat timing.

• obj_save_controller and its script layer provide a versioned three-slot save schema, validation, transactional writes, backup/quarantine recovery, cache summaries, new-slot creation, loading, and active-save ownership.

• The persistence diagnostic has produced a verified PASS for serialization and readback using matched buffer APIs.

• New Game flow steps have stable save identifiers, validated conversion in both directions, a rollback-safe checkpoint helper, Boolean transition contracts, destination-based Introductions music, and active-save resumption.

• obj_new_game_flow_controller contains dormant centralized save-failure Retry/Cancel handling and a blocking diagnostic overlay; it activates only after a transactional transition reports failure.

• rm_save_select and obj_save_select_controller compile with three-slot display, New Game/Load Game modes, shared input, status/error rendering, protected slot activation, flow-entry requests, and accepted-selection audio/music behavior.

• The save-selection room is intentionally not yet reachable. Main-menu New Game still follows the old direct route, and Load Game remains unconnected, until the final transactional integration is applied as one controlled change.

• CharacterSetup, OriginSelect, StorySetupCutscene, and full Gameplay remain future dedicated systems; the existing rm_game routing is still a placeholder.

• Release-clearance tracking remains mandatory for BoldPixels and all placeholder audio. In particular, the Dragon Ball-derived confirmation prototype is not a shipping asset.

Current protected structured-dialogue architecture

• Do not revert to making obj_textbox_controller draw itself unless there is a deliberate architecture review.

• Scene/drawing owner: obj_narrator_intro_controller Draw GUI draws the narrator scene background.

• Dialogue state owner: obj_textbox_controller stores dialogueEntries, entry/page indices, active speaker/text/page data, typewriter position, input lock, and completion status.

• Renderer: scr_textbox_draw() draws the active text box, border, text, and continue marker.

• Draw call rule: the scene controller calls scr_textbox_draw() last so the text box appears above scene visuals.

• Input rule: obj_textbox_controller Step Event handles confirm input, typewriter completion, page advancement, entry advancement, and textboxFinished.

• Flow rule: obj_narrator_intro_controller stores the controller returned by scr_textbox_start() and checks that direct reference for textboxFinished before calling scr_new_game_flow_advance().

• Reusable target: this architecture should be reused for NPC dialogue, signs, item messages, prompts, battle text, and future menu dialogue.

• Data contract: every dialogue entry is a struct with string speaker and text fields created through scr_dialogue_entry().

• Validation rule: scr_dialogue_validate() validates the full sequence once at startup; data-shape checking is not repeated every frame.

• Loading rule: scr_textbox_load_entry() is the single place that assigns an entry, calculates pages, and resets reveal state.

• Lifecycle rule: scr_textbox_start() reuses an inactive controller and refuses to overwrite an active sequence, preventing accidental interruption and unnecessary instance churn.

• Paging rule: scr_textbox_build_pages() performs pixel-width wrapping and groups prepared output into two visible lines per page; actual animated upward scrolling remains a future feature.

Current protected save-system architecture

• Ownership rule: obj_save_controller alone owns activeSlot, activeData, slot cache, operation state, and the latest save diagnostic.

• Persistence rule: complete save files use buffer_load/buffer_save with explicit buffer deletion; do not reintroduce the failed text-close path without a new runtime investigation.

• Schema rule: serialized data uses SAVE_SCHEMA_VERSION and logical string IDs. Runtime asset handles and reorderable enum numbers do not belong in save data.

• Validation rule: data must pass structural, type, version, slot-ownership, and recognized-flow-ID checks before activation or writing.

• Transaction rule: no temporary file becomes primary until it has been read back and validated; the prior primary is preserved before commit.

• Recovery rule: valid backup/temporary data is healed into a verified primary before becoming active. Corrupt or unsupported slots are never silently overwritten by New Game creation.

• Rollback rule: a failed checkpoint restores both the writer's timestamp and the flow checkpoint's previous in-memory step so the runtime state cannot move ahead of the committed disk state.

• Cache rule: checkpoint writes mark cached summaries stale rather than forcing unnecessary full-slot rereads during every room transition.

• Placement rule: obj_save_controller and obj_input_controller are created on demand and persist; they are not manually duplicated across rooms.

Initial v1.2 staged flow/save-selection contract (subsequently completed)

• NewGameFlowStep is a runtime state; persistent progression uses the explicit step-to-ID and ID-to-step mapping. Inactive is not a resumable checkpoint.

• The next-step checkpoint must succeed before flowStep changes or room_goto() is accepted. This final call is staged but not yet connected.

• The opening-cutscene and narrator controllers are the only external callers that must adopt the final Boolean advancement contract.

• Save selection owns slot choice and activation; the New Game flow owns sequence order; neither system should duplicate the other's responsibilities.

• Title music should continue from rm_menu into rm_save_select and stop only after a slot is activated and the saved/new flow transition is accepted.

• A failed flow checkpoint must remain on the current scene, display the central error panel, and allow explicit Retry or safe return to the main menu without damaging the last committed save.

• preparedSlot exists only to make a failed post-activation transition retryable without recreating or reloading the same slot. Navigating elsewhere clears the runtime attachment but leaves committed data untouched.

Object responsibilities captured at the initial v1.2 checkpoint

• obj_game:

• Persistent bootstrap object placed in rm_boot.

• Initializes startup_config.ini state, boot/game state, title-music globals, and the first room transition.

• obj_logo_controller:

• Controls the studio/publisher logo sequence, fades, timing, and later-boot skip behavior.

• obj_intro_controller:

• Controls the pre-title placeholder MP4, intro music, skip/failsafe behavior, and IntroSequenceSeen startup flag before entering rm_menu.

• obj_menu_controller:

• Draws the Majutori title, fnt_title_main presentation, neon flicker/Affinity rings, menu panel, and selected-entry highlight.

• Tracks title music, cursor/confirmation sound instances, delayed quit state, and shared vertical menu intent.

• Currently still starts New Game directly; its New Game and Load Game branches will be rerouted together in the next atomic integration.

• obj_input_controller:

• On-demand persistent owner of once-per-frame menu direction, held-repeat timers, axis thresholding, and Cancel intent. Calls scr_input_update() in Begin Step.

• obj_save_controller:

• On-demand persistent owner of active save data, slot cache, SaveSelectMode, operation lock, cache readiness, and save diagnostics.

• obj_save_select_controller:

• Non-persistent controller placed once in rm_save_select. Initializes mode/cache, selects a preferred usable slot, blocks carried confirmation, and renders all three slot panels responsively.

• Creates or loads only eligible slots, preserves protected failure behavior, supports prepared-slot retry, requests New Game start/resume, and stops title music only after accepted entry.

• obj_new_game_flow_controller:

• Persistent owner of flowStep, Introductions music, pending transition state, checkpoint failure diagnostics, Retry/Cancel input, and the blocking save-error Draw GUI panel.

• obj_opening_cutscene_controller:

• Controls the New Game MP4, eligible skipping, fade-out, OpeningCutsceneSeen, and the first external scr_new_game_flow_advance() call.

• obj_narrator_intro_controller:

• Owns narrator dialogue construction/scene rendering and makes the second external scr_new_game_flow_advance() call after its direct textbox controller reference reports completion.

• obj_textbox_controller:

• Stores and advances structured dialogue entries, prepared pages, speaker state, typewriter state, input protection, and completion state without owning the room background.

Script responsibilities captured at the initial v1.2 checkpoint

• scr_globals:

• Defines the 60 FPS/tile/camera macros; Direction, PlayerState, GameState, LogoState, and NewGameFlowStep; and save schema/slot constants plus SaveSlotStatus and SaveSelectMode.

• scr_input_confirm_pressed / scr_input_confirm_down:

• Provide normal confirm press/held semantics for dialogue, interaction, and menu actions across keyboard, mouse, and primary gamepad face button.

• scr_input_skip_pressed:

• Provides the broader cinematic/logo skip set without contaminating ordinary confirm behavior.

• scr_input_get_controller / scr_input_update:

• Create/find the persistent input controller and update shared menu vertical/cancel intent once per frame with held-repeat and gamepad-axis handling.

• scr_input_menu_vertical_pressed / scr_input_cancel_pressed:

• Expose cached menu intents to UI consumers without duplicating device scans.

• scr_dialogue_entry / scr_dialogue_validate:

• Create the structured speaker/text contract and validate complete dialogue sequences before playback.

• scr_textbox_start / scr_textbox_load_entry:

• Start or reuse the dialogue controller and centralize speaker, entry, page, and typewriter reset assignment.

• scr_textbox_build_pages / scr_textbox_draw:

• Measure/wrap entries into two-line pages and render the shared bottom-screen dialogue box when called last by the scene owner.

• scr_textbox_is_active / scr_textbox_is_finished:

• Expose dialogue activity/completion state to menus and flow controllers.

• scr_save_get_controller / scr_save_slot_is_valid:

• Provide the persistent save owner and central slot-index validation.

• scr_save_create_default_data / scr_save_validate_data:

• Create the versioned default schema and enforce required types, fields, slot ownership, version compatibility, and recognized flow checkpoints.

• scr_save_slot_filename / scr_save_read_file / scr_save_read_slot:

• Resolve slot filenames, parse and validate a complete save file, and select a valid primary/temporary/backup source with recovery diagnostics.

• scr_save_write_text / scr_save_write_slot:

• Use matched buffer persistence and execute the verified temporary-write, preservation, commit, rollback, and operation-lock transaction.

• scr_save_build_summary / scr_save_refresh_slot_cache:

• Build lightweight validated slot metadata and cache all configured slot states for UI display.

• scr_save_create_new_slot / scr_save_load_slot / scr_save_clear_active:

• Protect empty-only creation, validate/heal existing saves before activation, and detach runtime save state without deleting committed files.

• scr_save_run_self_test:

• Retained opt-in diagnostic that produced the successful serialization/readback checkpoint; it is not called during ordinary startup.

• scr_save_format_play_time:

• Formats fixed-frame playtime as hours:minutes:seconds for slot summaries.

• scr_new_game_flow_get:

• Returns or creates the persistent New Game flow controller.

• scr_new_game_flow_step_to_id / scr_new_game_flow_id_to_step:

• Translate playable New Game steps to and from stable persistent identifiers; unsupported and runtime-only values return undefined.

• scr_new_game_flow_checkpoint:

• Writes the next active-save checkpoint transactionally, skips redundant writes, marks cache stale on success, and restores the prior in-memory ID on failure.

• scr_new_game_flow_set_step / start / advance:

• Validate and route flow steps with Boolean results and destination-based Introductions music. The checkpoint call is the next pending connection.

• scr_new_game_flow_resume_active:

• Validates active save data, translates its stored flow ID, and requests entry through the centralized router.

• scr_camera_initialize / scr_camera_update:

• Camera foundations remain pending review before overworld work resumes.

• scr_weather_update / scr_audio_update:

• Placeholders remain intentionally unused until their owning systems are designed. scr_input_update is no longer blank.

Text system feature backlog and timing plan

Near-term text box improvements

• Better Gen IV-style bottom-screen proportions.

• Pixel-style font integration once a suitable commercial-use font is selected/imported.

• Completed foundation: automatic word wrapping by measured pixel width during entry loading.

• Completed foundation: two-line page preparation and page-by-page advancement; actual animated upward scrolling remains pending.

• Partially complete: a static continue triangle appears when the current page finishes revealing; animation remains pending.

• Completed foundation: textSpeed is owned by the text controller; exposing it through Settings remains pending.

• Message queueing so multiple messages can be queued without rewriting scene logic.

• Partially complete: structured reusable dialogue calls are proven for the narrator; NPC, sign, item, and system-specific adapters remain pending.

• Yes/No prompt foundation for save prompts, item prompts, starter confirmations, and origin city confirmations.

Later text-engine features

• Pause commands such as {pause=30}.

• Sound commands such as {sound=snd_text_tick}.

• Color commands for selective text emphasis.

• Player-name insertion after name entry and Tamer profile exist.

• Choice menus and multi-choice prompts after menu-choice input systems exist.

• Text speed settings in Options.

• Different window skins in Options.

• Animated Gen IV-style border graphics after the code-drawn foundation is stable.

• Optional per-character text tick sound after final UI sound effects are chosen.

• Battle-message integration after the battle system begins.

• Trade-message integration after trading architecture begins.

• Breeding/egg-message integration after breeding mechanics begin.

Broader game-feature backlog connected to Generation 1–4 inspiration

• Battle system and combat move design.

• Creature catching system.

• Creature trading system.

• Breeding or a reimagined equivalent mechanic.

• Creature encyclopedia / PDA archival analysis.

• NPC dialogue and world flavor text.

• Signs and environmental inspection messages.

• Item pickup messages and static capsule pickups.

• Gathering prompts for respawning gathering items.

• Local storage and Interdimensional / Multidimensional Storage.

• Three-slot persistence and save-selection display foundation completed; final menu/flow connection plus later metadata fields (location, creatures, badges, date, and screenshot) remain pending.

• Options menu including text speed, audio, screen/window options, and later window frame style.

• Origin city selection and origin city identity.

• Gender selection, name selection, and character customization.

• Opening apartment/laboratory gameplay sequence.

• Battlegrounds and Battleground Moguls by Affinity/city.

• Creature line evolution and balancing.

• Co-op system with Tamer-owned progress and event ownership.

• Competitive multiplayer battle goals.

• Remote trades and remote battle requests through PDA contacts.

• Excluding Pokéwalker-style companion hardware mechanics.

Known risks and production safeguards

• Scope creep is the largest production risk because the full feature dream is much larger than the current playable foundation.

• Avoid implementing all text commands, all options, all co-op systems, and all multiplayer systems before the game has a playable vertical slice.

• Use stable checkpoints to prevent accidental regressions: Boot stable, Logo stable, Intro stable, Menu stable, New Game cutscene stable, Narrator textbox stable.

• When a bug lasts longer than one focused session, isolate the smallest working test case instead of adding more layers.

• Keep object/event responsibility simple: Create initializes, Step updates, scene Draw GUI draws scene, scripts hold reusable logic, flow controllers control transitions.

• Do not put Create Event initialization code into Draw GUI or Draw GUI End events.

• Do not allow old diagnostics or development messages to remain in final presentation paths.

• Use room-specific scene controllers to call scr_textbox_draw() last when that scene owns a dialogue display.

• Before adding advanced text features, preserve the current working baseline in this document.

• Do not bypass scr_save_write_slot() with direct primary-file writes; temporary verification and preservation are part of the save contract.

• Do not serialize enum numbers or asset handles when a stable logical ID exists.

• Do not expose rm_save_select from the main menu until checkpoint-before-room transition, both external callers, and New Game/Load Game routing are changed and tested together.

• A compilation pass is necessary but not sufficient for persistence changes; use readback, recovery, cancel, resume, and failure-path tests before declaring the slot flow stable.

Initial v1.2 next milestone (subsequently completed)

• Connect scr_new_game_flow_checkpoint(_nextStep) inside scr_new_game_flow_set_step() before flowStep mutation, music changes, or room_goto(). On failure, populate the persistent blocked-transition state and return false.

• Update obj_opening_cutscene_controller and obj_narrator_intro_controller—the only external advance callers—to obey the Boolean transition contract without repeating disk writes every frame.

• Reroute main-menu New Game and Load Game to rm_save_select by setting SaveSelectMode. Keep title music alive across that room change and let the save-selection controller stop it only after accepted slot entry.

• Run an end-to-end empty-slot New Game test: create/verify/activate a slot, enter the opening cutscene, advance to narrator, confirm the stored step changed, and verify the prior primary/backup transaction behavior.

• Run Load Game/resume tests for opening_cutscene and narrator_intro checkpoints; verify empty, occupied, corrupt, unsupported, backup-recovery, Cancel-to-menu, and title/cursor/confirm audio behavior.

• Exercise the forced save-failure path so the current scene remains intact, the last committed checkpoint remains unchanged, Retry is input-gated, and Cancel returns safely to rm_menu.

• After the save-slot flow is verified and labeled stable, begin the dedicated CharacterSetup room and reusable choice/Yes-No foundation needed for Tamer appearance, name, and later origin city selection.

ChatGPT utilization record

• ChatGPT has been used as a coding and development assistant for GameMaker Studio project structure, GML code generation, debugging, architecture revision, document planning, and production analysis.

• ChatGPT has helped generate and revise code for startup flow, logo flow, intro/cutscene flow, menu flow, New Game flow, input handling, and the text box system.

• ChatGPT has helped identify responsibility splits between objects, scripts, flow controllers, and renderers.

• ChatGPT has helped analyze legal/disclosure concerns around using AI-assisted code on Steam, while the user remains the project’s creative director and decision-maker.

• ChatGPT has helped with concept ideation, title brainstorming, creature naming, animal inspiration research, audio pipeline explanations, GIMP workflow, and documentation structure.

• The current project record does not indicate runtime AI features inside the game; ChatGPT use is development assistance, not necessarily a player-facing AI feature.

• The user wants ChatGPT learning advancements preserved so repeated errors are not made in future GameMaker sessions.

• Most important preserved ChatGPT/GameMaker lesson: scene controllers draw scenes and call shared UI draw scripts last; reusable state controllers should not own unrelated scene rendering.

• ChatGPT Work is now the active collaboration surface for this project; this document serves as the durable bridge from the archived regular ChatGPT conversation.

• The Work-based continuation has been used for GML architecture review, syntax correction, dialogue data modeling, lifecycle/performance analysis, title-font integration, error diagnosis, and asset-attribution tracking.

• The v1.2 Work continuation used ChatGPT for save-schema design, file-I/O diagnosis, transactional persistence, recovery/rollback architecture, shared input design, flow serialization, and save-selection UI staging.

• ChatGPT assisted in distinguishing a GameMaker runtime close-result anomaly from actual read/write corruption and replacing that path with a matched, verified buffer foundation rather than suppressing the error.

• ChatGPT also preserved asset-rights distinctions: attribution requirements, CC0 reference metadata, and copyrighted placeholders that must be replaced or licensed are recorded as different categories.

• The current workflow continues to pair user-run GameMaker compilation/runtime checks with ChatGPT architecture review and durable checkpoint documentation.

Editorial rebuild record — Version 2.0

• Reconstructed the Worklog as a complete project chronology rather than a short recent-session index followed by legacy notes.

• Added a forty-plus-entry timestamp ledger spanning the June 6 project foundation through the current documentation rebuild, with exact hours only where recoverable.

• Retained the full detailed chronological narrative and historical appendices, then divided them into readable development eras.

• Standardized every date heading, bullet, note, table, header, footer, and page hierarchy under a new editorial system.

• Recorded the Fire connected-shell breakthrough, the remaining plume conflict, and the cross-system 2.5D/3D VFX research-transfer objective.

• Editorial rebuild completed 2026-07-20 17:48 EDT.