SLGOGP Draft 1/Discuss 1-1 Domains
< SLGOGP Draft 1
Jump to navigation
Jump to search
Revision as of 07:45, 18 March 2008 by Rob Linden (talk | contribs) (adding Talk template, even though it's not technically in the "Talk:" namespace)
This is a talk page. Please sign comments you leave here by putting four tildes (~~~~) at the end of your comment. You might also prefer to click on "Add Topic" to create a visually more pleasing discussion style. For more guidelines, see Talk Page Guidelines. |
- the sentence "The viewer does so from the vantage point of an agent. An agent is persistent identity and persona that interacts in a virtual world. The agent persists and can be interacted with even when the user controlling it (though a viewer) is off-line." might need some clarification in what sort of interactions are meant here. Inventory transfers and the like? [Tao Takashi]
- "The agent persists and can be interacted with even when the user controlling it (though a viewer) is off-line.":
- This has surprised many of us, as up to now the prevailing notion had been that the agent comes into being (based on data in account records) when the client connects, and disappears when the client disconnects. If (conceptually) the agent is now seen as persisting so that off-line operations can still be viewed as interacting with the agent, then
- the distinction between agent and account has been lost,
- the clean interpretation of agent as a proxy for the client has been lost,
- agent now has two different states, and on-line and an off-line one.
- This new definition of agent as a persistent entity seems to bring more trouble than benefit.
- If the reason for the change was that you seek the symmetry of all off-line operations being performed in the Agent Domain, then a cleaner approach to this would be to instantiate the agent whenever an off-line operation is effected. Since this matches what actually happens, and since keeping agents instantiated regardless of login status has dreadful scalability, the cleaner approach also reflects the design of non-toy implementations, which is no bad thing. Morgaine Dinova 21:42, 11 March 2008 (PDT)