The Fool on the Hill: The Game Engine Problem

I'm at the stage with The Great Game that I need to make a choice of game engine. This doesn't mean that I believe that the game can ever be completed (at least not by me, in my lifetime), or that it will ever be in any real sense playable. I don't. I think that's really unlikely.

But, all my exploratory work thus far on the game has been in Clojure, and Clojure (or another Lisp dialect, but in my opinion Clojure is the best Lisp dialect currently in common use) is what I find most productive to use: it's most efficient of my time. But there is currently no serious game engine which seriously supports Clojure.

A digression: NightMod

There is one Clojure-native game engine, NightMod (sources here). It works and it's delightful, but it seems aimed primarily as a teaching tool, and at developing simple games like 2D platformers. There are no fully 3D examples given; and, sadly, it's no longer under active development.

The Candidates

So what are the game engines I could use? The candidates are, as I see it,

As I've said, none of these directly supports Clojure.

But Clojure is a language which compiles down to the Java Virtual Machine, and consequently it's fairly easy for pieces of code written in Java and in Clojure to efficiently exchange data. A hybrid Clojure/Java program can exist in a single process. That's score one to jMonkeyEngine.

There was at one stage considerable support for a source-compatible variant of Clojure targeting Microsoft's 'Common Language Runtime' (CLR) virtual machine, which would make a hybrid Clojure/C# program equally viable. The project still exists, but it's unclear how well supported it is. If it works well, then Godot and Unity would also be able to integrate Clojure code into a single process.

Clojure cannot be interfaced directly in a single project with C++, but Common Lisp can via the CFFI library. And while Common Lisp is not my first choice of language (and I don't know of any current Common Lisp tooling which I'm comfortable with), the mutability of Common Lisp data structures, while being a feature of which I generally disapprove, is likely to have some performance benefits in game code. So from an interoperability point of view, a Common Lisp/C++ single-process game would also be feasible.

However, it isn't necessary for all the code of a game to run in a single process, and the things I'm doing in Lisp (currently Clojure) are neatly discrete from rendering high quality animated models on a screen. So a system in which a 'client' process, handling user interaction and visual display, and written in C++ or C#, communicated over a socket pair with a 'server' process which handled character knowledge, conversation planning, maintenance of world state, economy models and so on, is entirely feasible.

So let's consider the candidates in reverse order; but first, let's talk about open source, and where I consider the boundary lies between my game as a particular game, and the technology which I create to support my game but which others could use to create their own games.

Open Source and The Great Game

I am intellectually committed to open source; it's deeply embedded in my anarchist view of the world. It's my opinion that a world in which everything that is made is freely gifted to those who need it or wish to make use of it, in which all knowledge is freely shared, is just a better world.

The reason an open source game engine matters is that a lot of what a game engine provides is in the form of library functions, which means that a lot of game engine code exists in any working implementation of every game built with it. Of course one could distribute the code of one's own game open source, and require those who wished to play it to download their own copy of the game engine and compile the game themselves; but, firstly, that's a pretty high bar anyone would have to jump through to play the game, and secondly, game engines in active use are all being actively developed and updated, so any code I released would have to be continually maintained to keep in step with the game engine it was written for, or it would become unusable.

The alternative is to release the game as a conventional, proprietary, closed product. That's what the makers of the commercial game engines expect you to do and want you to do: they make their money not on selling their game engine to you, but taking a cut of the price at which you sell your game to others.

Of course, I could release the code parts of my game as a stand-alone module, communicating over a socket pair, which other people who were interested in using it in other games could integrate with the game engine of their choice.

In any case, I see the code that makes the game work, and the actual world and story of the game, as separate things. I intend to give both away for free, yes; but I'll give the code away with the intention that others should be able to freely copy and modify it as suits them. I'm not yet certain how happy I am with people modifying the story elements; I certainly wouldn't want modified versions being distributed as instances of my game.

But that's a problem for if I ever get anything sufficiently finished that there is a game that other people can actually play.

Unreal Engine

Unreal Engine is almost certainly the best game engine out there today. It's certainly the best supported and has the most features which would make building the sort of world I want to build easy. It's an engine designed, built and used to build very large, very cinematic, game worlds, and is used by many large game studios to produce very high production value games. It's probably the engine in which I could most quickly produce a playable game, and it's certainly the engine in which I could most easily create a very good looking game.

It's written in C++, and encourages the writing of game code mainly in C++, but as I say that's not an insuperable problem. What feels for me more of a problem is that the game I produced (if it ever were finished) could not be given away. I probably never will produce anything playable -- I'm too old, it's too big a project, and I have too many other things I must do. If I give up the idea of ever finishing, then Unreal Engine would be a good choice. But if I then, to my surprise, did finish, that would be sad.

Unity

Unity is also a big commercial game engine, with all of the disadvantages for me that that brings; and somewhat worse than Unreal, because the company that makes it is seeking to take a bigger cut of game revenue. Against that, it has no significant benefits vis-a-vis Unreal; it can be used to build very high quality games, but its support for large open worlds seems to be poorer and its ecosystem of third-party add-ons seems to be poorer. The company which produces Unity has also laid off a significant number of staff in the past year, and may be in trouble.

I see no benefits of Unity over Unreal. Compared to the open source engines it's better supported and has a better portfolio of high quality games produced with it, but if you feel that the support and portfolio offered by proprietary engines justifies making the compromise of using them, then it seems to me Unreal is just better.

jMonkeyEngine

jMonkeyEngine has been in continuous development for fifteen years and seems to have a reasonable community and a dedicated development team. It's much less sophisticated than Unreal Engine. It has far fewer features and there is far less third party support. There are no very high production value games that have been produced using jMonkeyEngine; this doesn't really matter because there's no way I could really produce such a game anyway. The production quality of the best games produced with it is adequate.

However, it's open source, it targets the Java virtual machine which makes it play reasonably nicely with Clojure, and it's good enough. The tooling is OK. And there's lots of experience out there of using it in concert with other open source tools, such as Blender.

Of relevance to me is that it is primarily a 3D engine, with good terrain and physics support; and while no-one has yet tried to use it to build as large a world as I envisage, the architecture should in principle support large open worlds.

There's also an excellent library, jme-clj, that not only makes it easy to integrate Clojure code with jMonkeyEngine code, but in practice allows you to do a great deal of jMonkeyEngine development from the Clojure REPL, which I find much more congenial.

Godot Engine

Godot engine is more than a decade old, and has again been under continuous development since then, with a good development team and plenty of community support; and it's also open source. While its 'home' language is C#, and its default target is the CLR virtual machine, it does have support for a number of other languages. And the very best games written with Godot have massively better production values than any games produced with jMonkeyEngine.

However, it seems a poorer fit for me. It's primarily a 2D engine, and doesn't seem to support large 3D games well. There is no native terrain support, although there is a third party terrain plugin available. Also, while a number of languages are directly supported, neither Clojure nor Java are.

Tentative Conclusion

It seems to me that of the commercial engines, Unreal is the clear winner. Of the open source engines, jMonkeyEngine feels like the better fit. The choice comes down to two issues:

1. Ideologically, open source matters very much to me;
2. If I actually do ever finish anything, then if it's built with open source libraries I can give it away; if it's not, I can't.

I think that means that, although I think I could create a better-looking game with Unreal, and that I'd be more likely to get something finished with Unreal, jMonkeyEngine (by which I mean, largely, jme-clj) is the correct choice for me.

Share on social media