Optional activatorOptional canvasdepends on canvas Type
Optional canvas"create" => a new canvas is created and attached to the canvas selector object "selector" => it is expected that the canvas selector points to a canvas
Optional defaultSet the path to the activator-path for all worlds.
Example: path to a local class
"path/to/ActivatorClass"
Example: package class (node)
"package/dist:ActivatorClass"
Set it to default (or not at all) to set it to TypeSprite's ManualActivator.
activator overwrites this value
Optional fixedOnly valid if mainloopType is MainLoopType.Fixed.
Optional flags[OPTIONAL] Define any flags that helps to run your game.
Suggestions: "ios", "nativ", "desktop", or "demo" :-)
Optional mainloopIt's possible to have different mainloop behavior and controlls how update() is called.
Optional maxwhen > 0 it will cap the FPS to the given value if the window has lost the fosus. This is useful during development when your laptop starts to scream at you while working on a game.
Optional maxwhen > 0 it will cap the FPS to the given value.
Optional noMeans the mainloop won't start automatically. This has to be done by hand.
Optional noOptional noMeans built-in property-parser won't be set automatically. You can add them by yourself
advanced
Optional noMeans built-in resourceloader won't be set automatically.
advanced
Optional resourceOptional resourceA global path-prefix used for all resources loaded using the ResourceManager.
This is useful when deploying the game into a environment where the paths of the executed javascript code does not match the dev-environment.
Name or list of names the start world.
For a very simple case one can simply set a string.
However, for certain patterns it's useful to start more than one world and in a controlled order.
Example 1: start two worlds at the same time
startWorlds: ["world1", "world2"]
Example 2: start 3 worlds in a controlled order
startWorlds: [["world1"], ["world2", "world3"]]
when world1 is active, world2 and world3 get activated.
Generated using TypeDoc
Use this to optimize activation/deactivation behavior for entities in a world.
Example:
It's possible to overwrite activator that meet the specific needs of a world.
_
Example 1: Imagine having a world that represents a auto-runner-level that only scrolls from left to right. In that case one could have a list of objects, sorted by their x-axis.
_
Example 2: Imagine a top-down-RPG where you like to only have objects active around the camera. Other objects (like NPCs far away) shall be deactive. You could implement an Activator which handles this using a QuadTree and quickly checks bounding boxes against the camera.
See
defaultActivator for format details