[X3D-Public] games > state carryover on anchor between scenes

doug sanden highaspirations at hotmail.com
Wed Oct 16 08:51:16 PDT 2013

>>>>> Q. for multi-scene games, how / where is game state -such as scoring, level, persona- carried over to subsequent scenes after an Anchor? Is there an SAI field on the Browser that can be set with (name,value) pairs from Script nodes/javascript, and if so which field(s)? Or is there another paradigm?

Q1. with subscenes-as-Protos do you instance them on demand and add routes to them, all from javascript?


Draft Summary: Holding Game State Across modules/levels/rooms/scenes
Possibility 1:
Master-Scene holds state for sub-scenes

Method A: Inlines 
(tested, preferred if viewer supports IMPORT/EXPORT)
Using prototypes (or inlines), with well defined interfaces, and load by:
a) refreshing/changing the URL on an inline or ExternProto to trigger load or
b) pre-parsing and using a Switch node on instances
For Inlines - use IMPORT/EXPORT and pre-route to the IMPORTs

Method B: Subscene as programmably created nodes
(common practice if no main/subscene state interchange, or viewer supports IMPORT/EXPORT)
Browser.createVrmlFromUrl()/createX3DfromUrl() called from javascript brings in sub-scenes to children of group node in master scene. 
- suitable when the interactivity and carryover state is all in the main scene part
- or use IMPORT/EXPORT and pre-route to the IMPORTs as with Inlines
Method C: Scene Handoff
(speculative / not tested)
i) newscene = createX3DfromURL(url) is called first to generate a new X3DScene
ii) then settings are transferred from the current scene to the newscene
iii) then replaceWorld(newscene)

Method D: Programmably adding Proto instances on demand
(should work, sounds do-able)
include Protos for each subscene in your main scene, so they are pre-parsed. Then programmatically create instances on demand in javascript, and create ROUTEs between mainscene the instances (and delete old subscene instances and their ROUTEs)

Method E: ExternProto instancing from javascript
refreshing/changing the URL on an ExternProto before instancing in javascript. If it works, this would create a new instance as with E.Protos, and you would need to programmably generate ROUTEs to it in javascript (and remove routes to a previous/deleted instance).

Possibility 2:
Browser object holds state between peer scenes
(would require change to SAI specifications for X3DBrowser and new support from viewers)
Method: Browser.crossSceneState
an SAI field or function on the Browser object that can be set from Script nodes, 
- perhaps an array of strings or property list called 'crossSceneState':
Anchor/LoadURL or createX3DfromURL + replaceWorld brings in peer scenes
- each peer scene keeps the Browser.crossSceneState updated
Possibility 1, Method B:
Q. Can programmably created nodes ie from createX3DFromUrl refer to DEF nodes not within its own subscene? 
A. No - DEF names outside the own subscene cannot be accessed directly (some Browsers have exceptions to this rule and allow to access DEF names of the "master scene" from some "sub scene" under some circumstances, but generally this is not possible). Use IMPORT/EXPORT.

Q. Could we somehow find a node to talk to by crawling the scenegraph?
A. Possible but not recommended. The method Browser.createVrmlFromUrl() delivers an MFNode with all top level nodes of the loaded scene, so  you could define "the nth toplevel node has this and that interface function" and setup dynamic routes. However some browsers invert the order of the loaded nodes.

Possibility 2
Q. can I just add more properties to X3DBrowser object from javascript ie Browser.mystate = new array()? If so would it stick around after an Anchor?
A. No. You can add it. But each Script node gets a separate copy of the global context, so simply adding properties to objects does not survive between Script nodes in the same scene file, nor between successive loaded scenes. The specs and viewer support would need to change so a specific property is available on the Browser for persisting. 		 	   		  

More information about the X3D-Public mailing list