Make yourself
at home in Random Saga.

PLAYERS / START HERE

Your first playthrough

A scenario is a prepared story world. A playthrough is your own run through that world, with its own conversation, memories, relationships, and choices.

1. Set up your AI connection. Open Providers & models, add your provider key, and choose the saved models you want to use. The provider FAQ explains the account setup.
2. Find a scenario on Discover. Read its description and introduction. Check the scenario type and any content labels.
3. Choose Start a playthrough. Select a beginning if the creator offers alternatives, your player identity, and an available chat presentation.
4. Write what your character says or does. For example: I place the sealed letter on the table. “Who sent this?” You can describe an intention without deciding how another character reacts.
5. Continue from the reply. Enter sends; Shift+Enter starts a new line. Your saved run can be resumed from your playthrough list.

The site may be in a restricted preview. Account creation, confirmation, membership, and access are separate steps; a profile alone does not guarantee that every feature is currently open.

Finding your way around

Home / Discover

Browse stories, search, and open scenario details. A scenario card’s views, favorites, and comments describe community activity, not your saved story progress.

Scenario view page

Read the introduction and the sections the creator allows readers to see. Start playing, follow the creator from their profile, favorite or rate the story where offered, and find comments below the scenario content.

Creator Studio / your profile

Manage your scenarios, personas, provider settings, statistics, favorites, and profile artwork. Other people see the public parts of your profile rather than your private drafts and account settings.

Your playthroughs / Plays

Resume an exact saved run. One scenario can have several separate runs and branches. A scenario title alone does not identify which run you are opening.

Story controls

During play, use the menu, Director’s Notes, Scenario options, memory notifications, and Chat settings. Desktop and narrow-screen layouts can place the same controls in different places.

If you cannot find a control, check both the story menu and Chat settings. Options specific to RPGs or Visual Novels appear only when the current scenario and presentation support them.

Choose who you are

Before starting a new playthrough, choose a saved standard persona for Standard or Visual Novel stories, or a saved RPG persona for RPG stories. If you do not have the right kind, choose Create persona & return; after saving, you will return to the waiting scenario. Playing without a persona is no longer offered. RPG persona creation supports an optional uploaded portrait, readable skill choices and class-appropriate weapons.

A persona describes the character you are playing. It is separate from your member profile: Alex might be your display name while a particular story’s player persona is Captain Vale.

• Standard personas hold a character name, description, lore, and any supported portrait or identity details.
• RPG personas also include game information such as level, race, class, weapon, magic gate, starting spells, and skills.
• Playable story characters are character lore cards the creator has explicitly made available as the player’s identity. A character in the cast is not automatically playable.
• Character parties, where offered, let you prepare a group and its shared history and dynamics.

{{user}} means the selected player persona. Creators can use it in scenario text so the app shows the player’s chosen name. You can choose a different saved standard persona for future messages through Chat settings; this does not rewrite earlier exchanges. RPG characters are selected when starting the playthrough; edits to their library record apply to future runs.

Keep the identity useful to the scenario. A grounded mystery may work better with a curious local than an all-powerful hero.

Scenario type and chat presentation

Scenario type describes the experience the creator is making. Chat presentation describes how the conversation is shown. They are related choices, rather than interchangeable names.

Standard and Multi-Character chat

Standard chat presents a storyteller response as narrative and dialogue. Multi-Character chat separates participating characters into named blocks, with character actions and dialogue. Narration can still appear between those blocks. This makes a group scene easier to follow; it does not mean each character is an independently signed-in person.

RPG and Visual Novel presentations can be combined with Multi-Character capabilities where the scenario offers them. Choose from the options actually shown at the start of your run or in Chat settings. Changing presentation changes future display and response formatting; it does not start a new timeline.

Character information and knowledge should still stay distinct. A character being on screen does not mean they know every secret in the story.

Writing a useful message

Say what your character attempts, says, notices, or asks. Give the storyteller enough detail to respond without writing everyone else’s choices for them.

Use ordinary dialogue for in-world conversation. Use /ooc for a direct instruction or correction outside the scene. For direction that should stay active across replies, use a Director’s Note.

A longer prompt is not automatically better. Focus on the next meaningful action, and let the response give you a chance to react. A model can still make continuity or formatting mistakes; the correction and archive tools help you address them.

All website slash commands

Open the slash menu beside the message box, or type a command. Put the command at the beginning when opening a tool. The eight commands below are the commands exposed by the website’s play interface.

Costs: asking for a new reply, image, generated prompt, or lore proposal may call your provider. Merely opening a tool is different from pressing its Generate action. Check the selected model before generating.

Action chips from an RPG’s Choose RPG action menu are separate from slash commands. Let that menu prepare them; you do not need to type their internal text.

