When a fictional Oniichat scene includes more than one supporting character, clarity matters before complexity. Give each speaker a stable name, keep the active cast small and describe who is present before asking for dialogue.
This is a writing convention for a scene you describe in a conversation. It is not a claim that Oniichat has a native group-chat mode, multi-bot controls or a guaranteed ability to track an unlimited cast. You can use the same convention in an ordinary piece of collaborative fiction.
Give the characters different jobs
Two people with different names but identical roles are easy to confuse. Start by identifying what each character contributes to the immediate situation.
In an original ferry-terminal example, Mira is responsible for checking the passenger list. Ren is carrying a crate that has been delivered to the wrong departure gate. Your character wants to find the right boat before the terminal closes.
The difference is practical. Mira can answer a question about a booking. Ren can explain where the crate came from. Neither needs a long history before the scene can begin.
Avoid distinguishing speakers only by appearance. “The person in blue” becomes ambiguous when a coat is removed or the scene changes. A name and a role survive those changes more reliably.
Make a cast note short enough to reuse
Write a small cast note before the scene. Keep private real-world identities out of it.
| Name | Immediate role | What this person knows |
|---|---|---|
| Mira | Checks the departure list | The boat’s scheduled gate |
| Ren | Delivered the crate | The delivery address on its label |
| My character | Needs the correct boat | The booking name and destination |
The knowledge column prevents another common problem: every character suddenly knowing everything. If Ren has not seen the booking, a response should not need him to explain its details. You can ask for the knowledge boundary explicitly, while recognizing that a model may still make mistakes.
Do not expand the note into a complete database. Include only facts that affect the current exchange. If a character leaves, say so and stop including them in every prompt.
Choose one dialogue convention
A simple format keeps the reader from having to infer a speaker from tone alone. For example:
Mira: “Which destination is on your booking?”
Ren sets the crate down beside the bench.
Ren: “The label says Gate Four. I was told to bring it here.”
Use the same label whenever that character speaks. Keep narration separate from quoted speech, especially if the content contains another quoted message or an object with writing on it.
You can request this format directly: “Label Mira’s and Ren’s dialogue with their names. Put visible actions in a separate sentence. Leave my character’s answer for me.” That is a formatting preference, not a special command syntax.
Keep one active location
Rapidly switching between the dock, a café and an office can make a short exchange confusing even for a human reader. Stay in one location until the group makes a choice about where to go.
When you do change location, use a scene cut: “Later, at Gate Four, only Ren and my character are present.” This states time, place and cast in one sentence. It does not require repeating every earlier line.
If a response has a character speak from a place they have already left, correct the stage rather than adding another explanation inside the fiction: “Mira is still at the desk and cannot hear this exchange. Keep the reply with Ren at Gate Four.”
Repair attribution before continuing the plot
A mislabeled line can produce several further mistakes if you immediately respond to its content. Pause to make the correction explicit.
Use a small repair note:
- Which line was attributed incorrectly?
- Who should have spoken it?
- Does the correction change anyone’s knowledge or next action?
If it does not change the story, keep the repair short and continue. If it changes a decision, restate that one decision before moving on. There is usually no need to regenerate an entire fictional history.
Your final check is straightforward: can a reader identify the speaker, the active location and the unresolved choice without rereading the whole conversation? If not, simplify the cast before adding a new character. The scene ledger guide offers a companion method for tracking what the characters carry and promise.
Sources and scope
Oniichat official product, checked October 29, 2026. The ferry scene, cast table and dialogue convention are original editorial examples. No native group-chat capability or tested character-count limit is asserted.