The engine is in Oxygene (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 5.1 to Windows 7.0. (Windows XP to Windows 7.0)

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

* Macintosh OS X

* XBox 360 under XNA

* PS3 under Yellow Dog

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.

I am now looking at http://fmod.org for sound. It's a pretty nice sound system with a pretty good reach, and a clean API. Pricing is reasonable, for a project of our nature as well.

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.

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.