OpenSpace 2.0: main features
Posted: 12 Feb 2010, 09:04
Here we go with a brief description of the main features of OpenSpace 2.0. A more refined list will be published once the final release will be available.
Under the hood
[√] OpenSpace server-side extension: now OpenSpace features its own Java extension, used to handle the map loading/updating process (see "Runtime map editing"). The extension class can be extended to add your application logic and/or integrate the OpenSpace server-side logic (for example: load map data from a database instead of file, validate map saving, filter inventory items, etc).
[√] New map loading process: OpenSpace takes care of joining the SmartFoxServer room selected by the developer and load the associated map via socket in order to keep the right room-map alignement.
[√] Map loading and rendering processes are kept separate and executed by separate methods: in this way, after loading a map OpenSpace can tell the application which external swf libraries are needed for the rendering step.
[√] Multi room join is now supported: you can have an avatar on a map and at the same time join a game room.
[√] New compact JSON format implemented in both the Editor and the Engine for map data import/export operations.
[√] OpenSpace Engine distributed both as Flash CS3 (and above) component and as native Flex Builder 2 (and above) component.
Viewport controls and visual aspect
[√] Viewport pan: viewport can be moved around in any direction by any distance, regardless of the avatar position.
[√] Viewport zoom: zoom feature fully re-engineered, now allowing full map interaction (viewport pan, scrolling on avatar movement, etc) in both zoomed-in and zoomed-out states. Tile coordinates and offsets (see next feature) can be passed to center the viewport on a specific tile while zooming.
[√] Enhanced viewport centering: additional offset parameters allow fine-grained control over the viewport repositioning.
[√] By default all viewport movements (pan, zoom, center) show the map scrolling animation. Camera speed and its easing equation, blur effect, zoom duration and its easing equation can be controlled by means of configuration parameters. Animation can also be disabled: in this case a static fade transition is displayed (duration and color are configurable). Default behavior can be overridden at runtime by means of a specific flag passed to the viewport related methods.
[√] By default all viewport movements are limited to the map boundaries (defined by the union of the tiles and background bounding boxes. Map boundaries can be ignored if needed by means of a specific flag passed to the viewport related methods.
NOTE: in case viewport exceeds the map limits (real or custom ones — see next feature), the map is centered with respect to the viewport, and the pan / zoom / center methods have no effect. Horizontal and vertical limits are handled separately.
[√] Custom map limits can be defined at runtime by means of a rectangle acting as a virtual map boundary to limit the camera movement.
NOTE: the rectangle x,y origin is measured with respect to the map grid 0,0 coordinates, as displayed in the following picture:
[√] Dynamic viewport resize at runtime.
[√] Fading effect during map transitions fully customizable (duration and easing equation).
[√] "Smart" foreground behavior: if the foreground is split into two or more parts, those outside the viewport are not rendered, to improve scrolling performance.
Runtime map editing
[√] Users can now enter EDIT MODE to make changes to the current map. When entering EDIT MODE, standard user interaction is disabled and avatars are removed from the scene. When EDIT MODE is left, map changes (if any) are submitted to the server-side extension which takes care of saving them and sending a notifications to the clients connected to the SmartFoxServer room linked to that map. These clients allow normal map interaction until the map update notification is received, in which case the map must be reloaded to get the latest version.
[√] Click a map item (tile and supertile) to select it. Only tile/group instances with an inventory ID assigned inside the OpenSpace Editor can be selected.
[√] Fully customizable map item selection highligther: a custom DisplayObject can be passed to OpenSpace to be used as item selection highligther. When a map item is selected, its data is passed to the selection highligther class (a specific interface must be implemented).
[√] Drag items from an external source and drop them on the map. Drag operations are handled by OpenSpace directly.
[√] Drag map items in a new location on the map, or drag them outside the map to remove them.
[√] Tiles can be flagged inside the Editor so that they do not accept a drop action, in order to avoid incongruent stacking of items (for example a table above a lamp).
[√] During drap&drop operations, tiles give a visual feedback highlighting areas where drop is allowed or not. Highlight color and alpha values are customizable.
Additional informations on runtime map editing
1) Runtime map editing is tightly integrated with the OpenSpace inventory system described next.
2) Realtime map editing (each single map change immediately shows up on the other clients, without the need to reload) is not supported.
3) OpenSpace doesn't implement a default authorization control system to prevent unauthorized map editing actions. Implementing the preferred method to allow a user initiate the editing process on the client-side is up to the developer. A possible high-level workflow could be:
- user clicks on a button to enter his own home (for example): a custom request is sent to the application' server-side extension (usually extending the default OpenSpace extension);
- if this is the first time the user enters his home,on the server-side a map file is generated by duplicating a template (the empty home) built with the OpenSpace Editor by the map designers;
- a SFS room is created (where the user is set as owner) and the map is assigned to it by means of room variables;
- user is joined to the newly created room and the map is loaded by OpenSpace;
- on the client-side, user clicks on a button to start editing;
- a check has to be done — for example by means of a custom extension call — to be sure that the user is the 'owner' of the room: if yes, editing is allowed.
On the server-side, a specific OpenSpace extension method can be overridden to validate the 'save map' action depending on the user submitting the map changes and the related SmartFoxServer room. So the last step in the previous flow could be:
- on the server-side, when the 'save' action is received, an additional check is made to be sure that the user submitting the changes is the room owner.
Also, the OpenSpace Editor allows a map to be flagged as non-editable to further prevent editing of maps that are not supposed to be edited by anyone. This flag is checked both on the client-side (when entering the EDIT MODE) and on the server-side (when submitting map changes).
Inventory
[√] In order to add new tiles/supertiles to a map, an inventory containing the available items is loaded. The OpenSpace Engine returns a list of inventory items with their properties, allowing developers to organize and display them without restrictions. The API also feature a specific method to retrieve a graphical representation of an inventory item.
[√] The OpenSpace Editor features a new sub-editor to build inventory items starting from tiles and supertiles.
[√] Up to 8 tiles/supertiles can be combined in one single inventory item in order to allow items rotation during runtime map editing.
NOTE 1: rotation is not available for items already placed on the map; the required rotation angle must be selected before dragging the item on the map.
NOTE 2: tiles and supertiles can't be mixed in the same inventory item.
[√] Additional custom properties can be defined inside the Editor, to be associated with the items (for example the item category, name, price, etc).
[√] Custom parameters can be passed to the server-side extension when requesting the inventory to OpenSpace, so that a user-specific filtering can be applied before the extension sends back the inventory to the client.
[√] Additional custom properties can be associated with the inventory items at runtime, in the server-side extension, before sending the inventory to the client.
[√] Inventory can be loaded independently of the currently loaded map, to be used in different use case scenarios not strictly related to map editing (for example an in-game shop).
Additional informations on inventory
An inventory is strictly related with the maps belonging to the same OpenSpace Editor project, because they share the same skin/tiles/supertiles assets library. This means that maps editable at runtime and the inventory of items that can be placed on those maps must be defined inside the same Editor project.
User interaction
[√] Brand new event trigger system: when editing the skin and tile instance properties inside the OpenSpace Editor, the following triggers can be associated:
- skins and walkable tiles → mouse click/roll over/roll out;
- walkable tiles only → avatar start/stop moving, avatar enter/leave tile
Custom parameters can be associated to the triggers, so that the appropriate action can be performed when the releated event is fired by OpenSpace.
NOTE: In OpenSpace v1.0 avatar movement events are fired by all tiles with an impact on performance in case a lot of avatars are moving around. The new system allows the map designer to set which tiles/skins are specifically demanded for firing events.
[√] In the OpenSpace Editor a flag can be set so that avatar-related triggers work when the current user avatar interacts with the tile only.
[√] OpenSpace v1.0 getMapObject method improved: if multiple instances of the same tile are placed on a map, developers can still access their internal skins by name (while in v1.0 only the last created skin with that name was accessible). Also a new method is available to retrieve an array containing the references to all the skins with the same name on the map (so, for example, if multiple tiles on a map show a lamp, developers can turn them on/off at once by giving the same instance name to their skins).
[√] Mouse and keyboard controllers can be used at the same time; both can be deactivated permanently or even temporarily to inhibit user interaction while 'something' happens (for example a sensor tile could trigger the avatar being sent to a given place on the map: inhibiting the user interaction make sure that the avatar reaches that place).
Avatars
[√] Avatar direction is saved in the user variables along with its position on the map.
[√] Introducing the avatar "state": this information is saved in user variables (for example: 'standing', 'seating', 'dancing', 'sleeping', etc) and differs from the avatar "action" because it is a persistent condition (within the same connection session) that lasts until it is changed again. This allows rendering avatars of the other users correctly when a map is joined.
[√] A secondary avatar, called Ghost, can be created. The Ghost is placed on a layer above the whole map, so that the items it contains (for example avatar balloon and name textfield) are visible even if the avatar is behind an obstacle.
[√] Avatar switch, to change the avatar type on the fly: simply call the createMyAvatar method again.
[√] When centering the viewport on the avatar, its full size is taken into account, not only the size of the tile on which it stands. Additional x/y offsets can be passed too.
[√] A function can be passed to the OpenSpace Engine to validate the user click on a tile. If true is returned, then the avatar start moving.
[√] Improved moveMyAvatar method: a flag can be passed to inhibit the user click until the destination tile is reached.
[√] Change the avatar speed at runtime.
[√] New terrain system: when tiles are created inside the Editor it is possible to assign them a custom 'terrain' id; avatars can be configured so that some terrains are walkable and others not. Also, terrains can cause the avatar speed reduction/increase.
NOTE: an example of use case scenario for the terrain feature is the following. A map contains both land and sea, respectively made of tiles of type 'land' and 'water'. The 'pedestrian' avatar type can't go on the water, but the 'boat' avatar type yes. A click on a specific sensor tile triggers some custom code which switches the avatar type from 'pedestrian' to 'boat' and places it on a tile with terrain set to water, allowing the user to explore new maps previously not available.
[√] Configuration parameters defining the sensor area which causes the viewport to scroll on avatar movement (scrolling start point and scrolling distance) are now split into the four up/down/left/right directions to have separate behaviors.
OpenSpace Editor
[√] New map export system, to generate separate assets library, inventory and map files compatible with the new map loading via socket and runtime map editing system.
[√] Optimized assets library, inventory and map files protocol (JSON is now used).
[√] New external swf manager module, allowing multiple swf files containing skins and backgrounds/foregrounds to be associated to the the same Editor project: in this way skins can be grouped in separate files (for example category based — buildings, furniture, vegetation, etc. — or map based, or else) optimizing the load times at runtime. In fact when a map is loaded, the list of swf files containing the assets used in it is passed to the developer, so that only those files can be loaded instead of one large file containing all the skins for the whole virtual world.
[√] Automatic skin generation always available inside the new swf manager module.
[√] Supertiles are now rendered during drag&drop operations (instead of showing the base area only).
[√] Supertiles are now rendered in the various lists inside the Editor.
[√] Groups drag&drop enabled in the map editor.
[√] Various bug fixes.[/i]
Under the hood
[√] OpenSpace server-side extension: now OpenSpace features its own Java extension, used to handle the map loading/updating process (see "Runtime map editing"). The extension class can be extended to add your application logic and/or integrate the OpenSpace server-side logic (for example: load map data from a database instead of file, validate map saving, filter inventory items, etc).
[√] New map loading process: OpenSpace takes care of joining the SmartFoxServer room selected by the developer and load the associated map via socket in order to keep the right room-map alignement.
[√] Map loading and rendering processes are kept separate and executed by separate methods: in this way, after loading a map OpenSpace can tell the application which external swf libraries are needed for the rendering step.
[√] Multi room join is now supported: you can have an avatar on a map and at the same time join a game room.
[√] New compact JSON format implemented in both the Editor and the Engine for map data import/export operations.
[√] OpenSpace Engine distributed both as Flash CS3 (and above) component and as native Flex Builder 2 (and above) component.
Viewport controls and visual aspect
[√] Viewport pan: viewport can be moved around in any direction by any distance, regardless of the avatar position.
[√] Viewport zoom: zoom feature fully re-engineered, now allowing full map interaction (viewport pan, scrolling on avatar movement, etc) in both zoomed-in and zoomed-out states. Tile coordinates and offsets (see next feature) can be passed to center the viewport on a specific tile while zooming.
[√] Enhanced viewport centering: additional offset parameters allow fine-grained control over the viewport repositioning.
[√] By default all viewport movements (pan, zoom, center) show the map scrolling animation. Camera speed and its easing equation, blur effect, zoom duration and its easing equation can be controlled by means of configuration parameters. Animation can also be disabled: in this case a static fade transition is displayed (duration and color are configurable). Default behavior can be overridden at runtime by means of a specific flag passed to the viewport related methods.
[√] By default all viewport movements are limited to the map boundaries (defined by the union of the tiles and background bounding boxes. Map boundaries can be ignored if needed by means of a specific flag passed to the viewport related methods.
NOTE: in case viewport exceeds the map limits (real or custom ones — see next feature), the map is centered with respect to the viewport, and the pan / zoom / center methods have no effect. Horizontal and vertical limits are handled separately.
[√] Custom map limits can be defined at runtime by means of a rectangle acting as a virtual map boundary to limit the camera movement.
NOTE: the rectangle x,y origin is measured with respect to the map grid 0,0 coordinates, as displayed in the following picture:
[√] Dynamic viewport resize at runtime.
[√] Fading effect during map transitions fully customizable (duration and easing equation).
[√] "Smart" foreground behavior: if the foreground is split into two or more parts, those outside the viewport are not rendered, to improve scrolling performance.
Runtime map editing
[√] Users can now enter EDIT MODE to make changes to the current map. When entering EDIT MODE, standard user interaction is disabled and avatars are removed from the scene. When EDIT MODE is left, map changes (if any) are submitted to the server-side extension which takes care of saving them and sending a notifications to the clients connected to the SmartFoxServer room linked to that map. These clients allow normal map interaction until the map update notification is received, in which case the map must be reloaded to get the latest version.
[√] Click a map item (tile and supertile) to select it. Only tile/group instances with an inventory ID assigned inside the OpenSpace Editor can be selected.
[√] Fully customizable map item selection highligther: a custom DisplayObject can be passed to OpenSpace to be used as item selection highligther. When a map item is selected, its data is passed to the selection highligther class (a specific interface must be implemented).
[√] Drag items from an external source and drop them on the map. Drag operations are handled by OpenSpace directly.
[√] Drag map items in a new location on the map, or drag them outside the map to remove them.
[√] Tiles can be flagged inside the Editor so that they do not accept a drop action, in order to avoid incongruent stacking of items (for example a table above a lamp).
[√] During drap&drop operations, tiles give a visual feedback highlighting areas where drop is allowed or not. Highlight color and alpha values are customizable.
Additional informations on runtime map editing
1) Runtime map editing is tightly integrated with the OpenSpace inventory system described next.
2) Realtime map editing (each single map change immediately shows up on the other clients, without the need to reload) is not supported.
3) OpenSpace doesn't implement a default authorization control system to prevent unauthorized map editing actions. Implementing the preferred method to allow a user initiate the editing process on the client-side is up to the developer. A possible high-level workflow could be:
- user clicks on a button to enter his own home (for example): a custom request is sent to the application' server-side extension (usually extending the default OpenSpace extension);
- if this is the first time the user enters his home,on the server-side a map file is generated by duplicating a template (the empty home) built with the OpenSpace Editor by the map designers;
- a SFS room is created (where the user is set as owner) and the map is assigned to it by means of room variables;
- user is joined to the newly created room and the map is loaded by OpenSpace;
- on the client-side, user clicks on a button to start editing;
- a check has to be done — for example by means of a custom extension call — to be sure that the user is the 'owner' of the room: if yes, editing is allowed.
On the server-side, a specific OpenSpace extension method can be overridden to validate the 'save map' action depending on the user submitting the map changes and the related SmartFoxServer room. So the last step in the previous flow could be:
- on the server-side, when the 'save' action is received, an additional check is made to be sure that the user submitting the changes is the room owner.
Also, the OpenSpace Editor allows a map to be flagged as non-editable to further prevent editing of maps that are not supposed to be edited by anyone. This flag is checked both on the client-side (when entering the EDIT MODE) and on the server-side (when submitting map changes).
Inventory
[√] In order to add new tiles/supertiles to a map, an inventory containing the available items is loaded. The OpenSpace Engine returns a list of inventory items with their properties, allowing developers to organize and display them without restrictions. The API also feature a specific method to retrieve a graphical representation of an inventory item.
[√] The OpenSpace Editor features a new sub-editor to build inventory items starting from tiles and supertiles.
[√] Up to 8 tiles/supertiles can be combined in one single inventory item in order to allow items rotation during runtime map editing.
NOTE 1: rotation is not available for items already placed on the map; the required rotation angle must be selected before dragging the item on the map.
NOTE 2: tiles and supertiles can't be mixed in the same inventory item.
[√] Additional custom properties can be defined inside the Editor, to be associated with the items (for example the item category, name, price, etc).
[√] Custom parameters can be passed to the server-side extension when requesting the inventory to OpenSpace, so that a user-specific filtering can be applied before the extension sends back the inventory to the client.
[√] Additional custom properties can be associated with the inventory items at runtime, in the server-side extension, before sending the inventory to the client.
[√] Inventory can be loaded independently of the currently loaded map, to be used in different use case scenarios not strictly related to map editing (for example an in-game shop).
Additional informations on inventory
An inventory is strictly related with the maps belonging to the same OpenSpace Editor project, because they share the same skin/tiles/supertiles assets library. This means that maps editable at runtime and the inventory of items that can be placed on those maps must be defined inside the same Editor project.
User interaction
[√] Brand new event trigger system: when editing the skin and tile instance properties inside the OpenSpace Editor, the following triggers can be associated:
- skins and walkable tiles → mouse click/roll over/roll out;
- walkable tiles only → avatar start/stop moving, avatar enter/leave tile
Custom parameters can be associated to the triggers, so that the appropriate action can be performed when the releated event is fired by OpenSpace.
NOTE: In OpenSpace v1.0 avatar movement events are fired by all tiles with an impact on performance in case a lot of avatars are moving around. The new system allows the map designer to set which tiles/skins are specifically demanded for firing events.
[√] In the OpenSpace Editor a flag can be set so that avatar-related triggers work when the current user avatar interacts with the tile only.
[√] OpenSpace v1.0 getMapObject method improved: if multiple instances of the same tile are placed on a map, developers can still access their internal skins by name (while in v1.0 only the last created skin with that name was accessible). Also a new method is available to retrieve an array containing the references to all the skins with the same name on the map (so, for example, if multiple tiles on a map show a lamp, developers can turn them on/off at once by giving the same instance name to their skins).
[√] Mouse and keyboard controllers can be used at the same time; both can be deactivated permanently or even temporarily to inhibit user interaction while 'something' happens (for example a sensor tile could trigger the avatar being sent to a given place on the map: inhibiting the user interaction make sure that the avatar reaches that place).
Avatars
[√] Avatar direction is saved in the user variables along with its position on the map.
[√] Introducing the avatar "state": this information is saved in user variables (for example: 'standing', 'seating', 'dancing', 'sleeping', etc) and differs from the avatar "action" because it is a persistent condition (within the same connection session) that lasts until it is changed again. This allows rendering avatars of the other users correctly when a map is joined.
[√] A secondary avatar, called Ghost, can be created. The Ghost is placed on a layer above the whole map, so that the items it contains (for example avatar balloon and name textfield) are visible even if the avatar is behind an obstacle.
[√] Avatar switch, to change the avatar type on the fly: simply call the createMyAvatar method again.
[√] When centering the viewport on the avatar, its full size is taken into account, not only the size of the tile on which it stands. Additional x/y offsets can be passed too.
[√] A function can be passed to the OpenSpace Engine to validate the user click on a tile. If true is returned, then the avatar start moving.
[√] Improved moveMyAvatar method: a flag can be passed to inhibit the user click until the destination tile is reached.
[√] Change the avatar speed at runtime.
[√] New terrain system: when tiles are created inside the Editor it is possible to assign them a custom 'terrain' id; avatars can be configured so that some terrains are walkable and others not. Also, terrains can cause the avatar speed reduction/increase.
NOTE: an example of use case scenario for the terrain feature is the following. A map contains both land and sea, respectively made of tiles of type 'land' and 'water'. The 'pedestrian' avatar type can't go on the water, but the 'boat' avatar type yes. A click on a specific sensor tile triggers some custom code which switches the avatar type from 'pedestrian' to 'boat' and places it on a tile with terrain set to water, allowing the user to explore new maps previously not available.
[√] Configuration parameters defining the sensor area which causes the viewport to scroll on avatar movement (scrolling start point and scrolling distance) are now split into the four up/down/left/right directions to have separate behaviors.
OpenSpace Editor
[√] New map export system, to generate separate assets library, inventory and map files compatible with the new map loading via socket and runtime map editing system.
[√] Optimized assets library, inventory and map files protocol (JSON is now used).
[√] New external swf manager module, allowing multiple swf files containing skins and backgrounds/foregrounds to be associated to the the same Editor project: in this way skins can be grouped in separate files (for example category based — buildings, furniture, vegetation, etc. — or map based, or else) optimizing the load times at runtime. In fact when a map is loaded, the list of swf files containing the assets used in it is passed to the developer, so that only those files can be loaded instead of one large file containing all the skins for the whole virtual world.
[√] Automatic skin generation always available inside the new swf manager module.
[√] Supertiles are now rendered during drag&drop operations (instead of showing the base area only).
[√] Supertiles are now rendered in the various lists inside the Editor.
[√] Groups drag&drop enabled in the map editor.
[√] Various bug fixes.[/i]