Re-rolls, branches, and the chosen story

Re-roll

Ask for a different version of the latest assistant response. Use the re-roll icon or /reroll. The selected version is the one the story continues from.

Canon

The chosen, committed version of events for this run. A rejected variation is not an additional event that also happened.

Branch

Create a separate playthrough from an earlier response or variation. Your original chat remains available. A branch is useful when you want to explore another choice without replacing your current run.

Continue

Generate another response without supplying a new player action. It advances the current story rather than making a copy.

Delete a message carefully

The message-options menu can delete a turn. The confirmation explains that this removes the player prompt and assistant reply, including that turn’s re-rolls and stored memory covering the turn. Later messages are kept, and continuity is rebuilt. Later prose can therefore still refer to something you removed; review the resulting story instead of assuming deletion rewrites every later sentence.

To preserve both possibilities, branch first. To correct a persistent fact, inspect its lore or memory entry as well as the visible message.

Director’s Notes: steer without speaking in the scene

A Director’s Note is private direction for a particular playthrough. Active notes are supplied to new replies and re-rolls without appearing as dialogue in the conversation.

1. Open Director’s Notes in the story controls or Chat settings.
2. Add an optional title and choose a scope: Current scene or Overall / upcoming story direction.
3. Write a clear instruction and save it.
4. When it no longer applies, remove it from the active list. Inactive/completed notes can be restored or deleted.

The notes list can show when a note was first used and when it was removed. A note is a direction, not proof that its requested event has already occurred. Avoid contradictory active notes, and remove temporary instructions yourself when they have served their purpose.

Use creator instructions for a scenario’s ongoing baseline, a Director’s Note for direction in this run, and /ooc for a direct conversational correction.

Commander: the story’s planning assistant

The roleplay model writes the response you read. Commander is a separate planning role that reviews the developing story and considers threads, character agendas, opportunities, mysteries, and consequences.

A thread is a possible continuing storyline. Commander’s private plans are not automatically facts that your character has witnessed. A plan must be introduced through the actual story before it becomes an established event.

• Choose a story profile to give the planning a general direction.
• Tune story weights, pacing, preferences, and required or excluded elements.
• Let a scene breathe. Direct steering such as /ooc, /break, or an explicit request for no interruptions is taken into account by the pacing logic.
• Turn Commander off if you prefer to guide the story yourself. The normal conversation and saved continuity still matter.

Commander uses its selected model when it evaluates the story. More frequent evaluations can add provider usage. It is not necessary to inspect every assessment while playing.

How Random Saga remembers a long story

Your saved conversation and the information sent to a model are different things. A model has a limited working context, so Random Saga organizes useful story information instead of assuming that every old message can be sent with every reply.

Recent conversation

The immediate exchanges that keep the current scene understandable.

Memories

Stored summaries of things that happened: discoveries, plot points, conflicts, abilities, and other important developments. Entries can cover a range of turns.

Chapters

A larger summary grouping related memories into a stretch of story. A chapter can still be in progress or be closed.

Sagas

Broader summaries grouping chapters, useful when a run becomes very long.

Scene records / capsules

Compact context about scenes so the system can reconnect a later moment with relevant earlier activity.

Facts and beliefs

A distinction between established story information and what an individual character believes. A belief can be incomplete or wrong.

Relationship milestones

Significant relationship developments tied back to the story, rather than only a current numerical value.

Memory maintenance is the process that creates or updates these records from committed events. Context selection chooses what is useful now. The Context Director, when configured, helps select optional context for the next reply. It does not replace the narrator or rewrite the entire archive.

No memory system guarantees perfect recall. Clear names, focused lore, consistent instructions, and occasional corrections make a difference. A large archive does not mean every record is active in every response.

Use the Memory Archive

Open the archive for the current playthrough. It offers search, sorting or paging where appropriate, and sections for Message history, Memories, Chapters, Sagas, Active lore, Facts & beliefs, Relationships, Scenes, and Continuity audit.

• Message history: read a saved canonical exchange and follow its link back into the story.
• Memories: inspect the summary, type, lifecycle, and covered turn range. Edit or remove entries where the interface permits it.
• Chapters and Sagas: follow the child memories or chapters to understand where a larger summary came from.
• Active lore: inspect cards currently relevant to the run, including their records.
• Facts & beliefs: compare a confirmed statement with a particular character’s understanding.
• Relationships: inspect meaningful changes and their source exchanges.
• Continuity audit: review covered turns, pending turns, active memories, chapters, sagas, scenes, and reported issues.

A coverage percentage describes stored continuity coverage, not a score for the literary quality of your story or a promise that the AI can never forget. A source link is useful when a summary seems wrong: read the exchange before changing the record.

Memory lifecycle

