Both game engines, Godot and Armory seem great. But I am not too sure which engine to pick. Can somebody please tell me the pros and cons between Godot and Armory and which engine I should use?
Also does Armory support Rust (programming language)?
Here’s my take on it:
Godot
Godot is definitely going to be more stable that Armory by far. Godot is in version 3 and Armory is in 0.5. I started with Godot 2 and spent some time with it about a year ago. It seemed pretty nice and I liked the way it worked in general, but I had a few of problems with it:
-
It seemed to have very bad performance on my few average power computers, but that may have been fixed as I have heard people talk about Godot performing better than Armory. Performance is obviously going to depend a lot on hardware and graphics cards, so this may not be a problem, but I figured it worth mentioning.
-
If GDScript was not powerful enough or did not have the bindings that you needed for your game, you had to write C++ for those portions of your game.
-
It didn’t seem like there was a foolproof way to get scenes from Blender into Godot. There was some kind of support for the Collida format for scenes, but it seemed like it would be a mess if you wanted to design a scene in Blender for your game and still manage being able to edit your game and your scene. This isn’t really Godot’s fault, though, it is just a difficult problem to solve.
Take into account that that was a while ago, and I didn’t spend a whole lot of time with Godot.
Armory
Right off the bat Armory is really nice because of its complete Blender integration. You can throw out a whole section of game engine design by borrowing Blender’s amazing UI and eliminating the need for an import/export workflow to get your assets into your game.
The other thing I really like about Armory is Haxe. It is by far my favorite programming language and is very well designed. Additionally, because Armory is written in Haxe, you get unlimited access to the internals of the engine without having to write C/C++. There are low level portions of the engine that are implemented in C/C++ to talk to the underlying graphics APIs, but that is all abstracted away, and all of the relevant engine portions are written in Haxe.
The other advantage of Armory is that it is extremely cross-platform because of the Kha framework that it is built on. Armory games can build for Desktop and Web in seconds, and if you want to develop changes to the Armory engine itself, you don’t have to wait for C++ to re-compile either. You can also publish to game consoles such as the Play Station 4, XBox One, and Nintendo Switch.
I absolutely can’t believe how amazing Armory is. It needs work, but it has grown amazingly fast for having one primary developer, and it only seems to grow faster. Granted, I am not very well informed on Godot, so take my input with a grain of salt, but that is how I feel about it. 
And just to link to my reply about Rust in Armory:
Take into account that that will only work when targeting Krom which mainly runs on Desktops ( and maybe Android soon ).
2 Likes
Thanks for your help 
So with Armory, is it based off Blender 2.8 or something before that?
With Godot, do you know how to set up GDNative C++ or GDNative Rust by any chance as I am struggling and i want to really use Rust cause its faster than C# and GDScript (C# is something new they added) and its not too difficult to use.
I may consider Armory but I heard that Godot is going to have tight integration with BLender 2.8.
1 Like
Armory is currently running on Blender 2.8. It was running on 2.7x and 2.8 up until last month, where we switched totally to Blender 2.8 because the beta came out.
I’ve never actually done it. They were actually just coming out with GDNative feature when I was last using Godot ( C# is news to me as well, sounds like they’ve done some work since I’ve been gone 
).
That would be awesome.
1 Like
Like in terms of exporting models, like it is going to have a better support for 2.8 with the Eevee render.
That’s cool. Armory was recently calibrated so that the Armory render looks nearly identical to the Eevee render in a test scene I was making:
Eevee:
Armory:
The differences I think are mostly due to Armory’s compositor settings which are completely customizable.
Wow Armory looks slightly sharper than Eevee.
Sharper is not necessary a pro.
Sharp shadows for example are easy to create, smooth shadows are more complicated…
1 Like
That can all be tweaked in Armory. You can choose to do soft shadows if you want; there are lots of rendering options.
1 Like
The “ace in the hole” of Armory … is Haxe. This is a “transpiler” (source-code to source-code compiler) technology that generates source-code for the target platform(s), from a single Haxe source-code base, then compiles it using that platform’s native tools. It actually can target “all those machines,” and HTML5, and Flash (producing far better Flash than Adobe ever could), and more.
(I have used it now for many years. Yes, it actually works. I haven’t written JavaScript “by hand” in a very long time now. And, once you try it, neither will you.)
Significantly, Haxe is an industry-proven ecosystem of tools and technologies that goes far beyond just Armory. Haxe is a fully featured, industrial-strength, software development environment. To Haxe, Armory (and Iron, and Kha) is a package.
I frankly think that Armory will transform the development industry, and do so extremely quickly. It is integrated into(!) a very widely-known graphics authoring environment, completely eliminating the “export/import” step and the “impedance mismatch” between that authoring environment and run-time. It, and every tool that it is built upon, is entirely open-source. It’s the tool that we’ve all been waiting for, and somebody finally built it.
IMHO, Unity (and many others who perceive no credible competition now) had better be watching its back, because they could soon be watching Armory’s … ahhh … “bumper stickers” before too long at all. Yes, there is yet much more work to do, but the future direction is quite clear and the advantages are compelling.
3 Likes
Although I like Haxe, nowadays the regular over-hyping regularly makes me feel uncomfortable about it.
3 Likes
I think it is very powerful and I very much like it. I don’t think that it completely clobbers everything instantly, but I do agree that I think that Armory can make a big impact on the game development environment and that it has incredible potential when put together in the way that it has been.
All of the technology out there is really great, and it can be difficult with how much cool stuff that is out there to figure out what is the coolest, but I do think that Armory and the tools surrounding it make up on the the best combinations I have seen yet. One of my favorite points about it is how I have options and I don’t feel locked into a specific runtime or deployment strategy. I feel like I can grow the engine and its surrounding tools as I may require during the course of development and experimentation. Its flexibility is one of my favorite points about it.
I saw @lubos adding an entry to the roadmap about researching ECS for Armory 0.7.
For those with more experience with Haxe, Kha & Armory, do you think that ECS and the Data Oriented Programming paradigm could be really implemented in Armory and get the performance gains that you can see on the Unity ECS prototypes?
It isn’t “hype.” Haxe has been around for a number of years, and it is well-proven technology that actually works. I first encountered it when I was forced to fix someone else’s dying Flash project and flatly refused to buy Adobe crap. But then I found what else it could do. 
There are even-more very powerful mobile development tools in the Haxe universe, including OpenFL. All of them need some of your time and attention.
Haxe … it’s real. Really.
It would be actually helpful if you could point out the other side of the story, just to be aware of the lower points of Haxe if you know of any particularly painful or that might pose a problem in the near future.
Can you use Haxe to write normal softwares, or program an Operating System or something like that?
Does haxe have memory safety features, like Rust?
I would love to see corporate products competing against FOSS.
“Hey, first of all, I am not ‘a Haxe fan-boy!’”
I think that it is very illustrative to point out the fact that Armory is built upon three distinct levels of open-source software … each of which builds upon itself:
- Iron – an abstraction useful to Armory
- Kha – an abstraction of graphics hardware
- Haxe – a practical implementation of cross-platform programming.
Each of these respective layers of software, “from the bottom up,” are not constructed with consideration of one another, nor were they built by the same individuals. Yet, every project depends on each of them.
I think that, "when you seek common ground," individual platform-specific differences will always potentially be a case that you will be obliged to address … and that you might find that you must step outside of the Armory3D framework and into the world of Haxe in order to accomplish it. (But, always being ever-mindful of whatever else is happening in the greater Haxe world.)
That’s not what Kha is. Also, Haxe is just one of the two cross-compilers it includes. To Kha, Haxe is just a package 
1 Like
“Eh?” Okay, I’m just going to presume that you meant some attempt at humor. Good evening to you, sir (or madam).