I'm not sure I need c++ code? I program in c# in unity, or javascript, I'm a game designer first lol I only dabble in code.

BUT I made some breakthrough doing that exercise:

I came to realize something, It's not a character behavior code, it's a SCENE behavior code. The equivalent would be, as kept telling but not realizing fully, branching dialog sequence, in other game, except of text you have whole actions and behaviors. Joint actions between character and options, are decided by gameplay events, during phases of the sequence. Obviously that was dangling every time I told about why it was different from character behavior, but I hadn't realize the implications yet.

It change the perspective on how to organize the code, it's a scope problem. Some data currently attributed to character, aren't for the character, but describe the SCENE states or transition from scene to another. That is SCENE contains character's behaviors, but aren't character behavior themselves, they direct character, and thus need specific encapsulation. That's why there was many characters within some branch of behavior, because it's misnamed and mis categorized.

Let's look at a mocked bath mis categorized "behavior", not using a joint character scene (no multiple character at the same time), assuming it's the yandere simulator game as a reference:

0. is triggered by being dirty events

1. go to communal bath

2. go to locker

3. change cloth to swimsuits

4. take the bath

6. go to locker

7. change back to normal cloth

8. exit the communal bath

This would constitute the basic behavior.

Context:
The true purpose of the bath scene isn't to make the character realistic, but to offer gameplay opportunity in the game of social stealth and manipulation, it's the "level". That is the Dirty events is created as opportunities to move or remove characters from a place to another place. For example, the locker allow you to tamper with character belonging and do action like put a letter, stole the phone, stole the cloth, plant evidences, etc ...)

Actual (mocked) code is more structured like that, the (isX) denote easily added "if-cards" to create variants per character/persona (not joint behaviors) :

0. is triggered by being dirty events

(is rich girl: rage 1mn about the clothes, change mood to angry)

(is fragilePersona: start crying, change mood to sad)

(is nemesis: look around suspiciously, mood change to vigilance)

(is idiot AND judgementalPersona nearby: judgemental.talk, play embarassed animation)

1. go to communal bath

(is rich girl: call her bodyguard to follow her on the way)

(is rich girl AND is arrived at communal bath: the guard get posted at the entrance, intimidate anyone passing nearby)

(is nemesis AND arrive at communal bath: slowly push the door, scan the room, close the door carefully, tapped a bell to the door)

2. go to locker

(is rich girl: lament the cloth)

(is nemesis: open the locker carefully, double check the environement and inspect inside the locker)

3. change cloth to swimsuits

(is rich girl: look at the mirror to flatter herself, change mood to normal)

(is nemesis: tapped a bell inside the locker, pick the knife, close locker's door slowly)

(is idiot: look at the mirror do funny face and poses for a while)

4. take the bath

(is fragile: cry during bath)

(is nemesis: submerge whole body to hide the knife)

(is idiot AND time remaining is small: do hurry bath)

6. go to locker

(is nemesis: removed the tapped bell from locker)

7. change back to normal cloth

(is nemesis: removed the tapped bell from door, open slowly the door, scan the environment)

8. exit the communal bath

(is rich girl: the guard follow her to next place)

MISC interruptions and branches.

(is nemesis AND bell sound AND 3 < phase < 7: Speech("I was expecting you"), change to fight mode)

Letter at locker:

(is nemesis: dismiss and toss to trash)

(is rich girl: mood set to angry)

(is fragilePersona: mood set to scared)

(is idiot: Mood set to concerned)

Phone stolen: [...]

Evidence planted: [...]

Clothes stolen: [...]

Player detected: [...]

end.

Using the perspective of SCENE scope rather than CHARACTER scope, this bath SCENE, should be encapsulated as its own objects with it's own local variables and method that manage the flow. SCENE are self contain context.

This scope issue reveal that, many old character behavior where part of a common scene, that is when I needed context to track multiple behavior, have joint hard coded behavior, and many of single use variable, they were scene scope elements. Having scene as concept ties up these thing together.

Which mean I can now introduce new concepts to generalize the scene as structure (yandere simulator as an example):

ROLES:

these are scene level behavior, character are elected to be in a role during the scene that define their behavior within that scene. For example you can have a character see a corpse, go into the REACT TO MURDER scene, if no one has taking the role, get set to REPORTER, then find a teacher to investigate, said teacher taking the role of INVESTIGATOR. Then call the police if evidence are found. Character no longer need contain behavior of a scene, they will take a reference to the scene and follow the script.

PHASES:

Basically it's the ordering of behavior, controlled by flow variable, in actuality it's the if tree. For example the REACT TO MURDER scene, would have approximately: react to corpse, find teacher, follow teacher, wait for teacher, exit the scene.

TRACKS:

Basically it's the way to encode the multiple phases in a scene, it's likely that phases are tied to roles, TRACKS would be parallel phases per role, it is to be noted, it's possible for character to change role mid sequence (for example, a fight can have people waiting and one person attacking, rotating attacking and waiting role). They can be seen as sub scenes of sort.

SCENE STATE: track data and flow control for the scene.

SCENE METHOD: The scene can have extra computation to control the flow of a scene. For example rotating who is attacking in a fight.

INTERRUPTIONS: basically the exit of the sequence, lead back to the common simulation or another scene.

Phases and tracks are also the basis for addressing, which allow to implement per character override of behavior like in the bath scene above. Also scene being distinct entity help coordinate agents more easily, for example, there is ONLY one reporter at the time in REACT TO MURDER scene, instead of doing code judo, when a character enter the scene, it checks if reporter slot is already taken, previously, the ai manager was used as an overall container, which lost the context.

There is no real way to define the scope of a scene from another scene or even tracks and phases, or from generic social practice, the bath scene is a social practice or a story scene? The difference is left to the author to decide. It's possible to have an uber scene that could be break into sub scene, but is sub scene can be a concept? Scene is a useful encapsulation of behavior anyway. Tracks can be seen as partial implementations of sub scene too.

Using these observation and generalization, I can break up and reorganize the code into a new architecture where I break responsibility further:

- The global ai manager,
is stripped from some responsibility and is merely the manager of sub module. It may hold global generic behavior (like talking), but no longer track agents.

- The social area objects,
hold by ai manager and track characters. Basically they hold area based "scene" called "social practice" (idea borrowed from Versu), for example the school hold practice like going to class, practicing sports, doing club activity. Another social area could be the mall, where "going to class and doing club activity" do not make sense. This represent the basic level background simulation.

- A story manager,
which hold the structure of scenes that implement the progression of plots based on player's action and character states. It might inject Scene in social area to perform. For example recording evidence in the REACT TO MURDER scene would be stored here.

- A character sheet object,
that implement the basic data of a character, such as appearance, stats and specific animations.

- A character script objects,
that encapsulate the character sheets and the scene override of that character (like isX in the BATH example). The motivation in separating with sheets, is to be able to reuse character in different story.

- An ACTOR agents,
there is no longer a character object, actor takes a sheets to define their appearance, the stats to perform actions, and animation to display behavior. They also have a set of generic behavior, such as moving and playing animation, and hold the mutable states of the character. But the behavior are now injected by higher structure such as story, character scripts and social area objects, this can be implemented in many way (ECS and all), but for now I just keep a reference to these structure and call their behavior function from the character's state. This mean, put the character in a mall or school, at a certain story point, and it would behave accordingly without modifying the actor.

This makes editing (authorship) collected in a a few places instead of many characters. First you start with defining character or you set social areas, then you write up the story behavior, then you specify character override relative to the story.