Active information can be selected for use. Other entries may be archived, superseded by newer information, or excluded as an alternate timeline. Do not interpret a historical entry as a second event that happened in your chosen timeline. Preserve the distinction between this used to be true and this was never part of this run.

If automatic memories need attention

A provider error or an unusable summary can pause continuity maintenance. The recovery notice identifies the affected turn range and explains that your messages are saved.

You can retry as needed. Read the specific error before repeating a request many times. If the provider has run out of credits or a model is unavailable, changing the connection or selection is more useful than repeated retries.

Do not delete your playthrough to solve a memory-provider problem.

Lore: the people, places, rules, and things in your story

A lore card is a reusable piece of world information. Unlike a memory, which usually says what happened, lore describes something that can remain relevant across many scenes.

Open the playthrough’s lore or character view to inspect the cards you are allowed to see. Character cards can show descriptions, artwork, relationship information, and records added during play. Lore can come from the original scenario, be generated from events, or be created by you during the run.

Capture a discovery or invent something new?

• Use Create Lore / /lore to capture a person, place, or subject already established in the story.
• Use Story Expansion / /expand when you deliberately want to propose new world content. Review the proposal and add only what you want.
• Use permitted archive editing tools when you need to correct the saved description of an existing card.

A card created in your playthrough does not automatically edit the creator’s published scenario or other people’s runs. Some authored content may be hidden by the creator; a restricted reading view is expected behavior, not missing data.

Relationships, knowledge, and secrets

Relationships are more detailed than one affection score. The tracker includes trust, affection, respect, attraction, comfort, resentment, fear, and attachment, along with a relationship status and history. Character-to-character relationships can also influence a group’s dynamics.

The state is supplied to the storyteller to help reactions stay consistent. A high value is not a promise of a particular response, consent, or a scripted outcome. Read the scene and character as a whole.

What a character knows matters

A story fact can be true without being known by everyone. A character can believe something false. Story Secrets let creators specify private facts and an initial knower: the player persona or a particular character. Keep a secret’s contents out of public summaries and ordinary text that other characters are supposed to know.

“Hidden from readers,” “known by this character,” and “not currently selected for context” are three different ideas. A privacy checkbox does not define a character’s knowledge, and a knowledge restriction does not change what an allowed customization copy can reveal.

In-story phone conversations

Creators can enable Character text messages in scenario options. When the story establishes a phone-text exchange, the system can keep it in a contact-based conversation thread rather than mixing the same message repeatedly into ordinary narration.

During play, describe the text you send and its intended recipient clearly. Review the saved Phone conversations in the story tools to see the contact and message history. A fictional message can be part of the saved story without every character in the scene knowing about it.

This is an in-story feature. It does not send a real SMS or contact another member outside the fiction. Turning it on does not give a character a phone or contact information unless the scenario establishes those things.

Restarts and different beginnings

Open Scenario options from the story controls. A restart creates a new playthrough; the current run stays saved separately. Your current persona, chat-mode choice, and model choices are kept by the restart flow.

Dynamic restart, step by step

1. Choose Choose an alternate opening.
2. Optionally add temporary Director’s Notes for the opening candidates.
3. Generate openings. Re-roll the candidates if you want different possibilities.
4. Read the candidates and select one.
5. Choose Start with selected opening, or cancel to keep your current run.

The temporary direction affects candidate generation only and is not copied into the new playthrough. Generation uses your text provider. Canceling after generating does not undo provider usage already incurred.

Story Clock: time inside the fiction

Story Clock is an optional in-world date and time. It is separate from the real date on your computer. The model can propose elapsed time; the app applies the clock rules and stores the resulting time.

• Creators enable it in the scenario options and can provide an authored starting date and time.
• Conversation, a journey, resting, and an explicit time skip should advance time differently.
• Tracked travel can use app-owned route and elapsed-time calculations, rather than accepting an inconsistent narrative estimate.
• Scripted events can use Story Clock dates and times as additional gates.
• A dynamic header can display clock-related variables when configured.

Enabling a clock does not mean real-world time passes in the story while the browser is closed. Describe the in-world action or time skip you intend. Exact time behavior can depend on the scenario’s rules and travel setup.

Make the chat comfortable to read

Open Chat settings → Chat appearance. Account defaults and a playthrough’s saved choices may differ, so check the current chat when a change seems not to apply.

Use Save appearance to apply the panel’s settings. Reset defaults returns the controls to the provided baseline. If a choice makes text hard to read, increase contrast and reduce transparency before changing anything in your story.

These are presentation settings. Changing a text color does not change a character’s personality, a model’s behavior, or the story’s facts. Creator-authored dynamic headers have their own separate style controls.

Images, backgrounds, and spoken narration

Character images and scene backgrounds

