Monday, April 18, 2011

The way of the servers

A teenage me was sitting in the summer of 1996 in an apartment I shared with a friend and mused on the state of games. Master of Orion 2 was just the latest game and besides that my computer sported Ultima VIII and Quake World.

The reason why a teenage me was not busy shooting things or doing other things a teenage me would be up to, was that I was waiting to the awful sounds my 14'400 baud modem made while connecting to the internet so I could shoot some things on quake world. Those crazy sounds shook loose some thoughts in my head. Wouldn't it be nice if I could connect to the internet and then play Ultima VIII with other people online? Quake World did it, it couldn't be that hard, could it?

Well yes it was hard of course. You write a server, clients connect to it and... Wait a second... As my screen avatar got fragged perpetually I was busy scribbling down some notes. Those notes did not survive my subsequent moves (including twice over an ocean) but the ideas did.

Again, it's 1996, Ultima Online is a long way away for someone that hasn't passed his second decade yet and I had some experience in programming. The idea was first very simply copying the Quake model.Connect users to a server. On the server everyone was known in position, so the server would transmit to everyone else where they were. This of course had inherent problems. You couldn't tell everyone everything at all times, if the server was too big. The modems were not fast enough to send huge data streams at all times. Paired with the utter crap experiences I had made on large servers, where it was so slow for everyone, that it was just not fun anymore, I knew this needed a new approach.

So simple, you delegate people to different servers, for different maps. Portal between the maps and there is your solution. Not quiet. You still don't have a solution for many people on one server. Out comes the first innovation, the field of action. If something or someone is within that field, you can see them and get their data. In crowded areas this gets sticky, but then again, you could lower that area if an area is very crowded.

Then came in monsters, quests, and all the other things. Wait, different servers for different maps. So that means a different build for each server, as they each need different sets of everything. And all of it baked together with the map.

To reiterate, this was 1996. The cloud was a mostly white thing in the sky and clusters something of a nerds wet dreams and billionaires. Yet I came up with something that today is called a cluster.

Create nodes, as we call them today, that do specific tasks, but can take on tasks in a configured way, not hard coded. First you have the map nodes. They simply know where everyone is and who needs to know where what person is at the same time. The node can simply be told which map it currently has loaded, or what portions of it. Yeah that's a clever trick, make maps huge, and have the server load portions of it, and load more if needed. Then some portions could be loaded by two servers at the same time though.

Well then there is the control node, taking care of exactly that. It knows which server takes care of which part of the map. That will work.

So now what? Well monsters hardcoding on the server makes little sense to my mind. So why not have a server that plays the monsters? They are like players, but the map node has no clue about that really, it just sees them as additional player running around, handling who sees what. The map node also does the usual checking of what is possible and what not, so it's a really dumbed down node in effect.

You can see this whole design lead to a multitude of nodes. At the end of the day I was at 32 different nodes (by pure accident) and started noticing more patterns, where things intersect. I started to split even more, then merge together again where the exact same operation was done just in a different style.

There is much more to this, but I leave you with this quote from an article over at CNN:
Trion servers are broken down by function, unlike other games in which servers are devoted to particular locations in the game. For example, they use a set of servers to handle non-player character functions in the world, a different set of servers to handle encounters with "bosses," and another set that handles functions directly involving the players' characters.

Hartsman said by dividing the servers by functions, processes can be started and stopped more quickly and easily, causing less lag and other glitches in gameplay. Getting them to all work together seamlessly was hard.

"Yeah, it was hard, but it was well worth it. We're really just now at the point we're about 25% into all of the things we can do with our technology and we're looking to add more," he said.

Welcome to 1996, Trion. Consider yourself lucky, the majority is still stuck in the 80s, server wise.

No comments:

Post a Comment