Object Layer Architecture

Some time ago we started discussing the architecture of virtual objects on Web pages. In this posting I will try to explain some key questions and considerations in building an infrastructure for virtual objects which appear on web pages.

First I will quickly write about our goals:

• We will put objects on Web pages in addition to avatars. 
• People will have inventories as known from many other games. 
• Objects can be installed on Web pages by dragging them from the inventory to the page.
• People can use objects on Web pages in various ways including crafting.
• Objects can interact on Web pages.
• Objects encourage communication.
• Objects are used for gaming in casual and highly engaged variants.

Here is an impression of many different kinds of objects (in practice you won't discover all of them on the same page):

Issues to take into consideration while discussing the software architecture:

1. One World

There is only one Web. All users can see each other and chat everywhere. All objects should be visible to all users. There should not be separated servers as in many Online RPG (called realm in World of Warcraft and shard in Ultima Online). 

2. It's Big

We expect many users and many objects. The amount of data and processing required is more than fits onto one physical server. Clearly the system must to be distributed. It needs multiple servers. Each server manages a part of all objects. Preferably the architecture is a shared nothing system which organizes itself without a management layer. 

3. Interaction

Objects belong to users. They are in a user's inventory, but at the same time, objects interact with other users and other user's objects on Web pages. A distributed system where objects interact with other objects on remote servers is very difficult. So, we try to make interactions local on a single server. This means, that only objects in the same room can interact. This sounds reasonable.

4. Open World Assumption

The object layer on Web pages should be open to other object systems. This project will create software to put objects on Web pages where avatars already are. Other projects or companies should be able to create their own object system and send their objects into the same chat rooms on the same Web pages. All users should see all objects of all object systems. They might not be able to use all objects, but everyone has the same view to the world. 

5. Chat and Messaging

We are living in a world of chat systems. Avatars on Web pages are created through chat rooms and chat protocols. Objects on Web pages should use the same or similar protocols. Objects should fit into the existing world. 

Architecture design decisions:

• All objects belong to users. 
• An object server manages user inventories which in turn contain objects. 
• A chat room on a Web page is like an inventory.
• An object is in only one inventory or room at a time.
• Objects can migrate between inventories.
• Object servers host complete inventories.
• Interactions happen only between objects in the same inventory hosted by the same server.
• If an object is moved from user inventory to a Web page, then it migrates to the object server which hosts the chat room of the page. 
• Users trade objects via temporary trade rooms .
• Rooms, inventories, trades are identified by utf-8 strings.
• Objects are identified by (large) numbers. The numbering is globally unique across all inventories. 
• Object servers create chat bots to put objects into chat rooms.
• We are planning for 100 k concurrent users (10 Mio. registered)
• We are planning for 100 objects per user inventory by average. Stacks of identical objects count as one. An inventory may contain 1 Mio. objects, though this needs hierarchical organisation, aka folders.

Here is an architecture diagram:

Now we can start programming.

Coffee and Cola Sample Implementations

I implemented a crafting process in the item server and the portal.

I am using two examples to check if the details make sense: coffee machine and cola dispenser with their respective ingredients and products.

The image shows all items which are currently defined. Most of them are for testing various functions.

This is a view of my visible inventory. One of them is a cola dispenser, a cola machine which makes a noname cola from water and syrup. It also needs energy. If I click the cola machine, then ...

... I see details of the cola machine. The machine is already equipped with water, syrup and batteries. It has a button to produce cola. When I press the button ...

... then I get an additional item, a small can of cola. Actually, a noname cola. Not very fancy, but still.

(For game designers: all item interactions are modeled with items. We took some days to replace a property driven model by an item driven model. It might be a bit less realistic, but manipulating items is more fun than manipulating item statistics.)

I can click on the cola can and see the datails ...

... including a button which lets me drink the can. Usually I won't drink it myself. I would offer it to visitors of my web site. If someone else drinks it, then we both get social points.

This is all just in aplain white design, actually not really a design. Only the bare minimum to check HTML/CSS structure and classes.

There will be a real design later. What about the green we were used to? or facebook blue? What do you think?

For developers: the item server has now 63 unit tests, the portal is still at 69. There are 74 different types of properties, which manage all item interactions.

Next steps: we will implement a little bit more item interaction, including damaging some stuff. After that we will turn back to the client and add a cool avatar display.

Neptun: Virtual Items Server

Avatars will have an inventory of virtual items. They will be able to buy, sell, build, trade and loot virtual items. A server manages all these items and everything you do with items. Over the last 3 weeks we implemented such a component. This is our first version of a virtual item server. It is called "Neptun".

In October and November we implemented a first version of the web portal and a simple form of an inventory. Back then, we simulated our items. Now, they are real.

The inventory is now populated by the item server. In other words: items are alive inside the item server. If you see them on the web portal, then the portal fetches all it needs to display them from the item server. As usual, items are also stored in a database for safety. But in the database they are only passive. In the item server they are active and you can do something with them.

What you can do comes later. For now these items have a place to be seen (the inventory of the portal) and a place to live (the item server). It is actually much better to see virtual items on a web page of the portal, than in the item server. On the portal they have translated text and images.

Developers can also see items in the item server, but this is much more bare bone. So, this is how Neptun looks like. It has a web user interface, but it shows only technical data. There is a list of item numbers and item properties. Not much for the user, but very informative for developers.

For the programmers: Neptun is implemented in C#. We program, debug and test in MS Visual Studio 9. Then, we run the program on Linux with mono.