Armory vs Godot


#1

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)?


#2

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. :smiley:

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 ).


#3

Thanks for your help :slight_smile:

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.


#4

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 :wink: ).

That would be awesome. :slight_smile:


#5

Like in terms of exporting models, like it is going to have a better support for 2.8 with the Eevee render.


#6

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.


#7

Wow Armory looks slightly sharper than Eevee.