The engine is in Chrome and C# (with some portions in other .NET compatible languages) running against .NET and Mono. We use TAO to talk to OpenGL.

This provides support for the following platforms:

* Windows 2000, XP

* Linux, FreeBSD and most other POSIX.1 Operating systems

* Macintosh OS X

* XBox 360 under XNA

Approximate memory requirements at this point are 256M for Windows and MacOS, and 512M for Linux. Before someone gets all worked up about this, more memory certainly helps Windows and MacOS, too, but the Linux OpenGL stack typically consumes double or more the main system memory of other modern stacks. Because we are graphics intensive, it is best to allow space for this. We will adjust the numbers as we get feedback on how realistic they are.

We are in the process of moving to a dual engine, that will support both DirectX and OpenGL. This is a true dual engine, and not an emulation layer faking one on the other. On XBox 360, we will support only the DirectX (XNA) engine, while on Linux and MacOS X, we will support only the OpenGL engine. On Windows, by default, we prefer the OpenGL engine, but you can change that if you need to.

Note

the 360 support will take some time. We have to do some significant work to support XNA, because it needs things packaged in a very specific way. We're having to build two executables, even though much of the DirectX code can be shared with the Windows port. My expectation is we'll get Windows out first, followed shortly thereafter by the POSIX.1 (Linux, MacOS) platforms, and then finally the XNA version. Complaining to us won't help us get it done faster, although sending money (or better still a 360) might.

The engine is now using a proprietary XML format that will be documented on our web site. I have a tool that reads a XOF and writes the equivalent XML. I made this change because it is easier to work with for some of the other stuff I want to do. I did not use X3D or the other popular XML formats because they didn't lend themselves to the structure I need to have fast geometry shaders. On the XBox 360, the only option is to use geometry shaders (the fixed function pipeline doesn't exist there, nor on Vista's DirectX 10), so its kind of an important thing.

Animations are using standard BVH files now. This will continue through release.

NOTE

There is also now a WaveFront OBJ to XML converter; WaveFront OBJ is more useful in many ways.

NOTE

Another reason for supporting OpenGL, is that on Windows XP, OpenGL supports all DirectX 10 features via extensions. This is important because we may want to switch on DirectX 10 features when they are available.

UDP Protocol

We primarily use a UDP based protocol in order to keep the simulation state as current as possible. We are using a TCP based protocol for the chat, login and zoning systems (for those specific systems, it means less code). Specifically, they use a Jabber variant. The windowed protocol we were using has been retired (primarily because the performance characteristics were not sufficiently better to be worth the added maintenence cost).

Our servers are designed so that we can deliver signed upgrades to them and apply those upgrades in a way that doesn't require us to shut the servers down, nor to force users to log out, for most updates. For example, a new combat system can be pushed and activated, and it will take effect the next time combat is initiated.

For firewall purposes, we use a small loader executable that loads a DLL containing our patcher; for most personal firewall software, this avoids a warning message every time we update the patcher. Additionally, we load the DLL into a custom appdomain, and if we need to update the patcher, we simply unload the appdomain and then reload the DLL. The net effect of this is that we don't ever have to restart the patcher in order to update it.

Note that we require .NET 2.0 features -- you will need a framework supporting the features that we use. This is primarily because we wanted generics to ensure a stable and reliable game experience.