Use /image for a square character image or /background for a wide scene background. A Visual Direction model can help turn the current scene into an image prompt. Choose a saved image model, an available style, a character when needed, and any prompt changes before generating.

Where offered, you can write a prompt, ask the app to prepare one, generate, re-roll, browse generated images, apply a background or assistant avatar, and save a relevant image to character lore. Gallery entries can show the prompt, model, and associated turn. You can also choose a supplied visual style or describe a custom one. Existing character artwork can be supplied as a reference when supported by the selected workflow. Results depend on the image provider and model; identity and visual consistency are not guaranteed.

Visual Novel art

Visual Novel scenes reuse character artwork and location backgrounds. A character’s available image or expression and a scene’s layout help determine the composition. A generated picture in the conversation is different from a reusable character asset in the scenario.

Narration

Configure narration and saved voices under Providers & models, then use the narration tools to generate a recording of a saved reply. Available controls include playing saved recordings, stopping playback, and choosing individual recording parts. Character lore can specify a voice; missing or unavailable character voices fall back to the default narrator.

Generating speech uses the selected speech provider. A saved recording is not the same thing as a new generation request. Text, image, prompt-generation, and speech models can each have their own costs and limits.

Playing an RPG

An RPG scenario combines narrative with game state. Check its configured rules and your character sheet before assuming that a described action has succeeded.

• Choose RPG action: prepare actions in categories such as Magic, Attack, Defend, Skills, Item, Rest, and Inspect. Choose the verb, target, and relevant notes. The resulting action chip describes the action you are attempting.
• Character sheet: inspect the current character’s game statistics, resources, abilities, and progression where available.
• Inventory and equipment: check what you actually carry and have equipped. Rules can limit capacity, costs, requirements, and available uses.
• Action Log and rolls: use the app’s resolved results to understand outcomes. Narrative descriptions should follow the applicable mechanical state.
• Quest journal: review offers, objectives, current steps, status, and relevant consequences. Accepting a quest is a choice; a suggested opportunity is not automatically an accepted task.
• Maps: distinguish known, rumored, and discovered places. A marker is not proof that your character has visited the location.
• Shops and trade: use offered stock, quantities, sale or trade controls, and confirmed exchanges where supported.
• Companions and bestiary: inspect the characters and creatures that have actually become part of the run.

Spells, magic gates, skills, race and class choices depend on the configured rules. Resting does not universally cure every condition, restore every resource, or revive a dead character. Read the scenario’s rules instead of relying on a generic fantasy-game assumption.

Your saved runs and storage

Resume a run from its saved playthrough entry. Give branches and separate runs meaningful names, especially when several share the same scenario title.

• Rename changes the run’s label.
• Archive moves a run out of the ordinary active list; it is different from changing the scenario itself.
• Scenario archive and playthrough archive refer to different objects. Read the confirmation before acting.
• Storage usage and cleanup controls, when enabled, appear in your account’s studio. Review cleanup descriptions before removing unused media.
• File export can be restricted to the site owner. The presence of an import/export capability in the desktop app does not mean every website account has those controls.

Each player supplies their own provider connection. The creator does not need your API key to share a scenario, and your key should not be placed in a scenario, comment, or support screenshot.

Profiles and community features

Your public profile can show your display name, handle, photo, profile background, banner artwork, bio, status, social links, published scenarios, and community activity. Edit profile and Edit artwork lead to profile settings. Artwork offers fit/fill or cropping choices where the editor exposes them; preview before saving.

In Edit profile, choose a Display name and a separate Handle. Display names can be shared by multiple people. Handles identify one account and must be unique, ignoring capitalization: Libby can be a display name while @Telakimathic is the handle. Use 3–32 letters, numbers, or underscores for a handle. Changing either name keeps your scenarios and follows connected to your account, and does not change your sign-in email.

Report a scenario: choose the Report icon in its preview or on its view page, select a reason, and optionally add up to 2,000 characters of detail. Reports go privately to the team. A report does not automatically penalize the creator. If an admin sends a message about it, you can open that private message from your notifications; these team messages do not accept replies.

Follow

Keep a connection to a creator. Followers and following are separate counts. A new follow creates a private notification for the person followed; following is not a message or a subscription to someone’s provider account.

Favorite

Save a scenario to your favorites list. This is different from following its creator or rating the scenario.

Rate

Choose one to five stars on an eligible published scenario. Creators cannot rate their own scenario. The site can review or hold suspicious ranking activity, so an aggregate need not change exactly as one click suggests.

Comment

Leave feedback below the scenario view page. Comments are limited to 2,000 characters. Commenting depends on the creator’s permission setting; existing discussions can remain visible after new comments are closed.

Leaderboard

Compare creator activity over the available 30-day, three-month, and yearly periods. A community rank is not a guarantee that a scenario suits your tastes.

