Source Code

If you’re wanting to have a gander at the source code that went into the game executable, then here it is!

We have a GitHub repository, first and foremost, but if you don’t want to work with that, then we also have downloads are in two formats: torrents and direct downloads. If you have a BitTorrent client (and if you don’t, we recommend qBittorrent), we highly recommend the first option – it’s much easier on bandwidth, and downloads are pausable and resumable, too! Of course, if you’d prefer not to get a BitTorrent client, then the direct download link is provided as a second option, too.

Official Game Executables Source GitHub Respository

Game Executables Source Download (117 MB)

Torrent / Magnet Link
Direct Download

This contains the source code for the MLI game executables in the form of a Code::Blocks project. It makes use of a number of different libraries; to compile it, you’ll need the following:

On Windows, this is as simple as getting the development libraries for all of these and then copying them to C:\Program Files (x86)\CodeBlocks\MinGW (or wherever you installed Code::Blocks to).

On OS X, you’ll want to get the frameworks for the SDL-related libraries from the links above and install them to /Library/Frameworks, whereas for the others, you can use Homebrew – just install it, and then in a terminal window type “brew install ffmpeg”, “brew install cryptopp”, and “brew install curl” to get the rest. The Code::Blocks projects should be able to pick them up from where Homebrew installs them. You may also need to update gcc with “brew install gcc48”, in which case you’ll need to update Code::Blocks’ GCC compiler settings by going to Settings > Compiler… > Toolchain executables, updating /usr/ to /usr/local/, and changing “gcc”, “g++”, and “ar” to “gcc-4.8”, “g++-4.8”, and “gcc-ar-4.8”, respectively. (GCC 4.8 is needed to properly link against the version of Crypto++ installed via “brew install cryptopp”. Versions of GCC 5 and later will encounter a linker error.)

The source code for the MLI game executables is released under the MIT license. Details can be found at the top of any source file.

Also included in this download, in the folder “common-data”, are the files compiled into the common.dat resource file.

Legacy Java Case Compiler (+ Game Executable) (557 MB)

Torrent / Magnet Link
Direct Download

This primarily contains the Java source for the now-defunct case compiler written in Java, but also as a consequence contains the source for the game executable in Java, since the two share the same code. This was used to create the first case in MLI, but now that the first case has been released, it’s being abandoned now that development can begin in earnest on a proper user-friendly case creator. This is being released primarily just for the sake of completion, for those academically curious. It can theoretically be used to create custom cases, but that isn’t recommended, because seriously, it’s not very good – the case creator will be way better. If you really want to see its compilation in action, after compiling, run, then load src/case1.mlicasesource, and click Compile. This will only work in Windows, due to needing to use some helper executables for certain steps. Seriously, like I said, most are better served just waiting for the case creator, which will support all three major operating systems.

The source code for the Java case compiler and game executable is released into the public domain.

Also included in this download, in the folder “data”, are all of the audio and visual assets in the first case of MLI.

13 thoughts on “Source Code

      • Well, it’ll take you ten seconds flat, and everybody can collectively work on fixing bugs, which really makes your all’s lives easier, so people aren’t nagging you constantly (Since bugs plague every product immediately after release). It’s a way of giving everyone a hub where they can patch the project, and gives all kinds of tools for doing so. Basically, it’d be foolish not to put it on GitHub immediately, as it’ll cause you far more heartache in the long run. If a “break” is what you’re after, why not let the community fix bugs and add new features, rather than doing it yourself?

        The alternative is to let the rest of us upload it to GitHub ourselves, and have tons of different repositories, all with different bugfixes and changes, all of them good, making it near impossible to merge all the changes together, since none of them would be official. Putting your source on GitHub (Or BitBucket, or other such site) as fast as you physically can is literally the best of all worlds. We’ll just patch things that are broken, create pull requests, and with a click you can integrate them into your own project. You can even release official updates later on thanks to our changes. Worst-case scenario, it’s one less torrent you have to seed.

        • Okay, okay. While I’m dubious of the idea that not putting the source code there immediately would cause innumerable fan-created depots that would then cause mass chaos, I’ll look into uploading the source to GitHub tonight.

          • Well, no, but I’m impatient. I wanna start hacking at the bugs I’ve found already. XD


  1. Every time I try to compile the source it complains that it cannot find -lcryptopp.
    I took the newest crypto++ library from the link you provided and put its contents into the folder MinGW/include/cryptopp but it seems there is some cryptopp.h file missing.
    Could you maybe take a look into it?

    • You need to compile Crypto++ yourself by putting its source into a folder, then using the gcc bundled with a Code::Blocks install to build it, then copying the resulting cryptopp.a into MinGW/lib and copying the .h files into MinGW/include. That should make the project able to pick it up.

      • Okay, I finally managed to make it work. In case anybody else comes up with this problem under Windows, here is how I did it:
        I downloaded the GNUmakefile from and pasted it into my cryptopp folder.
        Then I had to copy the adhoc.cpp.proto file to adhoc.cpp. (Renaming should work as well).
        After that you can just follow the instructions on that website I linked before. (Hint: you can temporarily change your PATH variable by using “set PATH=PathToMinGW\bin”. It will only change it in your current commandline window. Works in batch files, too.)

        I still can’t compile the update helper, though. It aborts with a few messages about elements not being defined in that scope.
        src\main_UpdaterHelper.cpp:95:32: error: ‘fork’ was not declared in this scope
        src\main_UpdaterHelper.cpp:99:36: error: ‘execv’ was not declared in this scope
        src\main_UpdaterHelper.cpp:104:47: error: ‘waitpid’ was not declared in this scope
        src\main_UpdaterHelper.cpp:107:38: error: ‘WIFEXITED’ was not declared in this scope
        src\main_UpdaterHelper.cpp:108:40: error: ‘WEXITSTATUS’ was not declared in this scope
        src\main_UpdaterHelper.cpp:113:60: error: ‘S_IRGRP’ was not declared in this scope
        src\main_UpdaterHelper.cpp:113:70: error: ‘S_IXGRP’ was not declared in this scope
        src\main_UpdaterHelper.cpp:113:80: error: ‘S_IROTH’ was not declared in this scope
        src\main_UpdaterHelper.cpp:113:90: error: ‘S_IXOTH’ was not declared in this scope

        • What platform are you compiling on? Windows? If so, UpdateHelper is OS X only – it’s not intended to be compilable on Windows. It’s unneeded on that platform.

          I probably should’ve made a note to that end somewhere in the source. Sorry about that.

          • Just for the sake of having a complete conversation:
            Yes, I do compile it on Windows.

            Thanks for the answer.

Leave a Reply

Your email address will not be published. Required fields are marked *