The LUNI Archive — October 29, 2019

The LUNI Archive

TLDR: LUNI has been dead for years, go visit https://lusprojects.github.io

As of today, all repositories in the LUNIServer GitHub organization are read-only archives. This has been long overdue as the community around restoration of LU has left LUNI behind a few years ago.

I don’t really have the time or incentive to write a full post-mortem here. The GitHub org is the only LUNI-related platform that I (Xiphoseer) set up and thus the only one that I can shut down.

If you are interested the backstory of this particular project, ping me on LUCH (linked here). But if you are really just interested in LU restoration projects, have a look at the current ones and come hang around on Discord.

Advertisement
Proposal: Federated LU Servers — October 22, 2017

Proposal: Federated LU Servers

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!

A LUNI Reference Page — January 13, 2016

A LUNI Reference Page

In addition to the LEGO Universe Page on this blog, that explains to you the current situation of LU development from a users perspective, I have created a little page describing how the project has evolved, and how you should deal with this diverse past. This is specifically targeted at server owners/maintainers, YouTube creators and others providing content using a distribution of a C++/RakNet LEGO Universe Server emulator, based on humanoids code, with its most prominent example, the LUNIServer project.

This intentionally doesn’t include the drama around this development, you can read about that in the A Bit of Backstory post on this blog. So here you go, the Reference Page for LUNI content creators is now available.

A bit of backstory — December 7, 2015

A bit of backstory

Dieser Beitrag is auf Deutsch verf├╝gbar auf xiphosiade.wordpress.com

I’m not an expert on this topic, but I feel there is the need for some explanation regarding the story of LUNI. I’ve not been around the LU community for very long, but i’ve read a fair bit about it, and talked to some relevant people. If I say anything wrong here, please correct me.

I want to publish this here, because I’m the only person responsable for this blog. This is my personal point of view, and I don’t want it distorted by others on any public site that is not fully controlled by me.

Let’s start at the beginning

What is LUNI? LUNI is a project aiming at recreating a server for the game LEGO Universe. It originated even before LU was shut down, but continued it’s work afterwards. LUNI is an acronym for “Leggendary Universe Nations Iperspace” or “LEGO Universe, Newly Imagined”.

Continue reading