Notifications

Use the bell to review private activity notices. Visibility of a notification is separate from public profile counts.

Keep feedback relevant to the story and its presentation. Follow the site’s Terms and Privacy information.

CREATORS / BUILD YOUR FIRST WORLD

Create a first scenario

1. Choose Create a scenario and select Standard, RPG, or Visual Novel.
2. Add a clear name, a short description, relevant story tags, and the correct content label.
3. Choose a cover image. Add a background and assistant avatar if they help the experience.
4. Write the backstory, opening message, and creator instructions. Make it clear who the player is and what they can do next.
5. Add a few focused lore cards: a central character, an important location, and one or two premises or rules.
6. Write the public introduction. Use it to explain the setup without revealing private plot notes.
7. Check the player preview and Readiness panel. A name, cover, story foundation, and scenario type are the listed readiness checks.
8. Save, then use a private play to test the beginning and the important controls.
9. Review visibility and creator permissions before publishing.

You can start small. A coherent opening with useful lore is easier to test than a large collection of overlapping instructions. Readiness is a checklist, not an assessment of story quality or a replacement for playtesting.

What belongs in each scenario field?

The introduction editor supports headings, paragraph styles, font choices, bold, italics, underline, strikethrough, quotes, text/highlight colors, lists, indentation, alignment, links, images, and clearing formatting. Use a few consistent styles so it remains readable on phones.

Keep rules in one clear place when possible. Repeating slightly different versions in the backstory, instructions, lore, and active notes can create conflicts.

Scenario artwork and visual setup

Cover image

The scenario’s main browse-card image. Check how its crop reads in the player preview.

Scene background

The default environment image for supported play presentations. It is not the same as a creator profile’s banner.

Assistant avatar

A default square assistant identity image where the presentation uses one.

Lore artwork

A character, location, or other lore card can have its own cover/default image, image prompt, and supported additional visual assets.

Image generation

Where offered, choose the relevant generation tool and configured provider. Review the prompt and result rather than assuming generation has filled every asset field automatically.

Visual Novel preview

Select a lore image and location/background, choose a layout, select a position, and preview sample dialogue. Layouts include solo and several two-to-five-character arrangements. A preview demonstrates the authored visual arrangement; it does not advance the story or create live conversation history.

Give reusable artwork consistent proportions and recognizable subjects. Distinguish an expression or scene asset from the character’s ordinary default image. A character without the expected image may fall back to another available visual rather than gaining new art automatically.

Create useful lore cards

Open Lore Cards in the scenario editor. Filter by category, edit an existing card, or use the centered Add Character, Add Location, or corresponding add button. The category-specific add tiles create new entries; existing cards keep their own appearance and information.

The common fields

• Name: a distinct label you and the storyteller can recognize.
• Summary: a concise description useful in lists and permitted reader views.
• Full content: the detailed information the story needs.
• Category/type and color: how the card is grouped and visually identified.
• Importance: a relevance priority, from Minor through Supplementary, Standard, Important, and Critical.
• Pin / always-relevant controls: keep especially important context in attention where supported. Do not pin an entire encyclopedia.
• Triggers: words or conditions that help relevant lore be considered. Ordinary lore triggers are different from a Scripted Event’s comparison rules.
• Linked lore: relationships to other cards. Link useful context rather than every card to every other card.
• Custom facts: structured key/value information that complements readable prose.
• Records: short, turn-linked notes of changes or events involving the card.

Save the lore editor, then save the scenario. A dialog’s edits and the scenario’s saved draft are distinct steps. Before leaving, check for unsaved changes.

Activation, links, pinning, and proximity

A large library works better when the storyteller receives the cards relevant to the moment. Relevance depends on several things together: the scene, referenced names, triggers, importance, links, location, memory context, and the available context budget.

Trigger words

Give a card recognizable names and aliases. Avoid extremely broad triggers like “the” or “person,” which can make unrelated cards compete for attention.

Importance

Helps prioritize a card when there is competition for context. “Critical” does not mean every word is guaranteed to appear in every model request.

Pinning

Use sparingly for facts that must remain immediately relevant. The app can distinguish user-owned and application-owned pins and record pin changes.

Linked lore

Helps related context travel together. A faction can link to its leader or headquarters without linking to every person in the city.

Proximity

Restricts eligibility to selected location anchors and their descendants. With multiple anchors, a card can be eligible at any of them.

Location hierarchy

A parent/child structure such as City → Harbor → Lantern Inn. It is a containment relationship, rather than a list of places already visited.

Use the expanded location view to inspect parent/child relationships; zoom, fit, and pan help manage a larger hierarchy. Moving a location under a new parent can change which descendants fall under a proximity anchor.

Character behavior and starting relationships

