The Fugue Counterpoint by Hans Fugal

24Oct/150

An outsider’s view of Minecraft development (Fall 2015)

I'm a programmer and a father. I want to teach my kids programming. My kids love Minecraft. Programmers can write Minecraft mods and plugins. It seems natural to teach my kids to program with Minecraft.

I am not a Minecraft aficionado. I know the game, sure, and I can even make it through the first night in survival mode. But to me it's just a game in the periphery of my consciousness. So I was dismayed when I started looking into writing Minecraft code, and discovered that keeping up with the various ways you can code in the Minecraft ecosystem requires a level of fanaticism and devotion that I just don't have. And unfortunately there is no page out there that covers the pros and cons of the various options, not really even one that is out of date. And the landscape has changed considerably in the past 1.5 years.

This is me writing such a post, for this moment in time, for those people who are programmers and familiar with Minecraft but are not Minecraft fans who already know the various plugin and mod frameworks by reputation as users.

Client and server are the two easiest concepts. They're exactly what you'd think. Hooray!

A mod is something that changes the behavior of the server (usually) or the client (less often) or both. Usually very hacky, i.e. developed against decompiled Java classes, and you trick Java into loading your classes instead or in addition to the usual Minecraft code. This is low-level hackery, made a little easier by Minecraft being written in Java. Mods are plagued with being out of date as Minecraft progresses, but the real popular ones with lots of support will stay up-to-date pretty well.

A plugin is code written to interact with a Minecraft server (or client, less often) via a well-defined API. The plugin is generally hosted by a mod that provides the API and proxies events, commands, etc.

Minecraft proper supports neither mods nor plugins directly. There is no official API or way to interface. But the scene is vibrant all the same. Various frameworks to support mods and plugins have sprung up. Some have died off but tutorials, books, forum posts, and so on still pollute Google and bookstores. As far as I can tell, the most important frameworks are as follows:

Forge provides a basic mod wrapper around decompiled Minecraft. If you use the Forge server (and launcher), you can choose the Forge mods to have enabled, and as a developer you have a bit more stable of an API.

Bukkit was the king of plugin frameworks, until it imploded in 2014 (due to a DMCA takedown by a bitter developer). CraftBukkit was the server mod that would host Bukkit plugins. It's probably possible to find the CraftBukkit jar still, but legality is grey at best.

After Bukkit imploded, the ground was fertile for dozens of replacement attempts. Now a little over a year later, it seems like there are two leaders. First, Spigot is a Bukkit-compatible API and has a server mod. It claims to also be a bit more performant than CraftBukkit, and I think it might have existed as a more-performant Bukkit since before Bukkit imploded. Since Spigot supports Bukkit plugins, and Bukkit was the most popular plugin API by a long shot, Spigot is now the most popular framework (the second is CraftBukkit, still.) You can see all this and more at the beautiful http://mcstats.org/

Sponge is taking a fresh (and purportedly improved) approach on the plugin API. It's not compatible with Bukkit. It's also not done, but it looks like it's probably functional. Legally, it's probably on much more stable ground than Spigot, however Spigot doesn't seem to be under any serious contestation so pragmatically speaking Spigot is probably the better choice unless you especially like the Sponge api or philosophy. Especially given the wealth of documentation, books, tutorials, etc. aimed at Bukkit which are mostly still relevant with Spigot.

Glowstone/Glowstone++ is a from-scratch server that supports the Bukkit API. It's meant to be faster, simpler, completely open source, but not 100% identical in behavior to vanilla Minecraft. It looks like a viable alternative to Spigot's server mod, but you don't have to decide up-front. You can write a Spigot plugin and use it on Spigot, Glowstone(++), or even old CraftBukkit.

So, the executive summary is it looks like you probably want to use Spigot, and you can use learning materials written for Bukkit. If down the road Spigot implodes and takes Glowstone with it (because of API copyright or something), then Sponge might be poised to be the successor. Or maybe once you've got some experience under your belt you'll find Sponge more attractive (and perhaps more complete, by then).

Hope that's helpful!

17Nov/083

Clojure DSP Longing

I often find myself longing to be able to use Clojure, a very enticing lispy language that runs on the JVM.

I could possibly be using it right now in my dissertation research. It has the promise of dynamic languages, functional programming, almost-as-cool-as-Erlang concurrency, JVM performance, and Java library soup. It could be so awesome. A few months ago I started briefly down this road, unaware that…

Clojure sucks. Not generally, but it sucks for DSP. More specifically, Java and therefore Clojure has no real support for complex numbers. In order to do serious DSP, you need native syntactic, semantic, and performance support for complex numbers. Java has none of the above. Older versions of C didn't have syntactic or semantic support, but the performance of using arrays was plenty fast. Not so in Java, at least not to the extent necessary to override the lack of syntactic and semantic.

So someday, when I'm writing general purpose code again and not high performance DSP code, I will have an opportunity to use Clojure, and I think that will make me very happy. By then the book will be out of beta. The community will be in full swing. There will be awesome libraries. Children will play in pristine parks with formerly-ravenous ravens.

In the meantime, if anyone sees the scene change, do let me know.

8Jul/062

Duck Typing Defended

Ever since I discovered ruby I've loved dynamic typing. I never paid much heed
to people who got their knickers in a knot over how dynamic typing is "unsafe".

While working on Ardour this
summer
, I've literally been wrestling with C++,
all because it is statically typed. The code I've been writing over the past
month could have been done in one week with half my brain tied behind my back
(which is the usual situation, by the way), if only C++ were dynamically typed.

In other ways static typing hasn't exactly got in my way, it just causes me to
jump through hoops that seem silly, unnecessary, and inelegant. A simple
concrete example will help. I'm doing undo serialization, and of course Ardour
already serializes other things in order to save sessions. In C++ this means
lots and lots of otherwise unrelated things all inherit from a common
serializable base class. This is why multiple inheritance is necessary in C++.
In Java you can use interfaces, which is better than multiple inheritance but
not by much. In dynamic languages, you don't even have to give it a second
thought. You just make sure everything that needs to be serialized responds to
a serialize method, et voilá!

So as I've been wrestling I've had this nagging feeling that it's *me* that's
broken, not C++. Have I become so spoiled by dynamic languages that I can't
program efficiently in a static language anymore? Are the static people right
and one day my whole world will come crashing in and all my ducks will keel
over? Feelings of self doubt are part of being human, and these were some of
mine this summer. Then I read a blog post by Bruce Eckel on Strong Typing vs.
Strong Testing
and my mind was put at
ease. The thrust is, dynamic typing is good, and testing is necessary. I think
this quote about Robert Martin (a C++ guru) sums things up nicely:

Robert came to more or less the same conclusion I have, but he did so by
becoming "test infected" first, then realizing that the compiler was just one
(incomplete) form of testing, then understanding that a weakly-typed language
could be much more productive but create programs that are just as robust as
those written in strongly-typed languages, by providing adequate testing.

I have a thought along these lines. Let's say you've got duck typing in full
swing as in his examples. Now in the real world it sometimes happens that you
choose a common ambiguous word for the duck method, like "run" perhaps, but
more often than not you have methods that are named fairly specifically, like
"speak" or "jump". The static argument is that you might accidentally call the
method on something that won't do what you anticipate because it's not of the
right type. But really now, how many of your objects that implement "jump" are
going to be the wrong kind of objects in your application? Often the answer is
none. So you jump through hoops for no reason.

Do read the article, it's fun and well-written. Even if you come out still
clinging to your beliefs that static typing is Good and Wholesome, at least
you'll see that us dynamic people aren't necessarily lazy, stupid heathens.