This section deals with the development of Ember. It's mainly meant to help those that wish to be involved in the development of Ember.
The quickest way to get involved is to visit the Launchpad and look through the bugs and blueprints.
When working on Ember you should always use the the latest code directly from the GIT repository. Information on how to access it can be found here.
The main philosophy behind the development decision that have been made for Ember is to try to leverage existing FOSS components as much as possible. There's no need to reinvent the wheel for a particular feature when there's already bound to be an already existing solution. In fact, it even seems counter intuitive to develop a FOSS application and not using already existing FOSS components. One of the great benefits of the FOSS world is that code and systems can be reused. And not only reused; they can be refined and updated by the very same people that uses them, since the code is open.
Ember therefore strives to reuse existing FOSS components as much as possible. This shows itself in the very large number of third party components used in the system. There are usually two complaints about this (or really just one).
* It's hard to compile * It makes the executable large
The first complaint is virtually void. It's only applicable for people that wants to compile Ember from CVS, all other people use either the prepackaged Autopackage version, or the precompiled Windows version, or get it from the FreeBSD ports system. Furthermore, all components used by Ember have been carefully selected so that they exists for all of the platforms that we support. There are even instructions on compiling Ember.
The second complaint would perhaps have been true 10 years ago when space and bandwidth were scarce. Today however it's not an issue. Additionally, if you don't have enough bandwidth to download the ~10Mb large Ember package, you probably don't have enough bandwidth to play online games anyway.
Most of Ember is written in C++. Most of the libraries used by Ember are written in C++ also, though there are some are written in C. The GUI is however mainly written in a scripting language, at this moment mostly lua. Ember provides a mechanism which allows for different scripting languages to be supported, as long as there are bindings. Currently however only Lua is supported.
The components chosen by Ember are all components that are actively developed. They are also all supported on a large variety of platforms. We've tried to commit to components that we feel will be actively developed for a long future term. The goal is to be able to not hesitate to throw out an internal functionality if an external component with similiar functionality develops. By using third party components we don't have be experts in all the different aspects of the client. Instead we can try to focus on making the whole of Ember better. And hopefully the components we've chosen will keep on developing, getting better all the time.
At the core of Ember are of course the Worldforge libraries. These are better described in other parts of the wiki, so they will just be briefly touched here.
- Skstream is used for low level stream transport, for example over the internet. This provides an easy way to send data to another machine. It's not used directly by Ember.
- Atlas is the main protocol for transferring data between the server and the client. Simply put, _everything_ that happens in the world is translated to Atlas. Ember uses some Atlas functionality directly, though most communication happens through Eris.
- Eris is a client abstraction layer which translates Atlas messages into higher level data structures that makes more sense for the client (such as "Avatar", "Entity" etc.). Ember interacts heavily with this library.
- WFMath provides math functions. Since all current Worldforge games works with 3d space, there's a need for a mathematical helper library to provide constructs such as points and vectors.
- Varconf provides functions for loading and saving settings to a configuration file.
- Mercator provides methods for dealing with generation of nature. It's mainly used for the generation of the terrain.
- libWfut allows for live updating of media.
Since C++ has no built in mechanism for detached message and event signaling there's a need for a third party solution. While most event situations could be solved by using callbacks instead, signals and slots have a better semantic meaning. They also provide a more decoupled mechanism for events. We've therefore chosen to use the SigC++ library. This provides a mature and very easy to use system for signals and slots. Note that some Worldforge libraries such as Varconf and Eris also uses this library.
There's a lot of smaller frameworks in Ember, designed to be pretty configurable and easily extended. These are described in fuller detail here.
Getting media into the Ember client can be a little daunting, but the flexibility of the engine allows for very advanced features. The general guidelines are probably helpful, as well as the Ogre media guidelines.