Collaboration with Terasology project? #6322
Comments
|
In minetest performance is an issue, the game should work on old hardware and it's programmed in c++, whereas terasology requires recent hardware, has interesting graphics and is programmed in java. In terasology there are a lot better looking object collisions (see #6076 (comment)). Maybe they can be ported to minetest. |
SmallJoker
added
the
Request / Suggestion
|
If Terasology devs are working in Java then it's not likely they will want to work in C++ for MT, especially since devs of both are probably already overwhelmed by their own project. I expect MT devs do not want to work in Java for Terasology, their code is difficult to work with and has been used as an example of unreadable coding in our own code guidelines. Doesn't seem a realistic suggestion.
We are enhancing the engne and it is well developed, you're focussing on fancy effects. |
|
@paramat can you think of any constructive response to the original question? E.g. what are some possibilities for collaboration? What are some ways the developers could actively learn from one another. Your responses so far have been:
If Minetest developers want to build an inclusive community, it is important to be respectful and open to new ideas. |
Just thought I'd clarify a few points. Irrlicht is a 3D rendering engine, not a game engine. Minetest creates the game engine by providing sound and networking on top of it. Minetest and Terasology are incompatible, as they have different languages, architectures, rendering engines, design philosophy, and more.
Heh. It's worth realizing that this is an echo chamber, so you can get past the halo effect. There are some things that Terasology does get right, such as its modularity and its rendering. (Although admittedly that impression is only from screenshots and brief look through of its source).
What does this even mean?
This is a valid point, however contributors may like both (@Calinou has in the past).
Terasology probably goes a bit too far into Java factory land, however Minetest is arguably worse in that it doesn't go far enough. It's on my road map to separate
This is quite vague, as is this whole issue. |
|
I'm being realistic, stating my opinions and stating what i see as obvious truths, if you see these as negativity that's your problem not mine. |
@HybridDog great point. We play Minetest at home with three laptops of varying capabilities. The older ones are running Ubuntu and Lubuntu, since they have limited resources, and we wouldn't want to lose the ability to run Minetest on those laptops. It seems like there may be some leeway with the design, where more advanced features could be toggled on/off to match the hardware capabilities. |
Agreed, it should be possible to have opt-in visual improvements on newer faster machines, whilst keeping older machines happy. |
|
@rubenwardy thanks for the clarifying questions. By 'quite far along in terms of world engine development', I was simply noticing that the Terasology engine is quite well developed. I can't find a complete feature list, but it seems like Terasology and Minetest have similar ambitions in terms of terrain generation and possibly other world engine features.
The issue is intentionally vague, or open-ended. My hope was to promote constructive discussion about how the Minetest developers might collaborate with the Terasology developers.
Where can one view the Minetest roadmap? |
|
I should note that some people hate paramat for always linking those roadmaps that I haven't updated literally in years. But I guess they're fine as an introduction. |
|
To be fair, that 'some people' is 1 person who left the project and who has an obsessive hate for me anyway. |
|
Oh, and, I think this is a good issue to have around. If nothing really comes out of it, at least we have some kind of a log for what has been suggested and thought about. |
|
Those road maps don't really match the reality. It's probably worth stating our current direction somewhere. The problem is that it's currently quite chaotic in development. So as well as generalising our direction, it may be worth encouraging core devs to publish their own personal road maps / aims. |
It’s not hard to hate you 😄
Always feels like every core dev does his own thing and rushes it into release no matter if it fully works, is useful, or is not secure. |
|
one point about the incompatibility, it's wrong, terasology can, if needed wrap minetest C++ core using JNI interfaces |
|
my own personal roadmap is
|
|
What are the details on this collaboration? Are we:
|
I am not sure what this means on a technical level, but it sounds like it might enable code sharing between the projects. Perhaps the Terasology and Minetest projects could agree on a common API or plugin model. Then, for example, Terasology might be able to use Minetest Lua mods or Minetest might be able to hook in to Terasology rendering features (such as shaders). |
My intuition is that the projects could lean on one another, embrace each other's strengths and augment each other's weaknesses. For example, Terasology rendering features might be integrated into Minetest. Also, Minetest mods might be made compatible with the Terasology engine through a plugin API/facade. |
|
minetest has an API, terasology should implement the API java side if it wants to be compatible, we know projects have the same goal, but minetest community and modding is big, terasology is just nice :) |
|
As one short-term goal for this thread, we could try to reach consensus about some possible ways the projects could collaborate. Then, we (or I) could summarize those ideas in a brief document, and post an 'invitation to collaborate' on the Terasology forum or GitHub repository. The Terasology developers could, hopefully, respond with their thoughts on the proposal. |
|
you can, but personally i think MT has many things to do before collaborating with another project which is absolutely not minetest cup of tea (java...) |
|
It would be interesting if it was possible to agree on a Lua API that any voxel engine in the style of Minetest could implement (not just Terasology). However, I feel the Lua in Minetest is very ingrained with the particularities of the engine and making it more generic would probably take away more than what it would bring. It will probably complicate development of other interesting features. Not having to go the extra step of seeking intercompatibility across engines allows the API to evolve with more freedom. Perhaps it's better to let each engine do its own thing. If the Terasology project is actually interested in offering a Lua API similar to Minetest they can check out the code for inspiration, and then if they come out with a nice design of their own API maybe it would be interesting to support it in Minetest as well, in some level or form. Same for texture packs, etc. But I think Terasology needs to want to do it. Minetest has an already established ecosystem of community content, so I think the other engines should be the ones taking the first step for cooperation if they want some level of compatibility. Does Terasology actually want this? |
|
in fact a lua api is generally very close to core engine, because it needs high performance |
This statement is still pretty vague, but at least you ruled out my idea of a brand deal. (Which makes no sense. They could put MESE in Terasology, sure, but that's a pretty vague reference.)
Now this actually sounds less vague, but there are certain things that really wouldn't be plausible. Sure, being able to make new nodes, tools and items is a piece of cake, but other features like schematics or aliases might require major changes to the Terasology engine. (Although to be fair, I don't know much about Terasology's engine or modding capabilities, seeing as I can't get it to run well on a puny little Lenovo Thinkpad T420s.) Currently, I know of two open-source projects that are going for a Mario style of gameplay, those projects being Supertux and Secret Maryo Chronicles (Which could be dead... Not sure.), but you wouldn't really merge those two projects together, now would you? (Although a brand deal makes more sense here. :P ) |
|
supertux and smc don't have mods as far as l know. But being able to load/convert supertux levels and worldmaps to smc and the other way round would work l guess. |
|
@HybridDog Now converting worlds sounds like a much more reasonable idea for a collab. (As long as Minetest has a subgame with the same items, etc.) (You wouldn't really be able to convert Supertux levels into SMC levels or vice versa, though, because I've used the level editors for both. Supertux uses a tile-based system, while SMC has chunks of ground that can be freely moved without any grid constraints. Converting SMC levels into Supertux levels would potentially lose data.) |
|
Here is a simple diagram of the compatibility model:
Basically, the compatibility layer would allow game assets to be freely re-used in any supported Voxel game (engine). |
|
@brylie Okay, I guess I understand a bit more what you want. Some of this seems a bit more plausible. (Skins are the most possible, graphics in the form of texture/resource packs are possible, AI might not work because Minetest has no AI, and Minecraft hardcodes its AI. Plugins and Mods would require either game to significantly change how it handles mods if at all.) |
By AI, in the context of Minetest, I think of 'mobs' or 'traders' (NPCs that can be scripted).
The compatibility layer might bridge different plug-in APIs. Think of it as an adapter. |
Should textures and resource packs then be considered separately from rendered effects (e.g. shaders and particles)? |
They do actually in fundamental approach and philosophy, what differs are some specifics, for example VAEs are not being worked on, and CSM was intended to be server-provided mods only but is currently clientside mods (unfortunately).
Not necessariy a bad thing, it's always been quite intuitive and artistic and the result is good.
It's voluntary work, so we obviously work on what we feel like working on and what we are interested in, from these combined interests the 'direction' naturally arises.
Apart from a few inevitable mistakes, not so at all. |
|
Admittedly, part of the motivation for this issue was to encourage high-level thinking, planning, and coordination between developers and projects. Being volunteer run, and motivated by curiosity and learning are understandable. But as projects and ideas mature, architecture and coordination/collaboration become increasingly important. |
|
We decided to keep this open for a while, but now closing. MT devs are not interested in collaboration and there's no news of contact with Terasology. |
|
Terasology seems to be very fancy. I’m aware of the fact paramat hates fanciness, but there are other opinions as well. |
|
This is not just about me so no need to focus on me here, the other devs also considered this suggestion impractical and did state their opinions, as did non devs, i just wrote more comments. Obviously there are other opinions, no need to imply there aren't. |
|
I've played Terasology(yeah ik, I'm a traitor ;D) and the effects they have achieved with shaders is amazing. |
|
Hei all. I have been chatting with Terasology community/devs recently, and there seems to be some recognition that Minetest codebase is well organized and the project fills some gaps that are missing in Terasology. At least one of the project managers has expressed interest in trying to figure out how to incorporate parts of Minetest into Terasology, but nothing committal. I really think this would benefit both projects if we could combine our scarce resources and build on each others' work. |
|
Minetest lacks people which are experienced with shaders as far as I know, maybe some Terasology developer could help. |
Continuing discussion from #6309
While Minetest engine is making incremental progress with engine features, such as dynamic shadows, it may be a long and winding road to enhance the engine. There seems to be at least one other active voxel engine community, called Terasology, who are quite far along the road in terms of world engine development.
In what ways can our communities work together to share the best parts of our game engines/game mechanics, so our players have a great gameplay experience?
The text was updated successfully, but these errors were encountered: