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.