The Performance Of Armory

[zicklag]

My somewhat broad response to some thoughts brought up in Armory ignoring the Pose Mode?:

@MagicLord

Making all in missing features in Haxe instead of native C++ is adding a layer, it’s a work around.

This won’t impact small games, and will work perhaps good enough, while the performance impact will be visible in bigger games.
When the game gets more than 10 enemies with scripts for AI, animations, effects, level scripts for game flow, with a complex graphics level, you will see the difference.

I just wanted to bring up that performance of Haxe is going to depend on your target. I heard that Krom is actually benchmarked by @lubos to be faster than the C++ target for Armory. When you target Krom, everything is compiled to Javascript other than Kore ( which is the C/C++ Kha implementation ), so even the Bullet physics engine that was originally C++ is actually running in the Javascript VM.

Writing things in C++ also makes it harder to work with. Part of the reason Armory is such a joy to use, for me, is because of the very nice to read and write Haxe that it is written in. The fact that Haxe compiles in seconds is also a huge productivity boost.

@MagicLord

I really don’t like work arounds and i just skip them

I wouldn’t call writing things in Haxe a workaround. Most of the logic for the engine is in Haxe and I don’t think that there is anything wrong with that. If we get benchmarks made and it turns out that we really need the extra performance and that the Haxe code is too slow, then we should look into doing something about it.

On the subject of the performance of Logic Nodes: Logic nodes compile straight to Haxe so, for the most part, they should be just about as performant as you writing the code yourself. Obviously, the code generated by the logic nodes might be a little less optimized than if you did it manually, but not by much. If you had an extremely complicated logic tree, then the performance toll might become an obstacle, but that just means that you need to consolidate some of those nodes into a more specific node, so that you can optimize the Haxe code that makes up that node.

@MagicLord

It’s always better made when this is the engine developers that implement a features

I don’t think that it is a bad thing for us to start working on things like this. Lubos has been coding this engine for years by himself and now people are starting to get more interested in it as it grows. I think that the community can really help Armory and come up with good ideas as well. Maybe it needs to be written in C++ and maybe it doesn’t, but I think that we all want to do what is best to make Armory awesome. If it is a good solution, it will get merged in and become a part of Armory, if it isn’t Lubose should have the sense to leave it out.

I plan on trying to make a lot of contributions to Armory moving forward and I think that will be a good thing for the project. I think others are getting more interested in finding what they can contribute and I think that is great. We need to collaborate and figure out how to do things, but I think that we can do that and start to work together as a community.

@MagicLord

You are right perhaps, making in Haxe or not , should not have impact because most people won’t try to make a huge game.

I don’t think that we should take the approach to assume that we will only be making small games in Armory. Call me crazy, but I actually plan on making a sizable commercial game with Armory. I know that the engine is not ready yet, but that is why I want to contribute. I really do think that it could beat Unity and Unreal in the future if enough work and passion is put into it.

Obviously if we have to go way out of our way to make Armory work for open world, then we might need to spend our time on something else. There is always going to be a balance that we have to make, but I don’t think that we should ever just consign Armory to a small game dev’s engine. That would be to limit what it could become if we put the passion into it.

[MagicLord]

@zicklag

I don’t think that it is a bad thing for us to start working on things like this. Lubos has been coding this engine for years by himself and now people are starting to get more interested in it as it grows. I think that the community can really help Armory and come up with good ideas as well. Maybe it needs to be written in C++ and maybe it doesn’t, but I think that we all want to do what is best to make Armory awesome. If it is a good solution, it will get merged in and become a part of Armory, if it isn’t Lubose should have the sense to leave it out.

Why not, my only concern was Armory would get lot of things made by users in Haxe that would not be as optimized as C++, or would not be made the right way.

This is where Lubos comes in, as he should look at code, test and validate any users submissions features code.

@zicklag

I don’t think that we should take the approach to assume that we will only be making small games in Armory. Call me crazy, but I actually plan on making a sizable commercial game with Armory. I know that the engine is not ready yet, but that is why I want to contribute. I really do think that it could beat Unity and Unreal in the future if enough work and passion is put into it.

We don’t need Armory to be the same copy as Unreal 4, while i expect Armory minimum graphics and able to run very fast as possible on some small levels like Dishonored or Bioshock for example.
Instead trying to do best graphics or open worlds like Unreal 4 but running slowly.

I don’t think a game is the best way to contribute until you make a million seller games that gets lot of popularity. Many good games just got released and nobody knows about them.
Godot has a great tps demo, this is a great showcase demonstrating it is capable to run smoothly a big level with some gameplay.

Any 3D engine does good physically rendering and post effects, or reflections.
I don’t think Armory focusing so much on graphics is the best way.

What matters for indies will be the best tools and easy of use and not the best graphics possible.
This is why Unity is so much popular for beginners.

Some features that would make Armory more interesting :

• Terrain, grass tools, because it’s easy for a beginner
• FSM for animations , easy animations management
• Behavour Tree like Unreal 4, easy to make AI
• 3D tiles editor like Godot, easy to make levels
• Object brush placement tool, work on grid also, quick level design
• Game templates, users could use them and tweak to make a game without
  knowing a lot about nodes logic or game development.
  I think it’s important to also get those users using Armory 3D.
• More linear tutorials like the Tank game (can be made by users)
• Procedural building plugin tutorial (for advanced users, there is many Houdini great examples)