OpenSpace logo

Overview » Avatars & pathfinding

In OpenSpace, the avatar creation is in total control of the developer: you just have to create a class which extends the Avatar base class and override its methods. In this way the OpenSpace engine can communicate with the avatar, and you can totally customize its graphical appearance in response to the methods called by OpenSpace, without limitations!

Then, when it's time to make the avatars move around on the map, OpenSpace is totally in charge of this task, featuring an advanced server-side pathfinding algorithm.


The Avatar base class features a number of methods and properties which can be used to setup the initial avatar appearance and to trigger graphical changes during the user interaction. OpenSpace tells the avatar when it should start or stop showing a movement animation (walk, run, etc.), when it should change its direction during the movement, when its graphical appearance (the skin) should be changed, when it should play a temporary custom action (laugh, cry, smile, etc.), when its permanent state* should change (standing, seating, dancing, sleeping, etc.), when a public or private message is received (so that for example a speech bubble can be shown) and more.

OpenSpace can display two avatars for each user: the main avatar and the ghost avatar. The main avatar is the standard avatar which OpenSpace places on the map: it represents a user (a real one or a Non-Player Character too) and can be moved around in the isometric environment, following the z-sorting rules of OpenSpace.

The ghost avatar is an optional secondary avatar which OpenSpace creates on a layer on top of all the map elements (background, tiles, foreground) and which follows the main avatar during its movement on the map. Being on front layer, the graphical assets it contains are always visible, even if the main avatar is, for example, behind a building: it can be useful to display a chat balloon or the avatar name.

Moving on the map

By default OpenSpace features an 8-directions avatar movement, but you can configure it so that only the four diagonal directions are used, and the pathfinding algorithm will adapt itself to this setting.

Avatar movement can be initiated by the player clicking on a target tile, or via code using the API methods. A function can be passed to the OpenSpace engine to validate the user click on a tile. When the movement is started via code, a flag can be passed to inhibit the user click until the destination is reached.

When tiles are created inside the OpenSpace Editor, it is possible to assign them a custom terrain; avatars can be then configured so that some terrains are walkable and others not**. Also, terrains can cause an avatar speed reduction/increase. Also, the avatar speed can be changed at runtime independently of the terrain on which the avatar is standing.


OpenSpace makes use of an extended breadth-first pathfinding algorithm which is able to handle maps featuring different tile elevations, slopes and terrains. The OpenSpace Extension is in charge of calculating the paths, which are then transmitted to the users on the map minimizing the efforts of the Flash Player in handling the movements of all the visible avatars.

Also, the server-side pathfinding makes it possible to create Non-Player Characters capable of moving around on the maps.

Some frequently asked questions

How many avatars can be displayed on a map?

It depends on various factors such as the tile size, the avatar size and its "rendering complexity". For example, an avatar made of many animated vector-graphics elements, would probably require more Flash Player resources than a simpler avatar made up of a few bitmap parts. For this reason you should run a few preliminary tests to make sure that many avatars on screen (say 20 or 30) don't hog the client CPU.
Additionally there are considerations to be done for the server-side part of your application: if you plan to use public messages you should be aware that each message sent by a player is broadcasted to all other users in the same room. This can generate quite a lot of network traffic in large rooms (100+ users). An optimal room size value is between 2 to 50 players when using public messages.

Is it possible to detect collisions between avatars in OpenSpace?

No, collision detection between avatars is not supported for a number of reasons.

  • In order to optimize the performance, the pathfinding nodes are pre-calculated when maps are loaded by the OpenSpace Extension. Keeping track of each avatar movement would involve realtime path calculation on every avatar step. This could take up too much resources, especially with very large maps and with many avatars.
  • There could be cases in which an avatar could not be able to move at all. Imagine a tiny room with a lot of people in it. This would make the application unusable or at least very annoying to interact with.
  • Detecting collision could block interactive tiles (exit points, triggers, etc.) that anyone should be able to use. Imagine an avatar standing on a trigger tile: the other players won't be able to use it until the avatar moves away.

Is it better to use vector-based graphics or bitmaps for avatars?

It is quite difficult to answer this question. Both ways have pro and cons. Using bitmap graphics has less impact on the overall application performance, but the SWF size can increase dramatically, especially if you have a lot of avatar customizations and animations. Vector graphics are the opposite: smaller file size, but heavier impact on performance, especially when you have a lot of avatars within the viewport limits.
A good compromise could be a mix of the two: use vector graphics, but when the avatar is rendered for the first time, convert each animation frame to a bitmap image. Check this link if you want to explore this approach.

* The avatar state 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 avatars of the other users to be rendered correctly on the player's client when a map is joined.

** A 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.