"The context is an object, unique per Script, that you can use to store your script data during the script life time. "
“The ctx object unique to each script, and properties we define on it will only be accessible by that script. Some of its properties are shared between scripts. entityData is shared by all scripts on the entity and worldData is shared by all scripts. They are all initially empty, and can be used to store any kind of data”
ContextObject sounds good form some cases like state-machine etc
Use this
That is your context. Our scripts are instances, so they behave like normal object that has this scope, and you can store anything to it, and even more, you can reference that script from somewhere else, and access its values, because it is simply object like the others.
The primary benefit I can see of separated context objects is for some very special cases. Like being able to persist the state of an object and have it return to exactly that state at some point in the future. I’m working on a time travel puzzle game that uses this principle - decoupling the model from the view and therefore being able to save the entire state and replay it at a later moment without getting confused by a lot of other detritus and UI relevant data.
The game idea has you being able to travel back up to a minute into the past and solve puzzles using the actions of your former self. Envisaging a lot of “yous” on screen at once
I guess it’s also good design to separate concerns and certainly makes it easier to have a game run headless on a server.
It’s pretty easy to store data in one of three “contexts”: global, per script object or per script instance.
e.g.
// this data is available globally
window.globalData = {};
pc.script.create("scriptname", function (app) {
// this data is shared between all instances of the script.
var scriptObjectData = {};
var Script = function (entity) {
// this data is only for this instance of the script
this.instanceData = {};
};
return Script;
});
