Build a worker

Supported compilers and runtimes

See Requirements.

Compiling and linking

The way that you'll be using the contents of the worker packages depends entirely on which language
will be using the Worker SDK in C.

The header file package c_headers contains the following structure:

  • <worker_package>/include/improbable- This folder contains two header files:
    • c_worker.h - The worker API, including connecting to SpatialOS and interacting with snapshots.
    • c_schema.h - The schema API, used to serialize / deserialize components and commands.

Each static library package contains the following structure:

  • <worker_package> - The root folder contains static libraries for the Worker SDK in C and its dependencies. On non-Windows platforms, you'll need to ensure that these libraries are linked in the following order:
    improbable_worker, RakNetLibStatic, ssl, z. The fully linked static packages contain only improbable_worker as all dependencies are merged into a single file. Additionally our static libraries depend on a number of system libraries depending on the platform:
    • Windows: advapi32.lib, gdi32.lib, user32.lib, ws2_32.lib.
    • macOS: n/a
    • Linux: dl, m (link with -l). pthread must also be enabled: -pthread
    • iOS: n/a
    • Android: n/a

Each dynamic/shared library package contains the following structure:

  • <worker_package> - The root folder contains the dynamic/shared library for the Worker SDK in C. Dependencies are fully linked into the library, such that it has no other dependencies. The library can also be loaded at runtime in a plugin like fashion, an example of this being a dynamic language such as Python or Lua. This file is named improbable_worker.dll on Windows; libimprobable_worker.dylib or improbable_worker.bundle on macOS and iOS; and on Linux and Android. Additionally, on Windows, the package also includes an import library improbable_worker.lib, that can be used when building a C or C++ application.

Building for a cloud deployment

After building a project, a certain directory structure is expected when uploading an assembly. Therefore, the steps of the Build task for your worker (within spatialos.<worker_type>.worker.json) should:

  • Create a zip file containing the worker binary with a name matching the value for the artifact_name specified in the managed worker configuration, under managed then linux.

  • Place the zip file in <project_root>/build/assembly/worker/, so it is picked up when uploading an assembly during spatial cloud upload <assembly name>.

SpatialOS runs managed workers as part of a cloud deployment in a Linux environment similar to Ubuntu 16.04 LTS. Therefore, you need to build a binary that can be executed in this environment.

If you are developing on Windows or macOS, we suggest installing Ubuntu 16.04 LTS inside a virtual machine using VirtualBox, and using our Linux support to build managed workers. Alternatively, on Windows 10, you can install Ubuntu using the Windows Subsystem for Linux instead of a virtual machine. This is not required for local deployments during development: just for cloud deployments.

Updated about a year ago

Build a worker

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.