Suggested Impressions of Terasology as a Minecraft Modder/Minetest Player

[asanetargoss]

A few things finally spurred me to try out Terasology:

• Minecraft updates have been speeding up and some members of the modding community have been difficult catching up. To be fair, I've just been chilling on an older version so I can't really attest to the exact impact this has had.
• Minecraft Forge has decided to use name mappings from Microsoft, under a license that a lead Forge developer has raised legal concerns to Mojang which have not been resolved/answered.
• Leadership issues in the Fabric community raise questions about the sustainability of the project as an alternative to Forge.
• I've played Minetest in the past and have been meaning to try out Terasology for comparison

My first impressions are:

• Almost zero gameplay-related documentation is available publicly from a web browser
• The default game that ships with Terasology (Josharias Survival) produces an experience that is overall just not as good as some Minetest subgames and self-customized worlds I've tried. The overall experience of Terasology + the game, from the performance, to the UI, to the game design, to the sound design, is just not good. The only thing I liked better compared to anything Minetest was the terrain graphics, after I turned off some of the more ridiculously expensive graphics settings.

I would say, at this time, I would not recommend Terasology to anyone, as far as gameplay goes. I think that Terasology has a better technical foundation than Minetest due to the choice of programming language, and I suspect that Terasology's engine is more future-proof (I worry about the future of the Irrlicht engine). But from my limited exploration (github wiki), it seems Terasology makes some similar mistakes to Minetest with regards to plugin loading and security. The Minecraft modding community is very much "anything goes" and there are a lot of modders who are very busy doing their own stuff and working independently from each other, so less friction is favorable there. I can't say much with regards to networking as I have not tried Terasology multiplayer. However, I will say that Minetest's client-server design is not suitable for any sort of advanced modding, but seems like it is suitable as a sort of, "web browser" for voxel games. A scripting sandbox with limited capabilities.

