Server Framework #
The runtime framework is essential to write server-side game logic for your games or apps. You can write code you would not want to run on client devices or the browser. This code you deploy with the server can be used immediately by clients so you can change behavior on the fly and add new features faster.
You should use server-side code when you want to set rules around various features like how many friends a user may have or how many groups can be joined. It can be used to run authoritative logic or perform validation checks as well as integrate with other services over HTTPS.
Load modules #
By default the server will scan all files within the “data/modules” folder relative to the server file or the folder specified in the YAML configuration at startup. You can also specify the modules folder via a command flag when you start the server.
Files with the “.lua”, “.so”, and “.js” extensions found in the runtime path folder will be loaded and evaluated as part of the startup sequence. Each of the runtimes has access to the Nakama API to operate on messages from clients as well as execute logic on demand.
The Go runtime looks for a Go plugin “.so” shared object file, either in the default file path or in the runtime path set. To learn how you can generate the “.so” file with your custom Go runtime code follow these steps.
The Lua runtime will interpret and load any “.lua” files in the default file path, or in the runtime path set. Each Lua file represents a module and all code in each module will be run and can be used to register functions.
This path must be relative to the default or set runtime path.
Run once #
The runtime environment allows you to run code that must only be executed only once. This is useful if you have custom SQL queries that you need to perform (like creating a new table) or to register with third party services.
Errors and logs #
Error handling in Go follows the standard pattern of returning an
error value as the last argument of a function call. If the
nil then the call was successful.
Lua error handling uses raised errors rather than error return values. If you want to trap the error which occurs in the execution of a function you’ll need to execute it via
pcall as a “protected call”.
try catch block.
will_error uses the
error function in Lua to throw an error with a reason message. The
pcall will invoke the
will_error function and trap any errors. We can then handle the success or error cases as needed. We recommend you use this pattern with your Lua code.
info(default level) or below, the server will return Lua stack traces to the client. This is useful for debugging but should be disabled for production.