This alpha release is mainly meant to showcase various developer specific changes (compared to Sauerbraten).
In this post I'll go into more detail about the reasons for some of these changes you might be wondering about.
You may have noticed we dropped the "vcpp" and "xcode" folders in the source as well as the makefile. Why?
We use Git now, as it is developed to allow as much productivity for teams as possible (though on the downside, learning Git can be a huge task if you choose to do it in the command line).
So the build system has to work with various people working in parallel. This is pretty rough for a static build-structure (e.g. adding a file, a dependency, or whatever costs a lot of nerves merging it back again). That's one of the reasons CMake came into play: It allows to generate all project files / make files or whatever on the fly. Take for example: you add a new file to the codebase: You do not need to modify project files for all platforms, making developement much more comfortable. (If you add a new file to one of the existing modules/folders it even gets automatically added to the projects)
So what is the downside you ask? Well.. Obviously CMake is needed as a dependency. Furthermore, you need to generate your buildchain after downloading before you can start developing (after doing it one or two times this won't bother you at all anymore, trust me). Another point is that the compilation on some platforms could consume a bit more time compared to Sauerbraten's (ultra-optimized) static projects. CMake adds a bit overhead here.
We decided that the upsides outweigh the downside at this point.
As you may have noticed, we also changed the structure in which the content is organised. We see that it could be more difficult to adopt content from Sauerbraten now. And you may also have been disappointed to notice that a lot of content has even been dropped completely.
Why did we do this?
We want to make Inexor (in comparison to Sauerbraten) completely free/libre. Mostly of course because of our belief in free software, but if you want more concrete benefits:
Let's just say that Sauerbraten was really indulgent in its content policy, meaning a lot of stuff is licensed non-freely (e.g just for Sauerbraten) or even not licensed at all. The downside of course is that we have way less content at the beginning and need to replace that stuff.
The opportunities which open through this fresh start are:
Furthermore we want to provide in-game downloadable packages, so this system needs to be easily extendable. That, btw, is where JSON comes in to play:
In contrast to CubeScript, JSON is used soley for saving data, not for executing stuff or scripting. It's used all over the web, simply because it's easy as hell. We want to slowly migrate all content, specifically stuff from .cfgs to .jsons. Although we just started converting existing content to load with json, (which is not yet included in this alpha), the API for it is set and pretty easy to use.
We want to provide powerful scripting and attract people with a dynamic way of mapping (e.g. pave the way for new [multiplayer] story modes or gamemode scripting.. ). Therefore we'll need a powerful scripting language behind the scenes. Pretty few people speak CubeScript and we do not want to spend time improving it while there are other (better) solutions:
So how did we implement this and how did it change the current behaviour? We decided to outsource it to another engine: node.js, and let it call CubeScript commands! (*Later on not CubeScript but a specialized API will be used..*) This is implemented through a system called "Inter Process Communication":
You may ask yourself, "inter process", does that mean I have to start two applications now to run Inexor?