I'm sure you've heard plenty of feedback already about the Terasology experience and I know these are not easy to solve. One piece of tangible advice I can give: add more gameplay-centric sections to the Terasology forum, for example a section for curated module collections, and a section for texture packs. IMHO there should be a top-level forum header for "Playing Terasology" (or similar), and it may be a good idea to move the Modules section there (perhaps a "Module Development" section could be created in its place if a more developer-focused section is still needed. I'm inclined to avoid using Discord for discussion of long-term value, as content in Discord is locked behind an account, and not accessible to search engines or web archival bots.

 

[keturn]

Your concerns with the relationship between Fabric, Forge, and Microsoft-Mojang are much the same reasons I had for looking like projects like this.
I haven't given Minetest much attention; I fear C++ has too much C in it to be safe from memory integrity errors, and I have no interest in building more software on that foundation.

I'd say your first impressions are mostly accurate. There isn't a lot of gameplay documentation because, frankly, there isn't a lot of gameplay. I'm with you on not recommending it to players as an alternative to modded Minecraft at this stage.

The more interesting question to me is whether it's something you'd recommend it to modders. If it's a viable platform for developers to build their ideas on (so long as they are willing to forego the massive name recognition and install base that comes with mainstream games).

But from my limited exploration (github wiki), it seems Terasology makes some similar mistakes to Minetest with regards to plugin loading and security. […] However, I will say that Minetest's client-server design is not suitable for any sort of advanced modding, but seems like it is suitable as a sort of, "web browser" for voxel games. A scripting sandbox with limited capabilities.

That's the one part of your first impressions that I suggest you re-examine. Modularity is, more than anything else, Terasology's guiding principle. Yes, it's built with a sandbox so that players are at less risk from experimenting with random modules, but modules are very capable when it comes to the game world. Modules are responsible for things as varied as world generation to rendering. The intent is for the engine to only have things like the main event loop, networking, persistence, and the core interfaces for defining and modifying these block-based worlds.

add more gameplay-centric sections to the Terasology forum, for example a section for curated module collections, and a section for texture packs.

A lot of the infrastructure of the Terasology project is built on this sort of "if you build it, they will come" principle. Design for the kind of participation you want, not the kind of participation you have.

But, well, this forum is too much an empty ghost town as it is. Curated module collections? There are a few, but the curators are the same people as the developers, and they have more developers than players. Texture packs? There's enough work to do to just maintain one texture pack, there haven't been enough others to be worth dedicating a section to them separate from other modules.

I'm inclined to avoid using Discord for discussion of long-term value, as content in Discord is locked behind an account, and not accessible to search engines or web archival bots.

Yeah, I share the concern about discoverability-via-search. Some of the technical discussion about why things are the way they are is recorded in GitHub issues and pull requests, but it's true that a lot of discussion is never summarized and posted there.

We could have a Discord bot archive messages and put them someone searchable. Surely someones must have written a bot for that already, right? But so far no one has considered it a priority or taken the initiative to find out.

Here's the thing about Discord: Despite the disadvantages of relying on it as an open source project, we get so much more discussion there than we do in the forum. This forum gets, what, one post every couple months? Slightly more when GSoC is in session?

Some of the discord channels are active on a daily basis, and maybe a dozen that aren't quite daily but not too far off. It works so much better for most of the conversations people want to have. I hope you can join us!

 

[Michael]

There has been some effort to kind of restructure the engine. The current state of the engine is pretty hogpodge as things go since this project has been going on for some time and we have a significant amount of software debt from past contributions that really need to be addressed. In the past year we've kind of been going with a scorched earth type of refactor of the engine to try resolve a lot of the core problems with the current setup. Trying to shave as much debt off the project as possible. There are a lot of problems that really need to be addressed but time is a pretty large factor.

We have some core modules for the engine but some of the modules seems to replicate a lot of functionality which is not really ideal. Some older modules rely of querks of the engine that were changed ofr removed so they don't work exactly or only work for one moment before breaking with a reload. the networking is a bit heavy since we serialize over protobuf and also do the same for chunks. The dependency injection is basically just nested maps so figuring out when a dependency is available is so difficult at times that doing any kind of refactor is really difficult.

In the current state I probably wouldn't really play terasology for fun since there isn't much in the way of gameplay.

 

[asanetargoss]

I haven't given Minetest much attention; I fear C++ has too much C in it to be safe from memory integrity errors, and I have no interest in building more software on that foundation.

These fears are valid, although Minetest seems pretty robust. I'd say it's possible to write relatively safe C++ code, although it is harder. For me, the main benefits of Java are better a cross-platform ecosystem and more dynamic programming capabilities.

The more interesting question to me is whether it's something you'd recommend it to modders.

I think most Minecraft modders like to build upon an existing game that is fun to play, as that is what inspires them. A few modders are "early adopters," but many like to build on top of an existing ecosystem of mods that already exists. At a lower level, tooling to make the mod development process easier, like a pre-written code template with the minimal boilerplate and a gradle build script, lowers the barrier of entry for new developers. Minecraft Forge's API provides a set of helpful utilities and ways to make mods more compatible each other. Documentation and tutorials for the basic aspects of development also help. Finally, because modders tend to be independent, they don't like when arbitrary restrictions are put in their way.

Those are the sorts of things that I think would make modders more likely to engage with Terasology.

Yes, it's built with a sandbox so that players are at less risk from experimenting with random modules

At this moment in time, millions of desktop/laptop users, some with very little technical knowledge, are running random video games they downloaded from the internet, without knowing how they work.

I'm not saying sandboxing is always a bad thing, but you should consider the limitations of sandboxing specifically as a security measure. It directly influences the freedom of players and plugin developers, and does nothing to safeguard against other security risks, such as social engineering, and the exploitation of security flaws in the Java Virtual Machine and your sandboxing implementation.

I'm reading over a bit of the gestalt wiki, and have a few additional remarks. Making people download java code from a server is pretty dangerous. There is a reason why people don't make Java applets for websites anymore. Also, the Minecraft modding ecosystem relies on the players downloading the mods themselves (usually not individually, but generally from a trusted source). When they connect to the server, the server only verifies they have the same mods installed (excepting some client-only mods). So, that may partially explain the difference in mindset.

We could have a Discord bot archive messages and put them someone searchable. Surely someones must have written a bot for that already, right? But so far no one has considered it a priority or taken the initiative to find out.

Here's the thing about Discord: Despite the disadvantages of relying on it as an open source project, we get so much more discussion there than we do in the forum. This forum gets, what, one post every couple months? Slightly more when GSoC is in session?

It's normal for forums to have a lower number of posts. It also looks like the Terasology forums were more active in the past. Forums and instant messaging serve a different purpose and have different strengths. Forums are better for more long-term and organized content. Are forums the only tool for this? No, as github, reddit, wikis, and static websites can also serve similar purposes (and... some people use Google Docs... >.> ). But you already have a forum, so you might as well use it. And consider making it a bit more welcoming.

 

[asanetargoss]

the networking is a bit heavy since we serialize over protobuf and also do the same for chunks

protobuf is great for structured data, but yea for stuff like voxel updates I can imagine that it wouldn't make a whole lot of sense.

 

[keturn]

I think most Minecraft modders like to build upon an existing game that is fun to play, as that is what inspires them. […] many like to build on top of an existing ecosystem of mods that already exists.

Absolutely! And you see the chicken-and-the-egg thing here, right? Gameplay content inspires people to make more gameplay content. But to have gameplay content, you need people to make gameplay content.

consider the limitations of sandboxing specifically as a security measure.

I want to acknowledge what you're saying here, so you don't think I'm brushing it off, but I personally don't have much to say about the tradeoffs of the sandbox system. That's been deep in the bones of the project since long before I decided to give a try at joining the development.

I guess the one thing I can say is that I was initially very skeptical as well. The programming language I'm most fluent in is Python, with some background in C, and sandboxing just isn't an option in those languages. There have been a few attempts with restricted execution Python over the years but I don't think they've borne fruit.

People in the Java ecosystem seem to have a lot more trust in the security properties of the JVM than I ever expected. Perhaps because the JVM was created with applets in mind? I haven't studied its vulnerabilities anywhere near enough to say whether that trust is well-placed.

At a lower level, tooling to make the mod development process easier, like a pre-written code template with the minimal boilerplate and a gradle build script, lowers the barrier of entry for new developers.

That's one thing the project has put quite a bit of focus on. There is a template gradle build script. The reason none of the docs talk about how to configure it is that the tooling copies it in to module projects by default, and you never need to touch it as a module author.

In fact, you can't configure the build script. Or, rather, you could, but the build server that uploads to the module repository won't honor any such changes, so it won't do you any good to do so.

That is actually where you will first hit the restrictions of the module system, long before you run in to the walls of the runtime sandbox. Opening that up more is a goal I've been actively working towards because I am much more interested in writing modules in Kotlin than Java.

I'm hopeful we'll get there this summer. We're nearing in on a pretty big milestone on that project now.

Documentation and tutorials for the basic aspects of development also help.

There are such tutorials! Most of them are not up to date!
something which was made painfully clear when this season's batch of GSoC students showed up and tried using them.

So yeah. A place where maintenance slipped through the cracks, but it's not entirely a blind spot for the project. More work in progress. Work we'd welcome help with from someone who knows the sorts of things modders want to see, and who has an interest in improving the onboarding process!