For a Character card, define the person before tuning the numbers: name, aliases, role, backstory, motivations, and the important facts the scene requires.

Behavior

The behavior editor includes conflict style, core personality metrics, qualities, and a searchable preset library. A preset applies a complete behavior profile. Manual changes return its label to Custom. Deterministic behavior defaults offer consistent starting values rather than rolling an unrelated personality every time.

Qualities such as guarded, loyal, hot-headed are useful starting language. Choose a small set that fits the prose. A low numeric trait paired with instructions that demand its opposite is likely to be confusing.

Starting relationship with the player

Choose the initial relationship status and tune the starting trust, affection, respect, attraction, comfort, resentment, fear, and attachment where offered. Explain the history that justifies those values. A stranger and a lifelong friend should not have identical setup unless you intend that contrast.

Playable character and narration voice

Enable Playable character if players should be able to select this cast member as their persona. Leave it off for narrator-controlled cast members. Assign a narration voice where supported, with the default narrator available as a fallback.

Story Secrets

Give each secret a clear statement and its initial knower. Keep private knowledge separate from visible card summaries. Test a scene with a character who does not know the secret to see whether the distinction is working as intended.

Quests and objectives

A quest card is more useful when success and failure are understandable. Define an objective, completion condition, failure condition, status, and consequence notes. The editor offers statuses including Not started, Active, Completed, Failed, Abandoned, and Declined.

RPG quest systems can also track offers and player decisions, objective steps, counters, target characters/items/locations, deadlines, rewards, encounters, and map markers as the applicable workflow provides them. An offered quest should leave the player a choice rather than silently treating a suggestion as accepted.

A narrative mention of a reward and an actual inventory/resource award are different things. Check the quest journal and app-owned game state when testing an RPG reward.

Scripted events: a planned moment with conditions

A Scripted Event is a lore card with a condition system. Use it when a moment should become eligible after a particular development, date, or earlier event. It is more precise than merely asking the narrator to “remember to do this later.”

1. Add a Scripted Event card and write what the event should introduce.
2. Choose Active immediately or After previous event. For a chain, select the earlier event explicitly.
3. Choose whether all trigger variables or any trigger variable must match.
4. Add variables with a key/name, starting value, update instructions, comparison, and expected value where applicable.
5. Optionally add a Story Clock date/time gate and choose recurrence.
6. Link lore that helps evaluate the trigger, save, and test both matching and nonmatching situations.

Comparison choices

The condition system includes Equals, Not equals, Contains, Does not contain, Greater than or equal, Less than or equal, Is true, Is false, and Is set. Use a numeric comparison for a numeric progress value and a true/false comparison for a switch-like fact. Give update instructions that explain when the value should change.

Clock gates and repetition

A clock trigger is an additional gate: the variable conditions must still pass. A date-only trigger can remain eligible throughout that date and afterward until resolved; a specific time makes the gate precise to the minute. Recurrence choices are One time, Daily, Weekly, Monthly, and Yearly.

Trigger-linked lore is there to help evaluate conditions; ordinary story links serve a separate context purpose. The runtime records waiting, triggered, or canceled outcomes. A planned event should not be described as already completed merely because its card exists.

Keep it testable: avoid circular event chains, vague conditions like “when it feels right,” and conflicting repeat rules. Story-state interpretation still involves a model, so important events deserve a private playtest.

Customize the assistant header

The dynamic header is the decorative information panel above an assistant response. It can display changing values such as date, time, location, or a custom story variable.

1. Open the scenario menu and enable Dynamic header.
2. Write a Header template containing placeholders such as {{location}}.
3. Add or edit each variable’s key, display name, update instructions, and example value.
4. Explain in Header update instructions when values should change.
5. Set colors, border thickness, corner radius, padding, and alignment.
6. Use the symbol library to insert decorative characters, then test the header in a private run.

The provided date/time/location variables use keys such as month, day, year, time, and location. A custom variable must appear in the template as {{key}}. Keep keys distinct and describe the intended value clearly.

Header colors accept #RRGGBB or #AARRGGBB; the extra leading pair in the second form controls transparency. Alignment can be Left, Center, or Right. A short header wraps more gracefully on a phone than a long decorative frame.

The model updates values under the configured rules; the app renders the decoration. A header is a display of story state, not an independent memory system or proof that an event happened.

Scenario Wizard, expansion, and remix

Open Scenario Wizard from the scenario menu when you want help generating a draft. Treat the result as a proposal to review, not a completed scenario that requires no editing.

The wizard gathers scenario seed, idea/changes, creative direction, content notes, cast and category counts. For RPGs it uses the RPG Setup choices. It offers controls such as generating special instructions and art prompts, keeping existing lore, restoring a retained generated draft, generating missing cards, canceling generation, and using the reviewed draft.

