Demo: Unitary Session
Starting from version 3.3, our server-side supports Unitary Session, enabling us to perform many operations without the need to restart the session.
Previous Logic:
- Obtain a token using the API key/secret.
- Generate parameters for
LoadScene
(UserRequest, ClientRequest, Capabilities, etc.). LoadScene
by inputting the newly generated token and requests, along with the scene's full name, to return aLiveSessionID
andagentID
for each character in the scene.StartSession
using the obtainedLiveSessionID
.
As seen from the previous logic, modifying any game parameters required disconnecting and restarting the session. Also, character agentIDs
, often cached in memory for easier reconnection, would cause server errors and disconnects if they didn't match the current scene's characters.
Logic After Unitary Session:
- Obtain a token using the API key/secret.
StartSession
directly with the token.- After establishing the session, load parameters such as UserName, ClientInfo, Capabilities, and even Scene Info.
With the new server-side logic, we can dynamically adjust parameters in the session on the client-side, allowing for a more user-friendly connection with the server.
Runtime Player Name Change
We've introduced a new Config menu in the PlayerController
, accessible by default with the ESC
key. Upon opening, it displays current session information, allowing players to change their character names. Changes are immediately reflected in the characters' recognition of the player, eliminating the need to close and restart the session.
Runtime Capabilities Change
As demonstrated, turning off the Narrative capability results in characters no longer generating Narrative Action information (indicated in italics).
Runtime Scene Change
Yes, we can now switch scenes within the same session, introducing characters that weren't in the original scene. After the switch, the original character, Alice, won't be able to interact, but Amy from the new scene will be available for interaction.
Auto-Connection Update
For the server side, if no data is received within two minutes, it will proactively terminate the connection due to inactivity, thereby saving bandwidth resources.
However, for a game, it's quite normal not to interact with NPCs within a two-minute frame.
Previously, on the Unity side, there was an AutoStart
parameter that, if set, would automatically reconnect to awaken the session upon disconnection due to session inactivity.
With the advent of Unitary Session, which provides extended data preservation and the ability to dynamically adjust many parameters, we have also revised the auto-connection mechanism from version 3.3 onwards:
-
AutoStart has been removed. Going forward, if the server-side disconnects due to inactivity, we will not automatically reconnect immediately, thus saving costs.
-
Now, a connection will only be established when the user first sends a message. For example, a Text message, a trigger event, or a ControlEvent such as
StartAudio
(typically, this happens automatically when a character is selected). -
InworldCharacter will no longer manage the agentID. Users won't need to use agentID as the target to send Text/Audio etc. In the API, the character's ID (also known as BrainName, Character Full Name) will be used as the target parameter. The Unity Inworld SDK will automatically manage and invoke these corresponding agentIDs for communication.
This adjustment means that the server will still disconnect after two minutes of inactivity, as it always has, but the client's approach to re-establishing a connection will now be more context-sensitive and efficient.