Reflecting on 10 Years of Open-Source Uru

[Paradox]

It was 10 years ago today that Cyan unexpectedly released the source code for the Uru game engine client and related development tools. I recall thinking it was inconvenient timing, because I was less than a month away from being finished with school, but right in the middle of final projects and exams when the source was released. It’s funny looking back at all the excitement – and politics – and seeing where it led to.

A lot changes over the course of 10 years. Sometimes a lot stays the same too. Our group of developers has seen people come and go over the years, and I’m incredibly grateful to get to work alongside many of these people — in some cases for over 15 years developing tools and Uru-related projects long before the engine codebase itself was released. It’s not an understatement to say that Uru is directly responsible for my becoming a software developer, and I owe a lot to these folks who patiently explained concepts and patterns to self-taught younger me.

A lot changes in a codebase over the course of 10 years too, and that’s what I want to focus on today.



There have been almost 700 pull requests merged to the Plasma project since we mirrored the original source code on GitHub. Some of the highlights include:

• Replacing the Visual Studio 2003 project files with the CMake build system, which allows building on multiple platforms with various compilers and IDEs.
• Updating the physics engine to PhysX 4.1 which is open-source and cross-platform.
• Updating the scripting library to Python 3.9.
• Simplifying management of library dependencies, and writing new user-friendly build instructions.
• Significant code modernization by adopting features of new C++ standards in favour of custom implementations.
• Various performance improvements and gameplay enhancements, such as clipboard functionality and widescreen support.
• Lots of code cleanup to allow for 64-bit and (in future) native macOS and Linux clients

This work has been a group effort, with lots of contributions from the core H’uru team as well as numerous community contributions. A big thank you to everyone who has contributed to Uru over the years, whether through code changes, bug reports, tutorials and documentation, or gameplay testing.

(Originally posted on the Guild of Writers blog)

[Bert_2]

Congratulations to the whole H'Uru team for all this great work and tremendous progress. I've only recently reintroduced myself into the world of online Uru, and I'm very glad to see that some of you are still around making an impact. I'm also plain excited about both the prospect of a native Linux client and the new fan ages finally releasing to the wider public through all the great tools you all have made. I take my hat off to you!

[Christian Walther]

What strikes me as odd is that a large majority of those contributions – 5½ of your 7 highlights – are not (directly/mainly) user-visible. I would have expected more people to jump in to fix their favorite UX peeves as I did.

[Tsar Hoikas]

I think a lot of them are author-visible though, especially to authors who are regularly building the code, especially if their platform is not Windows . But that doesn't answer the question about why more contributors haven't appeared to fix their own peeves.

[Paradox]

I think one of the challenges for a long time is that compiling your own client was a huge and daunting task, with unclear instructions spread across multiple places that always seemed slightly out of date and a million dependencies to wrangle.

Two of the more recent changes we've made to the codebase are to standardize on Microsoft's vcpkg C++ package manager for downloading and building all the required dependencies, and our new easy-to-follow build instructions. Seriously, if you follow those instructions you can pretty much grab the code, open it in Visual Studio, walk away for a bit, and come back to a compiled client.

Even better, we've also set up GitHub to make builds automatically every time a change to the code is merged. These "nightly" (although they're not on any schedule) builds are available to download too. Click a build, then click on Artifacts and you'll see various combinations of clients you can download and run without needing to compile the project yourself.

We're encouraging people to report bugs and long-standing known issues and pet peeves, partly so that they are captured somewhere, but also so that we can triage them. Many of these issues probably have easy fixes, and we can tag them as "Good starting points" for people wanting to get involved. (Our project site also has a whole page about how to get involved, and not all of it involves code!)

[Sirius]

The problem is, few people can code in Python, Java or C#. Even fewer in C++ on a complex multiplayer engine. (I can do a bit of C++ but nothing big.)
People who are likely to be skilled in C++ are also the most likely to have the patience to dust off the 20 years old codebase to clean things up before adding new features (and by features I mean things like UI improvements, as opposed to regular bugs and crashes). This means end users won't see much difference with the engine, but it's still getting more stable and more future-proof (one such example of future proofness being the FOV fix).

Seriously, if you follow those instructions you can pretty much grab the code, open it in Visual Studio, walk away for a bit, and come back to a compiled client.

That definitely will help. I've been meaning to try building my own version of the engine to tweak it, but have always been reluctant to step through obscure debugger messages to figure out how to set things up.
With that said, I don't have a lot of time for Uru-related things, so I usually spend it on things like ZLZ, Drizzle or Blender. Those take up enough of my time and skills.