The visible wizard limit is up to 24 lore cards total, with at most 12 per category. These are wizard-request limits, not a promise that every model will satisfy every count perfectly. Review the generated cards and use missing-card generation if offered.

Random Saga generation can replace the map and alternate beginnings when applied. Expansion adds selected cards. Remix uses the last saved scenario, so save important edits before remixing. Choosing a generated draft does not automatically publish it.

RPG setup, maps, and dungeons

RPG Setup groups creative choices so the generator and story have a coherent brief. Maps and dungeons are optional.

Mapper

Use regions and location lore to describe the world. Region controls include names, content, biome, danger, and explorable locations. Review the map and the associated location cards together. A coordinate or marker is not a substitute for a readable description of the place.

Dungeon Generator

Choose a dungeon location and a shape such as Dungeon or Cave. Controls include seed, floors, size, rooms, extra loops, cave rock, and cave smoothing. A seed is useful for reproducing a generation setup; changing its other inputs can change the result.

Preview before applying. After generation, inspect entrances, connections, location lore, and whether the setting supports the quest or scene you intend. Do not assume that a generated map is automatically an interesting encounter or a completed quest.

What setup does not guarantee

A worldbuilding option describes your requested experience. Its presence does not mean every possible crafting recipe, survival simulation, travel vehicle, or custom rules system has a fully automated mechanic. Use the supported controls, inspect the Action Log and game state, and describe special house rules explicitly.

Tune Commander to fit the story

Commander’s interface separates Story style, Settings, and private Threads. Save changes to apply them. You can start from a profile and then fine-tune it.

Story style

• Profiles: choose an overall style such as Balanced Adventure, Dark Intrigue, Character Drama, or Slow Burn; read its description and guidance.
• Story weights: favor themes and subcategories on the provided 0–100 scales. A weight expresses preference, not a guarantee that an event will happen next.
• Pacing: tune how often categories develop. Zero turns off new developments in that category; established consequences can still matter.
• Variation: tune the available variation controls. Variation does not override continuity or explicit requirements.
• Story requirements: state required elements, exclusions, tone, priorities, always-on rules, and soft creative preferences.
• RPG planning style: select a supported RPG mode when the current run uses RPG features.

Settings and review schedule

Select the Commander model independently from the narrator. The minimum and maximum evaluation intervals control when it reviews completed turns; meaningful developments can bring a check forward after the minimum. The current UI offers minimum 1–50 turns, maximum 1–100 turns, and an open-thread limit of 1–12. Keep the maximum at least as large as the minimum.

Threads and diagnostics

Inspect a thread’s premise, known story facts, possible next signs, hidden truth, and planning status. You can update planning status where offered. These views can reveal surprises. Changing a private status does not make an unwritten event canon.

Diagnostics can show the last assessment, scene assessment, direction delivery, queued instruction, and story pressure. Use them when planning feels wrong, rather than reading them as compulsory homework after each turn. Pressure is a timing preference, not a requirement to interrupt a scene.

Drafts, publishing, and reader permissions

Save changes keeps your editable draft. Publish scenario or Publish update makes the relevant version public. Make private removes public availability through the supported visibility flow. Check the status after saving; a draft save and a published update are not interchangeable.

Use the visibility panel and the save/publish actions together. The desktop editor groups the action buttons below Creator Permissions in Scenario Details; other tabs keep the actions available in the footer.

Choose what readers see

• Hide backstory: keep the authored background/plot setup out of the ordinary reading view.
• Hide instructions: keep storyteller guidance out of that view.
• Hide authored lore details: readers can still see permitted card images, names, summaries, relationship trackers, and records added during play. Lore created later remains visible.
• Introduction: always visible in these section-privacy controls.
• Allow comments: control new comments and edits. Closing comments does not automatically erase existing comments.
• Allow customization: let a reader create a private editable copy.

Privacy and comment choices take effect for readers when published. Review the published state and test as a reader when possible. Your private editor, a published snapshot, and an already-saved playthrough are distinct versions; do not assume editing one silently rewrites all the others.

A practical playtesting checklist

1. First impression: does the cover crop well, does the description make sense, and is the introduction readable on a phone?
2. Player identity: does {{user}} become the selected persona, and do playable cast choices behave as intended?
3. Opening: does the first message leave a meaningful choice instead of deciding the player’s response?
4. Continuity: do names, locations, starting relationships, and important rules remain consistent over several exchanges?
5. Relevance: do location anchors and lore triggers make sense in and outside the intended location?
6. Privacy: are secrets and hidden setup absent from the reader-facing summary and introduction?
7. Scripted events: test before, at, and after the trigger. Test a false condition as well as a matching condition.
8. Time: test dialogue, travel, rest, and a deliberate time skip if Story Clock is enabled.
9. Presentation: test allowed chat modes, multi-character blocks, header wrapping, images, and long names.
10. Recovery: know where model choices and memory recovery live before you need them.

