Seeing jamesster’s video on the Outpost LUP world today, I am in awe of what kind of creativity LEGO Universe has produced and how much and diverse content could have been provided through it.

As you may know, I’ve worked a little bit on restoration projects of the game where you get to experience some of the systems on which it runs. These are already quite intriguing, and really show that NetDevil was all in on turning that game into a powerful platform where the only true limit was creativity. And this one thing is what LEGO is really good at inspiring, which just feels like exponential growth to me.

In essence, every world is just a plane with some textures and a height map. On this map there are objects featuring components that would model virtually any capability something in the game could have. It doesn’t matter if the objects you are buying stuff from is a machine or an NPC for example.

When it came to bringing the objects to life, the game used the same powerful behavior system that was available on properties for basically all item features. And if that was not enough, you had fine grain control over the object by adding LUA scripts that could interact with pretty much any part of any object.

This was achieved (in part) by the scripts having access to the over 1000 GameMessages that were used internally within client and server to model all these interactions and attributes that an object could have.

A lot of this was exposed to the developers and artists through a tool called HappyFlower, developed initially for LUPs to create their own worlds, and part of the client. Recently, in a cooperation between DLU and LCDR-U this tools was brought back to life within an alpha client.

But enough on technical details, I want to come to my reason for writing this post: An idealised (and likely irrealistic) concept on what this community could evolve into and a different approach to what infrastructure might be possible here.

In a nutshell, I’d love a federated approach to LEGO Universe servers.

To explain that idea, I need to go into some technical detail again. The LU client only ever connects to three or four kinds of servers. These are:

An authentication server, which can be on any domain, but always on port 1001. This server is responsible for checking that the username and password are correct as well as handing out a session key, which is later used to verify that the client is authenticated.

A world server, which tells the client which map to load and starts up all ‘living’ objects within that world. This means that maps are not static but can behave in wildly different ways as long as all resources are available.

A chat server, which is mostly accessed through the world server, which handles in-game communication and social activity.

A cache / UGC server, used to provide content that the client has not yet downloaded or that has just been created through modular building or BrickByBrick.

The cache and auth server need to be statically set within the client someone uses, while the world server can be anywhere on the internet. The crucial thing here is that you can switch world servers while within the game, without even noticing.

Now the first proposal (which I’ve stated before) would be a central repository for assets and a common database that everyone would have access to. This ideally would be using some version control system as a backbone and as a way to keep it synchronized, because: There should be a number of cache servers from every project that serve this content, much like a CDN would.

This would allow some theoretical load balancing and geographical variety, which could lower costs for individual projects while still making the largely compatible. With how the original patcher works, this would even allow for different feature-branches of the central repo to be served while in development for the different teams from only their respective cache.

Then, as you start into the game, every project has their own authentication server. This server verifies the credentials against their database and returns a key which not only identifies the client, but also the project doing the authentication. Possibly something like “ab345df3223092456fec8686@dlu.org” which would have a standardized format.

Now when you start up your character, you would connect to a world server that does not need to be served by your project, but possibly by one of a creative team that takes part in the federation, or even another project altogether.

I imagine each project serving the basic game ‘campaign’ on their own servers, while using hub worlds like Starbase-3001 to provide access to other worlds. These would be standalone servers (possibly even running different software) run by LUP like creative groups, which use a common API to 1. verify that the player is logged in with a project and 2. get the necessary inventory and achievement data to provide a smooth experience.

The second point has the downside that some projects might make it easier to obtain some items, so we might go for world specific inventory, and possibly make only items from you home project be persistent (to also allow to make that API read only). But it also has the advantage that other programs could fetch this data to provide browser based maps or some forum integration with in-game items and achievements, and much more.

This was the federation explained from a user perspective. From the perspective of a content creator, this would allow to ask a project for a standalone server binary, run that to create worlds on it, get whitelisted with the other projects, and just like that allowing a large playerbase to find and enjoy that content, without the huge overhead of setting up all full-blown project with the ‘campaign’ worlds, the user database, password security and validation, forums, possibly even forwarding chat to the moderation staff of one of the projects.

I don’t see how a single project will ever handle a large quantity of worlds in a non-commercial setting. But I find it much more likely in this proposed way. Projects would develop their own software, which allows them to stay independent, small, possibly closed-source if required, and with all the backbone infrastructure.

At the same time, they’d be handing out binaries that allow registered creative teams to build their own maps while not fracturing the community as these are useless without being whitelisted, backed by and accessed through the project.

This whitelisting also serves the purpose of ensuring that the game remains child friendly. A project as the single source of information on its playerbase has all required control to ensure that no inappropriate content can be shown to their players. Teams going wild would just never get the character data, and as their software would be developed by a project, it wouldn’t even include a way to work without that.

If you want any more details on these thoughts, feels free to ask me here, or preferably in the LUCH discord.

I’m really inspired by what this game can do. Answer the call, save Imagination!