The First TrimesterDevelopment of the Bone Structure (The Technology)

The First Trimester”Development of the Bone Structure (The Technology)

It was quickly decided that the server technology would be UNIX-based. I do not believe Linux gained wind as the platform for the finished server until halfway through development. Although the servers were developed on that operating system, the engineers believed for a long time we had to use "real UNIX" on the live servers. The projections for "Intel"-based servers at the very beginning were 5“10 simultaneously playing customers per PC. We obviously needed other numbers to make money. The story of this first projected number of simultaneous players is a great joke with us these days.

One of the things I believe we accomplished well was to actually develop the core server technology ourselves . During the long development, many nay-sayers said the technology was never going to perform, that buying third-party tools would be much better, and that the 5“10 people per server was probably dead on.

Our early plans, which didn't end well, were the projections to make a universal online game engine. The idea was to develop an independent core engine, with many independent layers , that could be used for any online game. We wanted to use this engine not only in more RPG games , but also any type of game”from shooters to backgammon. As time passed, several "hacks" in between those engines (from the game code to the bottom layers) were made, and the layers now live more or less in symbiosis.

It is hard to say today if we should have scaled back ambitions and made the core engine smaller and more easily manageable. What I can say is that making these quick fix methods cost us more in development than if they had been better planned for. But then again, thinking reuse is critical, and it is very hard to find the optimum level.

Some things that did not work well from the very start were the game data development tools. From previous experience, we knew that getting the tools used to develop the game up and running as soon as possible was critical. (I am talking world designer tools, item tools, monster tools, and so on.) The first iteration of these game tools was almost totally useless, though. We shifted some personnel, made some changes, and the tools became usable. I guess there are many reasons for this, but the 8“12 months already spent left us with a bitter feeling.

Developing a Central Nervous System”A Brain

After the technology had been in development for some months, the game engine left the research and development phase and had a team assigned to it. After 12 months (we are now in 1998“99), the design was still completely incoherent; there was no direction, and many of the team members seemed to be working toward their own vision, not a central one.

Looking back at this, it is not hard to understand why the first months were botched. First of all, if Marius was the father, the womb into which he sowed his seed was a very hostile environment. The organization was not motivated; we did not want to make an MMP online game. The core development people of Funcom simply did not understand why players would think MMP online games would be fun (talk about people set in their ways). There were many, many feet-dragging exercises being performed throughout the organization.

"What did we learn from this," you ask? We learned that the game concept should be present as early as possible to be used as a sell-in. It is not always easy to sell only a business model and a piece of technology to an organization with other ideas in mind. When people saw the game and the possibilities to interact, battle, show off, socialize, and have fun together ”they wanted to participate. Many seeds fell on stones, but when a seed found earth, it grew and blossomed with a speed not often seen before.

Sadly though, the above-mentioned half-heartedness seemed to have found its way all the way to the core of the team, in my personal opinion. Suddenly, after 12 months, the original producer of AO left. He had been starting his own company on the side, at least mentally, for some time.

Just to be precise, I believe the core technology team, headed by Martin, the lead programmer, was working steadily and well toward its goal. The lack of development was mostly on the "brain" side”not in the muscles or bone structure. The problems were design and concept, not technology.

This was when Tommy Strand, Tor Andre Wigmostad, and I were added to the project. This was a tough but very fruitful cooperation, I think. Tommy's genius comes from his understanding of technology and complete enthusiasm in trying to make it work in the most general way possible. Many of the core game systems in use were designed by him (and me) in that period. Tor was partly also working as a designer, but mostly producing and acting as project manager to track the tasks . I must add that the cooperation with the main game programmer was really good, and that many of the ideas bounced back were better looking than before this point.

Hands and Feet”The Item System

One of the things we really wanted to do was make a completely flexible item system”a system where object-oriented code and thinking almost magically made everything interact in a logical way (*cough*). Well, at least the end result was pretty good. The idea of an item system where you can attach any script on any event is still there at the core. That is why an item in AO today can pretty much do anything to the objects around it: animate, make sound, change the weather, change abilities on characters , move you around, and so on. The only thing it does not interact with in the way we wanted is the GUI.

This item system, I think, was a good investment of time, and its use has been constantly expanded on. Many of the items in the game, including nanos, implants, armor , weapons, utilities, doors, chests, and so on, are various types of similar items.

The Interpolation System

The AO design team was understaffed. The end result was that there was little time to create the content. We needed a dynamic way of creating a lot of content very quickly. The end result was the interpolation system. Basically, with this system, we can cluster as many "templates" (item instances) as we want, making them one item. The defining difference is their "level," or quality level, as it is called in the game. The system enables us to handcraft 2 items and put 200 into the game. We make one template at Level 1 and one at Level 200; then you can ask the system for an item anywhere in between those levels. It mixes those two, making a unique item for the level you request.

I think this is similar to the system actually seen in quite a few other games, just not yet in an MMORPG until AO . With the system, items scale with the characters. The system is also applied to monsters, chests”everything but nanotechnology items. We wanted the nanos to be unique, defining the profession, and I think Andrew Griffin did a great job here. He hand- assembled more than 4,000 nanos. (A nano is our equivalent of a magic spell.)

The good thing about the interpolation system is that it is very easy to make loads of content. The bad thing about it is that things feel similar”they are similar. If one chooses to go with a system like this, it is the drawback one has to live with. What we have learned from this is that in some ways, quantity is quality in an MMORPG”the more, the merrier. It is not enough , though. You need handcrafted, rare objects for the up-market players.

The Categorization System

One of the other things that I believe distinguishes AO from the other MMORPGs so far is its categorization system. We call it the "Categorytree." In this, we can group objects into meaningful categories. Every object can belong to many categories, and we can request random objects from any category; for example, the fictitious weapon "Brutalis-Shotgun" can be added to the shotgun category, which in turn belongs to the explosive weapons category, which in turn belongs to the distance weapon category, which belongs to items you may carry around, which belongs to man-made objects, and so on. This mimics the way people group objects in the real world, so it is quite easy to understand. The trick here is that you can, at any one level, request any object.

So you may say to the system: "Give me a shotgun, or give me a distance weapon." This makes the whole item system extremely versatile. Every object with a meaning in the whole game is found at least once in this system: missions, monsters, nanos, doors, traps, everything. Let me give a simple example. I make a monster. I decide I would like for this monster to drop some loot when it's killed . I can then easily decide the level of abstraction of its loot; it can be everything from one specific item to every item in the game. All the levels in between are possible. This ability to control the level of randomization at the item level is very important to AO .

Truth be told, it was a difficult system to get running. The first iteration of this data system was very unstable and crashed the servers all the time. I can still remember being shouted at by two red-faced programmers because their code depended on this data working, and it didn't.

Anyway, now it works fine, and it is really integral to the heart of our game system.