2d multi-user virtual world via javascript in browser and server which handles communication

#2 Avatars not visible for other people

~iank commented on libreadventure todo

7 months ago

#1 Fix major bug that affected LibrePlanet 2021

~iank commented on libreadventure todo

8 months ago


LibreAdventure is a fork of the last freely licensed version of WorkAdventure, plus a map and small changes for use at LibrePlanet 2021/2022. Renaming is incomplete.

At FSF, we mainly want to fix a bug for LibrePlanet 2022 (https://todo.sr.ht/~iank/libreadventure/1), and if we can find some other improvements to make that would be good too.

#fsfsys on libera.chat and the SourceHut mailing list for this project are the main place to ask questions and coordinate. Yes, we know there are little to no posts on the mailing list yet, don't let that stop you.

There exists an instance of this code at an FSF server, play.libreadventure.org. If you want to help with LibreAdventure, FSF tech team is giving access to test changes there to people they think are trustworthy (they have done some work volunteering or something). If you think you one of those people, email sysadmin@fsf.org with your public ssh key and join #fsfsys and say that you've emailed your key and want to help with LibreAdventure. The FSF tech team will add your key to the server. Before making changes to the server please say something on #fsfsys in order to make coordinate with any other volunteer who may be working on it. The main way to run the software on the FSF server is with cd /srv/libreadventure-deployment; docker-compose restart, then browse to https://play.libreadventure.fsf.org. The standard out of docker-compose is useful for development, so if multiple people want to work on it at the same time, you will probably need to coordinate to make it visible to multiple people, like sharing an tmux or screen, or redirecting it to a log file that can be tailed.

Feel free to have a look at the upstream version of WorkAdventure and explore improvements made there. We should not copy any code because the upstream is under an incompatible license.

This package is licensed AGPLv3. There is no indication in the repo of whether the original authors meant AGPLv3 or later or only. We are waiting to hear from them. Any contribution you make is assumed to be dual licensed AGPLv3 only and AGPLv3 or later, so that when the original license gets clarified, we will distribute under that.

#Work Adventure (upstream readme is below)

#Work in progress

Work Adventure is a web-based collaborative workspace for small to medium teams (2-100 people) presented in the form of a 16-bit video game.

In Work Adventure, you can move around your office and talk to your colleagues (using a video-chat feature that is triggered when you move next to a colleague).

#Getting started

Install Docker.


docker-compose up

The environment will start.

You should now be able to browse to http://workadventure.localhost/ and see the application.

Note: on some OSes, you will need to add this line to your /etc/hosts file:



#Designing a map

If you want to design your own map, you can use Tiled.

A few things to notice:

  • your map can have as many layers as you want
  • your map MUST contain a layer named "floorLayer" of type "objectgroup" that represents the layer on which characters will be drawn.
  • the tilesets in your map MUST be embedded. You cannot refer to an external typeset in a TSX file. Click the "embed tileset" button in the tileset tab to embed tileset data.
  • your map MUST be exported in JSON format. You need to use a recent version of Tiled to get JSON format export (1.3+)
  • WorkAdventure doesn't support object layers and will ignore them
  • If you are starting from a blank map, your map MUST be orthogonal and tiles size should be 32x32.

#Defining a default entry point

In order to define a default start position, you MUST create a layer named "start" on your map. This layer MUST contain at least one tile. The players will start on the tile of this layer. If the layer contains many tiles selected, the players will start randomly on one of those tiles.

#Defining exits

In order to place an exit on your scene that leads to another scene:

  • You must create a specific layer. When a character reaches ANY tile of that layer, it will exit the scene.
  • In layer properties, you MUST add "exitSceneUrl" property. It represents the map URL of the next scene. For example : /<map folder>/<map>.json. Be careful, if you want the next map to be correctly loaded, you must check that the map files are in folder back/src/Assets/Maps/<your map folder>. The files will be accessible by url <HOST>/map/files/<your map folder>/....
  • In layer properties, you CAN add an "exitInstance" property. If set, you will join the map of the specified instance. Otherwise, you will stay on the same instance.
  • If you want to have multiple exits, you can create many layers with name "exit". Each layer has a different key exitSceneUrl and have tiles that represent exits to another scene.

#Defining several entry points

Often your map will have several exits, and therefore, several entry points. For instance, if there is an exit by a door that leads to the garden map, when you come back from the garden you expect to come back by the same door. Therefore, a map can have several entry points. Those entry points are "named" (they have a name).

In order to create a named entry point:

  • You must create a specific layer. When a character enters the map by this entry point, it will enter the map randomly on ANY tile of that layer.
  • In layer properties, you MUST add a boolean "startLayer" property. It should be set to true.
  • The name of the entry point is the name of the layer
  • To enter via this entry point, simply add a hash with the entry point name to the URL ("#[startLayerName]"). For instance: "https://workadventu.re/_/global/mymap.com/path/map.json#my-entry-point".
  • You can of course use the "#" notation in an exit scene URL (so an exit scene URL will point to a given entry scene URL)

#MacOS developers, your environment with Vagrant

If you are using MacOS, you can increase Docker performance using Vagrant. If you want more explanations, you can read this medium article.

#First steps

Create a config file Vagrantfile from Vagrantfile.template

cp Vagrantfile.template Vagrantfile

In Vagrantfile, update VM_HOST_PATH with the local project path of your machine.

#VM_HOST_PATH# => your local machine path to the project

(run pwd and copy the path in this variable)

To start your VM Vagrant, run:

Vagrant up

To connect to your VM, run:

Vagrant ssh

To start project environment, run

docker-compose up

You environment runs in you VM Vagrant. When you want stop your VM, you can run:

Vagrant halt

If you want to destroy, you can run

Vagrant destroy
#Available commands
  • Vagrant up: start your VM Vagrant.
  • Vagrant reload: reload your VM Vagrant when you change Vagrantfile.
  • Vagrant ssh: connect on your VM Vagrant.
  • Vagrant halt: stop your VM Vagrant.
  • Vagrant destroy: delete your VM Vagrant.

#Features developed

You have more details of features developed in back README.md.