The past few months have granted me little time to work on MUTA, our 2D MMORPG. There have been events to attend (NGS), another trip to India (IGS), and work. But I've done a bit of MMO work nevertheless.

The proxy server

I began working on MUTA's proxy server. It is a server that sits between the client and the game server, dispatching messages in both directions. The purpose of it is to never reveal the true IP address of the game server, making it more resilient towards DDOS attacks. Each proxy could be connected to multiple game servers, and each game server to multiple proxies, so that two people playing on the same server might be connected to completely different IP addresses.

I'm writing the initial implementation using TCP, in C as the rest of the game is written in. Adding another layer of connectivity, especially with TCP, will of course increase latency, so it remains to be seen if we should do the game-server-to-proxy connection via UDP later.

The idea for the proxy came from many sources, but one of them is CipSoft's Matthias Rudy's GDC talk about the infrastrucuture of Tibia. The slides for the talk are here.

The login server

Once I had sat down and begun writing the proxy server, I went as far as accepting clients and reading their packets before I realized I should probably write the login server at this point, too. Currently in MUTA, the game server acts as a temporary login server. It wouldn't make much sense to write login-related functionality code between the proxy and game servers, only to remove it later. So I also started up the login server project.

Event based architecture

On the login server I thought I might try out something that's new for me. I'm not a very experienced network programmer, and hence I haven't had the chance to try out that many different tricks yet.

Dividing work between threads is still an issue I constantly run into when writing server software. Usually, because of my background in game programming, I've simply settled for having a main loop that runs at a certain frame rate, and the other threads feed work to that thread, such as handling incoming accepts or reads. Work is fed using various buffers that store different kinds of events (for example, a client received something in it's buffer, the message should be handled). This is not very elegant or energy-efficent design.

On the login server, I thought I might still have one thread executing the main logic, but instead of locking the thread's frame rate, I'll try having the main thread sleep until it gets work from other threads. I will also try to unify the event buffers so that most events would be inserted into a single queue. Insertion would block the feeding thread if the queue is full. Well, we'll see how that goes.

Art direction

Something thing we've recently (and before, too) been pondering with Lommi is what would be the most practical direction we could take in regards to art in MUTA. It's been a tough subject!

We know the feeling we want the game to go for: the sort of gritty fantasy provided by Robert E. Howard's Conan stories and other sword-and-sorcery works. We also really dig the artstyle of many of the comics made of Conan. In a 2D game that would look awesome. But 2D art in 8 isometric directions is painstaking, and it's complicated by things such as displaying equipment on characters while keeping animations smooth-looking.

We thought of a couple of directions we could follow. One would be to reduce the game's resolution from 64 pixel tiles to 32 or 16 pixels. Such a low resolution would allow even us programmers to make art for the game, albeit low quality art. We didn't really like the idea, as it doesn't let us present the game world as such a gritty, "mature" type of place as we'd like, and it would limit the art style a lot. Besides, the programmers probably shouldn't do the art anyway.

Another thought we had was going 3D. Neither of us two working on the game can do 3D art, but 3D would mean not needing to draw 8 different directions for each object (or at least each character). Then again, 3D would probably present our style in quite a bit of a worse manner than well-made 2D in isometric space.

We didn't decide anything yet, other than that the direction we have sought so far would look the best.