- Activate the plugin: Add intensity.components.server_runner to [Components] list in your settings.cfg
- After logging in to the master, click on 'plugins...' in the main menu. You will then see the status of the local server.
- Tell the plugin which map to run (simply by writing the location of the map, e.g. "racetrack" for the racing map). Then click start, and wait a bit while the server is started up for you. As soon as it is ready you will automatically connect to it.
- The server will be shut down automatically when you close the client, or connect to another server, so no need to worry about that. You can also shut it down in the GUI if you want (which is necessary to start it up with a different map).
- Requires you to be logged in to the master, but allowing master-less running would be possible if people want it.
- If the server crashes, output is saved to ~/.intensityengine_client/out_server.txt (note: not in the install directory, but the engine home directory). A nice GUI for viewing the output should be added later.
- You can't write the location of a map that you never played on before, as it only looks locally for translating the map location to the asset info.
- Tested on Linux. Should work on other OSes (it is 99% pure Python), but not tested yet.
- The server still uses a network port, so your firewall may ask about that. It would be possible to move to a pure IPC solution later, without that problem, but it would be additional work.
Sauerbraten, the engine that the Intensity Engine is based on, lets you easily run a local server - it runs the server inside the client, in fact. This makes sense, since the Sauerbraten server is very simple, it is basically a network message router.
However, the Intensity Engine lets you run scripts and physics on the server, which raises the possibility of the server crashing (due to bugs in scripts, etc.). The server also can take a lot more CPU and RAM because of that. Consequently, the server is strictly separated from the client - there is no option to run it inside the client. Another reason is since the server now does a lot of the things the client does (scripts, physics), then maintaining a single codebase with the server defined as separate - and not two options, separate or internal - is much easier.