EvolvingWorld is a useful paper for storyboard work because it treats character change and world change as the same problem.
Most role-play agents start with a persona card and try to stay in character. That helps with style, but it is too weak for long stories. A character is not static. A room is not static. Relationships, motivations, locations, objects, and social rules all move as the story unfolds.
The paper's answer is an open-schema framework where a Character Agent and an LLM-based World Model update each other over many scenes. For Story2Board, that is the right direction: a storyboard system should not only remember what a character looks like. It should remember what happened to them and what changed in the world around them.
The paper in one sentence
EvolvingWorld simulates literary worlds by coupling open-schema character profiles with open-schema world state, then evaluates whether both stay coherent across long multi-scene trajectories.
That makes it different from ordinary role-play benchmarks. The target is not a good single reply. The target is sustained development. A character can revise a belief. A location can change after an action. A social order can create pressure on a scene. Those facts should persist.
The paper builds its benchmark from 57 public-domain books, producing 138,596 supervised training samples and 222 test snapshots. It defines 7 trainable tasks and evaluates trajectories with 10 dimensions and 20 metrics.
Open schema is the important phrase
Fixed schemas are tempting. You define fields such as personality, goal, emotion, memory, location, and inventory. Then every story has to fit into those fields.
The paper argues that literary worlds do not work that neatly.
A detective story may need investigative habits. A Victorian domestic drama may need social standing, marriage norms, reputation, and family obligation. A fantasy story may need magic rules. A school story may need class hierarchy. If every world uses the same slots, the system misses what makes a story specific.
EvolvingWorld lets the model infer the relevant dimensions from the book.
For Story2Board, that matters because visual continuity is genre-specific too:
| Story type | State that may matter |
|---|---|
| detective scene | clue possession, suspicion level, room access |
| romance scene | relationship tension, emotional distance, social pressure |
| action sequence | injuries, weapon state, escape routes |
| courtroom drama | evidence status, authority, witness confidence |
| fantasy scene | magic rule, oath, curse, location boundary |
The product lesson is not "never use schemas." It is: schemas should be flexible enough to track the story's own logic.
Two modules, one evolving story
EvolvingWorld separates the work into two coupled modules:
| Module | What it owns |
|---|---|
| Character Agent | profiles, hidden evidence, motivations, dialogue, thoughts, actions |
| World Model | global state, location state, entity state, scene selection, turn orchestration |
The Character Agent does not only speak as a character. It updates the character after scenes. The World Model does not only provide background. It chooses scenes, locations, speakers, and world-state updates.
That split is close to what a storyboard system needs. A co-director should know both sides:
| Storyboard question | Module-like responsibility |
|---|---|
| Why does this character enter the shot? | character motivation |
| What has changed since the last scene? | world state |
| Who should speak or act next? | turn orchestration |
| Which location makes sense now? | scene planning |
| What should persist into the next panel? | profile and location update |
This is also why we keep returning to structured state in our paper reviews. GEST-Engine uses an event graph as a video contract. EvolvingWorld uses character and world state as a story contract.
The seven-task pipeline is very storyboard-shaped
The simulation pipeline has 7 tasks:
| Task | Plain-language job |
|---|---|
scene_cast | decide whether there is a next scene and who participates |
location_scenario | choose location and scenario |
motivation_update | set each participant's motivation entering the scene |
next_character | choose who acts or speaks next |
interaction_gen | generate thought, speech, and visible action |
world_update | update global or location state after an interaction |
character_update | update profiles and hidden trackers after the scene |
That sequence feels natural for Story2Board:
| EvolvingWorld task | Story2Board equivalent |
|---|---|
| cast selection | choose characters in the beat |
| location scenario | pick the setting and dramatic setup |
| motivation update | write the shot's emotional driver |
| next character | decide action-reaction flow |
| interaction generation | write dialogue/action beats |
| world update | update props, location, and social facts |
| character update | update intent, relationship, and visible state |
The key is that generation and state update are interleaved. A system that generates 10 storyboard panels first and checks continuity afterward is already late. The state should update as the sequence develops.
The hidden tracker solves a real writing problem
One of the better design choices is the hidden tracker.
The paper notes that different character dimensions evolve at different speeds. Mood may change quickly. A stable personality trait should require accumulated evidence. If the model rewrites a character after one line of dialogue, the character becomes unstable.
So EvolvingWorld stores weak or emerging evidence separately before promoting it into the visible profile.
That maps directly to storyboards. A single shot should not rewrite a character. But a sequence can.
| Evidence type | Store where |
|---|---|
| a nervous glance | hidden tracker |
| repeated avoidance | hidden tracker with stronger weight |
| explicit confession | profile or relationship update |
| public betrayal | character and world update |
| destroyed prop | location/entity update |
This is a practical way to avoid both extremes: static characters who never learn, and unstable characters who change because the model overreacts to one moment.
The benchmark measures the right pain
EvolvingWorld evaluates long-horizon behavior, not isolated response quality. The scoring is split into two families:
| Score family | Dimensions |
|---|---|
| Character | character consistency, evolution quality, environmental grounding, interaction quality, motivation generation, instruction compliance |
| World | scene planning, speaker management, world state maintenance, instruction compliance |
The dataset scale is also meaningful:
| Statistic | Value |
|---|---|
| Books | 57 |
| Extracted scenes | 9,763 |
| Interactions | 132,800 |
| Unique characters | 3,311 |
| Unique locations | 1,888 |
| Training samples | 138,596 |
| Test snapshots | 222 |
The results are strongest as a pattern rather than a single leaderboard claim. EW-trained models improve both Character Agent and World Model scores across matched backbones. The comparison with BookWorld is especially clear: EvolvingWorld scores higher on shared metrics, with large gains in profile update fidelity, profile evolution smoothness, motivation quality, scene continuity, and turn organization.
The paper also notes a useful asymmetry: models generally do better at character-agent tasks than world-model tasks. That rings true. Dialogue imitation is heavily represented in training data. Structured world maintenance is not.
For Story2Board, this suggests that world-state tracking should be a product feature, not something we assume the base model will handle automatically.
How this relates to MAGNET, GEST, and WNM
EvolvingWorld sits in the same design family as several papers we have covered:
| Paper | State layer |
|---|---|
| MAGNET | character goals and dynamic world state |
| GEST-Engine | formal event graph for executable synthetic video |
| World Narrative Model | physical production state before video rendering |
| EvolvingWorld | open-schema character and literary world co-evolution |
The difference is that EvolvingWorld is closer to narrative simulation than video production. It does not produce pixels. It produces long-horizon state trajectories.
That makes it useful upstream of Story2Board. Before generating panels, a storyboard system needs to know what the scene means in the larger story, how the character has changed, and what world facts constrain the next shot.
What Story2Board should borrow
The near-term product idea is simple: add co-evolving state under the storyboard.
A Story2Board version might keep:
| State layer | What it tracks |
|---|---|
| character profile | stable identity, relationships, speaking style, dramatic wound |
| hidden tracker | weak evidence that may later become a real change |
| scene motivation | what each character wants entering a scene |
| global world state | rules, social pressure, story-wide constraints |
| location state | room layout, important entities, prop changes |
| continuity review | conflicts between new panels and existing state |
This would make Gemini a better co-director. It could say: "This close-up works emotionally, but the prop state is wrong," or "This character's motivation has shifted enough that the next shot should not stage them passively."
That is the difference between an image generator and a storyboard system.
Where the paper stops
The limitations section is useful.
First, EvolvingWorld models the world as a single objective state. Real characters do not experience the world that way. One person may see the same room as safe while another sees it as hostile. A character may misremember where an object is. Subjective world models would be more realistic, but also more complex.
Second, the world representation is constrained by LLM context length. The World Model tracks important entities, not every object in a location. For visual storyboarding, that means we still need careful compression: keep the details that affect continuity and drop the noise.
Third, the benchmark uses public-domain classics from Project Gutenberg because of copyright. That keeps the dataset legally clean, but it does not cover modern novels, games, fan worlds, or user-created story universes.
Those are real limits. They do not weaken the core idea. They define where the next product work has to be careful.
The product lesson
The storyboard lesson is this: continuity is not only visual memory. It is state evolution.
A useful storyboard tool has to know that a character's fear has hardened into resolve, that a letter box is now empty, that a room still contains the aftermath of a party, and that a relationship has changed enough to alter blocking.
EvolvingWorld gives us a clean vocabulary for that layer: open-schema profiles, hidden trackers, motivations, global state, location state, and trajectory-level evaluation.
For Story2Board, the path is not to simulate every literary world in full. The path is to keep enough evolving state that every storyboard panel can answer a simple question:
What changed, and what must not change?
References
Zong, Q., Guo, Y., Yang, M., Guo, Y., & Song, Y. (2026). EvolvingWorld: An Open-Schema Framework for Co-Evolving Role-Play Agents and World Model in Interactive Literary World. arXiv preprint arXiv:2607.17250. https://arxiv.org/abs/2607.17250