Private creator testing is useful without inflating public play activity. Test with deliberate, small actions before generating a long run; provider calls can cost money.

Providers, models, and defaults

A provider is the service receiving an AI request. A model is the particular engine used for a task. A saved model profile is your reusable configuration for that task and connection.

Set account defaults in Providers & models. Open Providers and models for this chat to override them for one playthrough. Choosing “Use my account default” delegates that task to the account selection; other saved runs keep their own choices.

Advanced story preferences

The account settings include Use the context helper and Show relationship changes, along with response length and memory/lore limits, including lore before memory begins and lore after memory begins. These affect how much context and output the system aims to use. Larger settings can increase provider usage and can exceed a model’s limits; more context is not automatically better context.

A site membership, an invite code, and provider credits are separate. Follow the current provider and membership FAQ for setup. Provider catalogs, prices, availability, and rate limits can change. Use the provider’s current information for purchasing decisions.

Keep API keys in account provider connections, never inside public lore or a prompt template. If you change a model for one task, it does not automatically change all the other tasks.

Common workflows

Troubleshooting

If you need help, include the page, action, time, and error text. Remove API keys, private setup links, passwords, and unrelated personal information from screenshots. Contact support@randomsaga.com.

REFERENCE / PLAIN ENGLISH

Key terms

Account / member profile

Your site identity and public creator page. Separate from the persona you play in a story.

Scenario

The authored starting world: setup, cast, lore, instructions, artwork, and supported options.

Draft

The creator’s saved editable work, which may differ from the public version.

Published snapshot

The scenario version made available to readers through publishing.

Playthrough / run / session

A saved conversation and its own evolving story state.

Turn / exchange

A player prompt and the associated assistant response and committed changes.

Canon

The chosen committed history used for this run’s continuity.

Re-roll / variant

Another candidate version of an assistant response.

Branch

A separate run continuing from a selected earlier response.

Restart

A new run from the scenario’s original setup rather than the current run’s accumulated history.

Dynamic restart

A restart using a newly generated opening that you preview and select.

Alternate beginning

An opening the creator has authored for players to choose.

Persona / {{user}}

The identity controlled by the player in the current run.

NPC / cast member

A story character generally controlled by the storyteller, unless offered as playable.

Lore card

A reusable description of a person, place, item, rule, quest, or other continuing subject.

Memory

A stored summary of established story developments.

Chapter / saga

Increasingly broad groupings of remembered story history.

Context

The instructions and selected story information sent to a model for a request.

Context budget

The space available for that information; it is not unlimited.

Token

A provider’s unit for processing text. It is not the same as one word or one character.

Director’s Note

Private active direction for a particular playthrough.

Commander

A planning role for threads, pacing, agendas, opportunities, and consequences.

Context Director

A model role that helps select optional context for the next response.

Visual Direction

A model role that helps turn a story scene into an image description.

Thread

A possible ongoing storyline in Commander’s planning, not automatically an established fact.

Story Clock

The scenario’s saved in-world date and time.

Header variable

A changing value displayed through a placeholder in a decorative assistant header.

Trigger

A relevance cue for lore or a condition for an event; the meaning depends on the control.

Proximity anchor

A location that makes a card eligible there and in its descendant locations.

Story Secret

A private story fact with an initial knower, distinct from ordinary shared information.

Fact / belief

What is established in the story versus what a particular character thinks is true.

Customization

A permitted private editable scenario copy, separate from the creator’s original.

Remix

An authoring workflow that proposes a new private draft from a saved scenario and requested changes.

API key / BYOK

A credential for your own provider account; “bring your own key.” Keep it private.

Provider / model / saved profile

The service, the selected AI engine, and your reusable configuration for a task.

Website, desktop, and availability

This guide is written for the Random Saga website. The related Windows desktop app shares story-engine concepts, but menus, account connections, transfer tools, diagnostics, and storage behavior can differ.

• The website exposes the eight play commands listed in this guide.
• Import/export and file-transfer controls depend on permission. Some website export controls are intentionally owner-only; this guide does not assume ordinary members can export files.
• Standard, RPG, Visual Novel, and combined chat presentations depend on the options offered by the current scenario.
• Exact provider pricing, model names, rate limits, storage quotas, and membership availability are managed separately and may change.
• Profile handles and display names can differ. A public handle does not change the email address used to sign in.

Still under review: a full illustrated RPG rules reference, exhaustive provider-by-provider tuning examples, and a separate desktop walkthrough are not included in this edition. The feature instructions above cover the verified website controls; those additional references should not be treated as available features or promised release dates.