Dev Diary - Networking 1

Hello Worlds explorers/discoverers/creators! I'm Ciaran, one of the younger programmers on the LEGO Worlds team here at TT. I've been working on the game for over 18 months now on a wide variety of features, but my most significant contributions have been the terrain editing tools and extensions to the terrain generation like caves. But for the past eight months all of my efforts have been devoted to one of our biggest and most requested features: online multiplayer. Making a game run on multiple machines over a network is a monumental task, requiring us to touch almost every element of the game in order to make it synchronise correctly and efficiently, and I'd like to share with you some of the interesting challenges that have arisen. Getting Started Our longer-term fans may remember that we actually released LEGO titles a few years ago that were online-enabled: LEGO Indiana Jones 2 and LEGO Harry Potter allowed you to go on bricktastic adventures with a friend via the internet. So there was already a basic framework in place in our code for networking. However it hadn't been used for five years, which is a very long time in the programming world. So like an old vacant building, it needed a substantial amount of renovation to get it up and running again. Some things worked fine, others needed patching over, and some needed ripping out and replacing. My first month on this task was just spent in a loop of connecting two instances of the game, watching them crash and tracking down the cause to fix it. Getting the old stuff up and running was only the first step. Our traditional LEGO games feature up to two players following a scripted narrative through relatively compact levels and our networking infrastructure was designed to accommodate this. In contrast, LEGO Worlds provides a wide-open, procedurally-generated and fully-customisable world to explore and create with your friends. As such, we need to write a lot of new systems to support these ambitious features. Data and Determinism The most important new feature is of course the terrain itself. Taking this online is inherently a very difficult technical task because of the sheer density of the data. Many players have commented on how large their save data becomes as they play. We continue to work to find new ways of compressing this data, but ultimately there's only so small a representation we can make for the countless millions of bricks each landscape contains. So when it comes to synchronising this data, we really need to do something better than just transmitting it all over the internet to every player in the game, if at all possible. The key is our deterministic world generation. Determinism means that when two machines do the same thing, they get the same result. As you probably know, our worlds are seeded and you can generate the same world as often as you like by inputting its original seed value. Using this fact, we can have client players generate the world themselves most of the time, only requiring the host to transmit regions that have been modified. This means that no terrain data has to be sent at all as you and your friends explore dragon-guarded peaks and skeleton-infested valleys. Interestingly, when I implemented this, I discovered that our world generation wasn't perfectly deterministic after all! I found that there were in fact tiny differences between different generations of the same world, which prevented the games from syncing up correctly. So