So, I ran into this question on a hiring form, and I think I gave a really brief answer and didn’t really think hard about it. But the question stuck in my head and I figure that answering it here is appropriate.
So, you guys know me as a Unity guy, but I have worked on other things as well, both before and after learning Unity. My particularly proudest achievement was my work on qCraft.
qCraft is a project that brings some of the high-level concepts of quantum mechanics into Minecraft. The project had already existed for some time before I started working on it; Dan200 (Daniel Ratcliffe) did most of the original work on the project, and it was already a very cool mod, with things like blocks that appear or disappear based on observation, and even work in multiplayer.
What I was tasked with on the project was making a system to teleport between active servers. Dan200 had been approached to add this feature himself, but he said “It can’t really be done.” Please don’t judge him for this statement; Dan200 is SUPER talented, and quite frankly I know what he meant. This is the answer you learn to give to non-technical people (like managers and marketing folk) when a task is complex and tricky and likely going to cost more time than anyone would figure it’s worth.
Somehow, my company PlayHabit (Now defunct) ended up as part of this project, and I was asked if I thought it could be done. I said yes, and I could do it.
It was a leap of faith of sorts, as I hadn’t actually used Java before, and I had never looked at Minecraft code. As a programmer, you make these little leaps all the time, as learning new things is just a standard part of any project work.
The mod “system” for Minecraft was not really official; it’s been built up by the community and involves quite a bit of reverse-engineering. This is all approved by Notch; he wanted a mod system but never had the time to plan it out.
As such, we ended up using the “Forge” mod platform. It’s basically a mod for Minecraft that tries to expose aspects of the engine in such a way that it’s easy to extend without changing the core source files (They had already been modified in a way so that you rarely needed to).
So, I started learning the platform and how Minecraft was organized. I had a lot of help from Dan200, so that was a huge plus. But I quickly found that we needed access to some parts of Minecraft that weren’t exposed explicitly by Forge. Minecraft NEVER does a server reconnect while you are in game; there’s no hooks for it at all. So I had to switch over to a core mod.
A core mod means I have to change code that is part of Minecraft. It was in one of the main files too (I forget some of the implementation details, my apologies). I basically set it up so that there was some additional data used for checking for a new server, and later for inventory storage/transfer. And I set it up so that if the IP data for a new server is present in these variables, the main loop picks it up and whisks you away to your new server.
Now, I got the system working after a few weeks and I was super excited about it, but there was one more step. See, while Notch’s license allows you to modify Minecraft however you desire, there’s a stipulation that you can’t redistribute the Minecraft executable. It has to be installed alongside of it. This means that the installation process can’t rely on just modifying the files.
Forge has a low level system that allows you to specify a new file to replace an old file, and it does this as the files are loaded. This replacement however relies on Java bytecode; basically the assembly-equivalent of Java. The easiest method is full class replacement, because you can just compile your modified file into bytecode and inject it at runtime; you don’t have to know any Java bytecode to do this.
I got that part working by following this tutorial. At the time, this was the ONLY PAGE ON THE INTERNET THAT I COULD FIND that explained how core mods worked. And the instructions, as written… didn’t work.
After a few days of raw experimentation using this guide as a base, I FINALLY got the mod system to accept my changed file. Hallelujah! Party time!
But there was one more problem.
qCraft is also part of a package that we were supporting geared towards educational institutions that use Minecraft as part of their syllabus. (I don’t remember the name, if you know what I am talking about, put the info in the comments.) This mod had it’s OWN core modifications, which were full file replacement. For the time being, I was able to support this by just creating a separate version of my modified file that was based on their modified file. But if they made any changes to this file, it would break. And they changed this file a LOT.
So I had to support PARTIAL bytecode injection. Again, that tutorial linked above was the only thing with any information on this. I had to set up a system that basically searches for tokens (In bytecode, not in regular Java) where I needed to make my modifications, and then make them, and have it all work afterwards. I can safely say I now understand Java bytecode more than most people, and through force of will and perseverance I finally got the injector to cooperate.
So, that’s my most proud achievement: I wrote a mod for a game that I had never worked on before, in a language I hadn’t worked with before, and another lower-level version of that language that quite frankly I didn’t know existed before this. And I got it done in time for the deadline.
qCraft is the first and only mod that allows you to build connected teleporters between servers on different IPs, and it’s the only mod that allows you to carry inventory between servers.