Rust and the Vision of Armory

Really, what you are describing has nothing to do with "the vision of Armory." What you’re talking about – all that you are really talking about – is creating a brand-new system in Rust. Starting all over and doing it all over again.

What you could easily be overlooking, though, is that you’ll have to re-implement Kha and Iron as well.

And now, people would soon be badgering you about your “vision” (or lack thereof), and maybe talking about forking a brand-new “starting over,” this time, say, in PHP … :wink:

As I said here before, no need to do Kha in Rust. Kinc was released two days ago, Rust support is the next feature on my list.

3 Likes

@MikeRobinson I’m going with a different engine because Armory is not going to go where I need it to go for my game. If I make my own game engine it is because I cannot find what I am looking for somewhere else. What I make will be tailored to my needs while Armory has its own needs that do not match mine. The decision is driven by the requirements of the games I plan on making, not just because I want to fork Armory.

If Armory was going to be able to provide what I needed for my game, I would be more than happy to use it and to develop it even further, but it does not appear that that is the case so an alternative is required. If I could make Armory work, I would, but I can’t without changing the fundamental technology on which it is built.

1 Like

Zicklag, “if you conclude that you must invent your own path forward,” you certainly will not be the first. Godspeed…

@zicklag I understand your feelings about lubos lack of attention to the community members, I also tried to get in contact with him a couple of times, with no response. I’m sure this is really frustrating for you as an active member and contributor. I wish you luck with your project and hopefully lubos find some time to address peoples concerns about this engine. :slight_smile:

2 Likes

If anybody is interested on the direction I ended up taking, I am building a Blender integration on top of Amethyst.

6 Likes

This looks pretty interesting I have a few questions in regards to this. During game development, if I were to use your tool, would I be able to just use Rust without any complicated setup or any BS?

Also do you have other people working with you at the moment? I wish I could offer to help you but at this time I lack such skills for software development so I was thinking that maybe when my exams are over and I can learn more Rust then maybe perhaps I can help you with your project.

Within Godot, there is a development team that is already working on GDNative Rust (which allows the game developer to script the objects using Rust) which is functional for now but it is very like messy code and stuff. What if you did Blender tool integration with Godot instead? How does that sound? Since Godot seems a lot more mature compared to Amethyst and Armory game engine?

As far as I plan, yes. Me and my team are seeking to make it as easy to use and get setup with as absolutely possible. When it comes to writing a game, you should be able to write game logic with Rust or Lua to start, but it could be extended to any language, according to the Amethyst scripting RFC. There is also a plan to use Luna for visual scripting in Amethyst. I’ll have to look into it, but we might be able to use that and integrate the visual editor into Blender like Armory’s logic nodes.

I have a team that I work with, but I’m the only one that has the time to write code at the moment. The project is Open Source, and will be dual license under Apache 2.0 and MIT so it would be perfectly possible for you to help out if you wanted to! It would be great to have some help. A lot of our work will probably center around getting certain features into Amethyst so we’ll be able to collaborate with them and have their help with a lot of the stuff that we need to work on such as scripting support.

We’ve tried out Godot before, but there are some reasons we don’t want to use Godot:

  • Performance: This very well may be a non-issue, now, but a while back, while Godot 3 was still under development, we got very low frame rates on very simple games and that worried us quite a bit. If it weren’t for the other reasons not to use Godot, it would be worth looking into the latest version of Godot to see if it was fixed.
  • Modding: I tried to integrate a modding system into Godot, but they didn’t want to do it because of security concerns. Security is a concern, but I believe that the advantages that modding provides is worth it. ( It looks like there might be a way to do this now but I haven’t looked into it yet. )
  • Written in C++: Godot is written in C++ and while we wouldn’t necessarily have to write C++ to write game logic becuase of the GDNative Rust setup, we will very likely end up wanting to contribute to the engine core, and if it is written in C++ that will be a much less approachable experience. Amethyst is written in pure Rust ( with some C++ dependencies, but not a lot ) which grants it all of the safety and ease of development that Rust provides.
  • Amethyst’s ECS: Amethyst is written on an Entity Component System ( ECS ) which is a huge advantage, in our eyes. The ECS design model is amazing for games and allows Amethyst to parallelize much of the game and engine logic with no extra effort. ( A good article on how an ECS helps can be found here )

Amethyst is the most in line with my team’s goals, including the ability to meet or beat the performance of Unreal and Unity so at this point we are confident in that as the direction that we want to go in.

2 Likes

