For the third anniversary of Unvanquished’s first release, we are proud to present to you an engine milestone in Alpha 37!



Our first release was February 29th, 2012, which was exactly three years ago (considering Leap Day), three years during which we have greatly improved all aspects of the game. This includes replacements for almost all inherited models, great new maps, and significant gameplay enhancements. At the same time, Daemon, the engine powering Unvanquished, has come a long way from being just ioquake3 plus fancy a renderer, being iteratively upgraded to a more modern engine with HTML-based UI and special effects. This release adds another engine milestone, so read on for what’s new!

This release has major engine changes in addition to two map updates, some gameplay changes, a new model for the overmind that will creepily follow you with his unique eye, and a technical preview of an updater to easily keep the game up to date. Parpax’s layout has been updated while Forlorn has received yet another graphical update with particularly beautiful lighting in the central area. On the gameplay side, the spiker has been rebalanced by changing the fire pattern of the spikes to be more deadly and the human team has been slightly nerfed by reducing the damage and radius of the firebomb, and putting the Lucifer Cannon in a new momentum threshold, providing a smoother transition to human team’s most potent weapon.

On the engine side, we rewrote and improved the “system” modules of Daemon and ported the client-side VM to NaCl, completely replacing the QVM system that was inherited from Quake III. The latter is a very big change and is likely to introduce bugs and performance regressions, but releasing this will allow us to find these problems and fix them over the next alphas. Finally, for consistency, we renamed the server-side VM from “game” to “sgame”, so server administrators and package maintainers may have to update their scripts.

Overview of the engine changes

Two feature branches were merged for this release. The first one, sys_rewrite, simplified, refactored and improved the code responsible for the operating system-specific parts of the engine, altering the error handling in the engine to use exceptions instead of setjmp/longjmp, unifying error handling behavior across all platforms, as well as adding the ability to send commands to a running instance of the engine from the shell, a feature formerly provided by ad-hoc shell scripts. The second branch, nacl-cgame, marks a huge milestone in the evolution of Daemon by completing a project started back in the summer of 2013 to make the gamelogic virtual machines use NaCl instead of QVM. This allows us to use C++ for the gamelogic, include external libraries, and increase code-sharing with the engine; we had already moved the server-side VM to NaCl in Alpha 27.

The biggest problem with NaCl VMs is that calls between the engine and the virtual machine are much slower because they run in separate processes and must communicate through a socket. This is why, when porting CGame, we added the ability to communicate through a command buffer in shared memory: asynchronous commands are buffered in it and socket communication is only needed to signal when the buffer needs to be flushed. All audio related commands as well as most of the renderer commands are sent through the command buffer, greatly reducing the performance overhead of the communication. While in most cases there is no difference in performance compared to the previous releases, and even a gain of a couple FPS for mostly empty games (parpax default human base); a busy layout on the training server with hundreds of buildings and dozens of players incurs a 30% performance hit. This an acceptable loss given that we will further optimize the communication and that it is a worst case situation for a CGame NaCl VM.

Now that both VMs are using Native Client, we have deleted all of the QVM handling code, removing 23.000 lines of code of tools and 8.000 in the engine, although in fairness this delta doesn’t take into account the addition of the NaCl SDK, which is huge. Having C++ in the gamelogic brings a lot of benefits, ranging from having an intuitive vector math library that uses operator overloading, to structuring our entity types using components, all of which will hopefully help us move forward faster.

Changes for users

The curses console is now off by default and command-line flags for the executables have been changed, they are now the following:

-homepath <path> to set the path for the “home directory path” where configuration files are written and paks downloaded

-libpath <path> to set the path for the “executable path” containing additional executables used to load a NaCl VM

-pakpath <path> adds another path from which pk3s can be loaded

-resetconfig resets all cvars to their default value by not loading autogen.cfg on startup

-curses activates the curses console, for server-owners wanting colors and a nicer console UI

-set <variable name> <value> is now the preferred way to set a configuration variable (unlike +set which will now only be executed after engine initialization has finished)

+ <command> still works as before, but must be specified after the flags. It executes a console command after the engine has finished initializing.

-help/–help shows a list of all available options and exits

-version/–version shows the engine’s version number and exits

unv://ADDRESS[:PORT] allows you to connect directly to the server with the given address

Changes for developers

The workflow when developing the gamelogic is now the following: while developing, build the VMs as native DLLs and run the engine with “-set vm.sgame.type 3 -set vm.cgame.type 3”, which will make the virtual machines run in a thread of the main process, making debugging easier. The engine looks for the native DLLs in the same directory as the engine executable, which is where they are built when Unvanquished is compiled from sources. When you want to release the VMs, build them as NaCl executables which will result in four files for each vm: with and without a “-stripped” suffix and targeting x86 and x86_64. Put both the x86-stripped and x86_64-stripped files in the root directory of a pk3, renamed as x86 and x86_64. In the future, the “basepak.sh” scripts automates this process.

In the rare event of a bug specific to NaCl VMs, or if you are an engine developer, you’ll want to debug the NaCl VMs directly. To do this, set the VM type to 1 and drop the nexe files next to the executable. You can then run the game with an added parameter vm.<name>.debug 1 which will start the VM in a gdb server. You can then connect to that server using the nacl-gdb provided in external_deps. In nacl-gdb, use “target remote localhost:4014” to connect to the gdb server and type “c” to start the gamelogic.

Below are the commits that were added in this release: