# Patcher, `/res` and the CDClient

Hey there, people! o/

NinjaOfLU and myself (Xiphoseer) have decided that we want to bring to you a series of articles about what goes on inside of a LEGO Universe server. Ninja is a community moderator for pretty much every LU project out there and I am a programmer/researcher for DLU, mainly working on LU-related tools.

LU is a game with big ambitions. The goal was to bring the LEGO bricks to the digital world, to rival other massive games such as World of Warcraft, and in some ways that is exactly what *NetDevil*, the developing studio, delivered.

When we talk about reviving LEGO Universe as a community project, there are two simple goals that people are reaching for:

1. Recreate the game so that everything that was possible back then is possible now. That is logging in with some account, starting up in the Venture Explorer, following the main storyline through Avant Gardens and beyond Nimbus station and explore any of the side quests or achievements that you can remember.
2. Build our own worlds that other people can explore. Back in the day, some LEGO User Groups (LUG) participated in the LEGO Universe experiment through the LUP / Worldbuilder scheme. Many of those were (and still are) hardcore LEGO fans and some of them have kept in touch with the restoration projects. Those groups built the prototype worlds that you could reach from Starbase 3001 and full versions of those were in preparation.

Why does all of this matter for a project such as DLU? Well, the short answer is that both goals fundamentally require the same things and we're going to try present you a long answer in the rest of this article.

## An MMORPG

LU was designed to be an MMORPG, that is a Massively-Multiplayer-Online-Role-Playing-Game. That is a long acronym that tells us a few things about the requirements that the game had. Let me tell you what that means:

1. **Game**: LU is obviously a game. It is meant to be fun and enjoyable. That entails a whole bunch of moderation (see: Mythrans) and it should be a digital counterpart to the traditional LEGO Bricks.
2. **Role-Playing**: There are some games where you just have a storyline that you play through or even just a simple task that you need to fulfill over and over again (like a capture the flag). Role-Playing is different. While you don't necessarily need an open world like Minecraft, the player is still the center of attention. You can choose your faction, choose your specialty, choose the order of missions that you want to do, choose whether to go racing or exploring, build on your property and more. All this is relevant for how the game is set up.
3. **Online**: This is where the server comes in. When you log into LU, you are not just connected to the people you know that also have the game, but to the whole world of LEGO Universe (in your country). LEGO ran a set of servers that people logged into and that connected them.
4. **Multiplayer**: You were not just connected to other people, but you were interacting with other people. You could chat, do a survival mission together, race against each other, work together to get the nexus tower opened, see each other pet, gear or property.
5. **Massively**: This is not really anything that hasn't been said before, but this is about the scale of all of it. Most places you could go had other people there. You would rarely be completely on your own.

So the **multiplayer** and **online** components are what sets us up for a client and server architecture. You have the game on your machine and connect to a machine at LEGO which connects you to all the other people that are playing the game. Also, you wouldn't want people to be able to cheat, so anything that happens needs to be verified by the servers.

The **role-playing** component sets us up for a data-driven game. That means that everything that you see in the game is not just hacked in by some programmer, but actually the work of a game designer, level designer or artist. Any NPC you can meet, and brick you can collect, and item you can consume, any enemy that you can smash, any mission that you complete, every world you can visit - all of that content was created by non-programmers, and so the programmers had to give them ways to get all of that information fitting together into the game. This is what gives rise to all of the subsystems in LEGO Universe - they were all ways of making it easier for people to add new things to the game without directly interacting with the game's code.

## The Patcher

When you wanted to play LEGO Universe, you'd probably double click the item on your desktop, taskbar, start menu, or equivalent. However, this didn't actually run the game, but instead brought up a patcher. This would spend some time loading files, a blue bar along the bottom ticking up, sometimes interminably, before you'd be able to play. This was the patcher, the part of the game which would download the files you'd need to play and update them, before launching the actual game when you clicked play.

If you start the original patcher now, it immediately displays an error. Why is that? It's because the patcher is trying to download information on where to find the most up-to-date version of the game and it can't find that, because there aren't any servers out there to give it that information.

If you launch `client/legouniverse.exe` directly, the game launches and you are presented with the login screen, Bob and all! You can try to log in, but will get an error as the game tries to connect you to LEGO's LU login servers which are no longer running.

When the patcher does work (let's say we pretend that we are lEGO and manage to trick it), it downloads a bunch of things for you before it launches the game. It even tells you what it is currently working on (like *Nimbus Station*), but it turns out those messages just change over time and have nothing to do with the files that are downloaded. *(A note from Ninja here: I feel utterly betrayed, I always thought those were telling the truth!)*

These files are the actual game content. They are rolled into `*.pk` archives by default, but if you were to unpack those (which we can do -- maybe a post for another time), you can see folders like:

* `maps` -- which contains all the terrain and object positions
* `scripts` -- which contains the features that you couldn't achieve just by adding a config value somewhere
* `mesh` -- which is what shape objects have
* `ui` -- which is the user-interface
* `textures` -- which is color, logos, decorations, surfaces

And you can see a file called `CDClient.fdb` which is a database (a set of tables) that ties all of these different components together. The database contains entries that describe:

* All the worlds that exist
* All the NPCs that exist
* Which gear these NPCs have
* What mission there are
* What missions an NPC offers or accepts
* All the items
* Whether you can eat an item, build with it or use it as a weapon
* What happens when you attack with a weapon
* ... and much more