Just out of curiosuty why dual license it? Why not license it under MIT, what is the difference since I don’t know much about dual licensing between Apache 2.0 and MIT?

I am more then eager to help but yeah just wait for my exams to finish and for me to actually learn more about Rust I only have a basic experience.

Oh wow that’s a bit of a shame. Maybe it was buggy or something. You could try Godot now and see if it is still an issue if you wanted to.

You said the word they, do you mean that the Godot developers refused to add modding? Couldn’t you have just forked it and made your own version out of it? It is MIT licensed after all?

Yeah it is a huge shame that it is written in C++ I wish it was written in Rust. Oh well. Couldn’t Amethyst be integrated with Godot by any chance?

When you say parallelize what do you mean by that exactly?

From a technical prespective you said it may beat the performance of these two game engines, could you explain to me how is this possible?

You’re project looks pretty interesting and I would love to use such a tool if it even exists. Do you have any estimation as to how long would it take to make Arsenal game engine?

You should try and promote your project to the Amethyst discord channel and to Rust forums and discord channel as well. This could potentially gain more developers to help out with Arsenal game engine.

After some additional investigation, we decided to just license it under MIT, but contributors must sign a CLA. See our FAQ.

Yes. See this comment. They thought that we couldn’t make modding secure enough. There was some more discussion after that and the last comment says something about it being possible now somehow, but I haven’t looked into it.

Forking an entire engine isn’t really an option for us because it would mean that we have to maintain that fork. We have to make sure to keep it up-to-date and always make sure that we keep our changes working with their changes, all while writing more C++, which we are trying to avoid.

I don’t think that there is really any way that makes sense to do that. They are both different engines trying to accomplish things in a totally different manner with completely different language and technology. Amethyst is very much in line with the goals that we are wanting to pursue for our engine; even if it needs some more work, we are pretty much set on it right now.

By “parallelize” I mean executing code on multiple CPU cores at the same time, aka., multi-threading. Amethyst is designed to take full advantage of all of the CPU cores that you have on the computer, where other engines may only use one core and be missing out on the processing potential the the computer could be using to run the game. The ECS design of Amethyst makes it extraordinarily easy to multi-thread game logic, something that can present quite a challenge under different circumstances.

From the Amethyst Docs:

Most of us have worked with quite a few game engines over the years, namely Unity, Unreal Engine, JMonkeyEngine and many more. While they all are pretty solid solutions if you want to build a quality game, each have their own pros and cons that you have to weigh before using them, especially in regards to performance and scalability.

We think that basing the Amethyst engine on good and modern principles will allow us to make an open source game engine that can actually be more performant than those engines. Those principles are: Modularity, Parallelism, Data-oriented/Data-driven.

Not really. We have no idea how long it will take, especially because we haven’t done any work yet to give us a reference for how long different kinds of development will take.

Thankfully we don’t have to build the entire engine ourselves, because we are building on the Amethyst project, so we will essentially get a bunch of free help from them.

Awesome. :slight_smile: :+1:

You also might want to check out our new vision and FAQ pages to get more of an idea of what we are working towards.

3 Likes

Oh thats nice :slight_smile:

That’s a bit of a shame. Oh well.

I understand.

I understand.

Oh wow this is interesting, so even Godot and Unity wouldn’t have something similar to ECS and would make it difficult to parallelize the game.

I understand and looks interesting.

Luckily this is the case :slight_smile:

Thanks for the links looks pretty interesting and I would love to see this grow :slight_smile:

One last question, you know how Godot has NativeScript that points to the dll file on Windows after it is generated from a compiled language such as Rust or C++? And you know how using NativeScript causes a small performance drawback, would the same apply to Arsenal, would we end up using something similar to NativeScript?

I think I heard at one point that Unreal may have been integrating an ECS, but I can’t remember for sure. You can still parallelize your game without it. For example, in Godot you can create threads for doing multiple things at the same time, but an ECS breaks down the problems that you are solving into smaller pieces which makes it easier to reason about and Amethyst’s ECS has a structure that can automatically run systems that don’t depend on each-other in separate threads.

I don’t know how Godot’s NativeScript setup works, but the scripting plan for Amethyst is outlined in this RFC. It looks like there would be no performance hit if you are using something like C or Rust for scripting. If you use Lua for scripting it would be slower than Rust because it is garbage collected and not compiled ahead of time, but it should still be very fast.

Also, even in when using Lua for scripting, we should still be able to get multi-threading for the Lua code, again, because of the ECS design and the clever scripting plan.

1 Like