C++ CMake Other
Failed to load latest commit information.
cmake [WINDOWS] Embed a manifest-file in windows builds Dec 26, 2016
dist/linux Startup improvements Jan 13, 2017
doc [DOXYGEN] add a starter page to doxygen Oct 20, 2016
flex @ 4320e83 Updated flex submodule Jan 12, 2017
inexor [LOGGING] truncate ns if possible Dec 26, 2016
media Add media-core folder as submodule Dec 25, 2016
tool Startup improvements Jan 13, 2017
.gitignore Ignore compiled python files (like conanfile.pyc) Jan 12, 2017
.gitmodules Include Inexor Flex as submodule 'flex' Jan 11, 2017
.travis.yml [PM] change from conanfile.txt to conanfile.py Dec 16, 2016
CMakeLists.txt [WINDOWS] Embed a manifest-file in windows builds Dec 26, 2016
Jenkinsfile [CI] Use two cores for compiling Inexor Core Feb 24, 2017
appveyor.yml [CI/WIN] remove the unit-tests wrapper script Dec 26, 2016
changelog.md Update changelog Jun 20, 2016
conanfile.py [LINUX/BUILD] make conan build use all cores Dec 25, 2016
contributing.md Update readme & comments Sep 17, 2016
credits.md Update license/credits notes Dec 13, 2016
dependencies.py [PM] only use static SDL and SDL image for gcc Dec 25, 2016
doxygen.conf [DOXYGEN] add a starter page to doxygen Oct 20, 2016
inexor.bat Modified the start scripts to use Inexor Flex as the only entry point Jan 11, 2017
inexor_unix Modified the start scripts to use Inexor Flex as the only entry point Jan 11, 2017
license.md Update license/credits notes Dec 13, 2016
master.cfg Added, updated, sanitized and cleaned the master server. Mar 5, 2016
readme.md [CI] Add master status of Jenkins CI. Jan 2, 2017
server-init.cfg add ctftkpenalty to server-init.cfg Apr 10, 2016
server.bat [REFRACTOR&CMAKE] only one top level "bin"-folder + fix install Dec 16, 2016



Build Status Build Status Build status

Inexor is a fork of the open-source First-Person-Shooter Cube 2: Sauerbraten, a fast-paced shooting game featuring an ingame map editor.
In contrast to Sauerbraten, Inexor adds a lot of functionality and strives to stay open to improvements and suggestions.
The goal of this project is to be more flexible and create an environment where development is easy, fast and where creativity can prosper.

How is Inexor organized?

We are a non-hierarchical organisation. This means we are simply a group of people with different ideas working together without a leader making all the decisions. Anyone of us is free to work on the particular things they want to. For this organisation to work properly we rely on good communication. We are on IRC and Mumble pretty much everyday. Every so often we organise official Mumble meetings to discuss our roadmap and strategies.

We are open for new people!

Where are we headed?

Our goal is to make the game as moddable and developer-friendly as possible. Even though we might have refactored most of the code at some point, Inexor should always feel like Sauerbraten gameplay wise.

A popular stance among the Sauerbraten community is "that's impossible", and this is what we want to prove wrong. Our answer to remarks like "things are best like they are" is: standing still means falling behind.

Different features are afoot

giving a general but no inevitably defined idea of where we're going next

  • node.js scripting
    • (JavaScript + asynchronous + package manager)
  • new user interface using HTML5 + CSS3
  • functionality to facilitate content-creating:
    • better editing features (e.g. a version control system for maps)
    • extensibility (e.g. for custom playermodels, sounds,..)
  • in-game content sharing
  • documentiation of the whole code base
  • refractored code to be more modern, scaleable, safe, non-blocking, modular, free, ... than before
    • modularity (makes working as/in a team easier)
    • scaleable and non-blocking resulting in better performance
    • heavier use of proven third-party libraries
      • instead of buggy and slow "reinvent-the-wheel" implementations
  • ...

We believe that basing our project on these few points will work out for the best.
They have already required a lot of thought and discussion, so chances are high that -in case you're not fully convinced by them yet- you will get convinced by working with it.

However, if you want to influence our development you should join our IRC-channel #inexor on gamesurge.net (see Contact) and talk with us.

And of course we won't be too proud to rethink this list if you face us with a more thought-through and better developed alternative.

What have we changed already?

Have a look in our features section and our changelog.

If you are a developer familiar with Sauerbraten worrying about the direction we are going check out the posts in our blog called "Design Decisions" (Design-Decisions Part1, Design-Decisions Part2) giving you a vague idea of our reasoning for some points.
You'll probably find more info on the dedicated wiki-sites, in the readme of the particular module and for specific stuff in the documentation.

A little note on that is that a lot of our decisions are consequences of other ones (e.g. working as a team had influences on the whole build structure, that we use CMake, that we use Git and hence had to split the data and code repository and more ... it's all chained). Consequently, our approach in developing Inexor is probably the most profound one in the Cube engine world.


Good tutorials on the whole process needed to build Inexor can be found in its wiki page, which you should read beforehand for saving you some nerves.

Join us

You have already accomplished the first step by reading this readme. Congratz!

The second one is only slightly harder by joining us in IRC (again see the wiki site for that: Contact) and idling/participating in our chat.

To contribute to the project and merge your changes into the master branch you need to convince enough members that the changes are an improvement. If you keep communicating what you are doing, take into account feedback and tips from others as well as giving insights into your decision making process, it won't be an issue.

More information about the contributing process can be found here.


The Inexor source code and the Inexor files are provided under the terms of the ZLIB license (very similar to the BSD license). Inexor is a fork of Cube 2: Sauerbraten, which is also licensed under the ZLIB license.

The license covers the source code repository on GitHub as well as the "config" directory in the "data" repository on GitHub.
Game media included in the game (maps, textures, sounds, models etc.) are NOT covered by this license, and may have individual copyrights and distribution restrictions (see their individual READMEs).

In contrast to our predecessor Sauerbraten our officially bundled content needs to be open source, i.e. allowing all kinds of usage required for increasing the ecosystem around the code, including sharing mods or commercial use.

The included third-party libraries also have individual licenses, which you can find in the respective READMEs in platform/legal.