Not true, simple class inheritance incurs no performance costs. A extends B ends up being literally the same as manually writing a class C which contains all member vars of A and B.
But my general advice for lots of X is as follows:
For hundreds of X just use your game engine’s game logic things.
For thousands of X build it into your engine itself (there’s lots of talk nowadays for doing thousands of X with an engine’s high level features - but unless you’re using a closed source engine that’s just silly IMHO).
For millions of things compute it exclusively on the GPU (that’s how today’s fancier games handle particles and here’s a relevant example of that: https://www.youtube.com/watch?v=p2YyNKPlJrE).
1 Like
Thanks for these general tips for beginners, but I would like a more in-depth discussion on how we can make things easier with the concern of high performance, and thus organize our data and code with Haxe and Logic Nodes to handle the usual cases in game development where we have many items of the same type to update as soon as possible.
As an example on the type of experience sharing / discussion, what I would like to find in this post concerns the current SIMD materials which are extremely fussy about data layout. We can only achieve optimal performance by organizing our matrices in memory, but we still need to know how it works with Haxe ? ( managed efficiently by type of SIMD hardware? how are things optimized in Haxe? what should we do to facilitate performance for the most efficient memory configuration depending on the SIMD hardware used like we could have with pragma directives in certain langages ? focus on how our machine will execute code and data with Logic Nodes / Kha / Haxe …)
As I hinted before, working with kha.simd is the same as working with simd intrinsics in C. There’s nothing special to it at all. In general the only thing to keep in mind compared to C is that you can not create a contiguous array of class instances (just like in Java and many other languages) and that Float is a 64 bit type (that’s because JavaScript used to only support 64 bit floats and Kha’s FastFloat type was added for that reason).
@Didier You may also want to investigate the entity component system (ECS) design model as a competitor to the Object Oriented model. Here is a great article on how an ECS helps in the context of games:
https://kyren.github.io/2018/09/14/rustconf-talk.html
I know you aren’t really building a game, but the data-oriented design of an ECS can be great for performance and the way it breaks down the problem solving into components and systems is really useful for handling features as a project grows. I’m not sure how well that would fit in with designing larger software in logic nodes, but I figured I’d throw it out there.
@zicklag Sure that this ECS design is inspiring and I think that I actually use a mixe of an approache like ECS + Data Driven + MVC + Observable/Observateurs in order to reuse the advantages of the systems/entities/objects/… already available in Armory and Blender and get max of them in term of performance but also in term of dynamic reconfiguration during the gameplay …
Maybe it’s mainly actually a mixe of observer pattern as it’s used for example in the MVC architectural pattern ( Model–View–Controller we use for example in the excellent Django framework) and ECS “à la sauce Armory/Blender”.
For example with the choices I have done, I like that when one object changes state, only an ended number of dependent objects are updated automatically, but also that this number could become dynamic too during the gamework.
Thus the choice I make here too is more for the reconfigurability of the actors during the gamework than the performance like we could like to find in pure games.
As explained before, I have some Factories to create entities. The entities are stored in different kind of containers. Thus here I reused the available “Blender Collection” and the available “Armory Logic Nodes” to manage it.
Then, as in ECS, each entity is only referred by it’s unique ID given by the Factory. Each entity consists of a kind of container of components, that is the empty children it has in Blender. We have too the Logic Nodes to iterate on the children, that is here the look like “components of the container of the entity”. Thus an entity only consists of an ID and a container of components like in ECS. The methods are coming from the components, but are not methods of the entity.
With regard to the communication between objects, the title of this post 
, then each Observable, with it’s Array of the Observateurs registered to it by their unique ID (in fact a unique name/ID given to the spawned child empty by the Factory) and during the gameplay, this looks like an ECS design where every component type are stored in separate lists, thus using specific collections and known/called only by it’s unique ID.
So whatever the different systems in the gameplay, that is according to system’s step or batch that operate on those type of components, it’s only iterating over objects they concern them.
What I was hopping to discuss here was about advice/tips we could get from people knowing in deep the Haxe langage and compilator to compare different approach, benchmarks, impacts of things as data layout, but it’s also very important to keep in mind the choice made during the design, that could have more impact on global performance than an only Haxe langage usage optimal with the memory cache usage for example when in intensive part of the game code.
My first attempts make me think that we could also try here in this forum to create a design pattern really powerfull, innovative and specific for making games in Armory, reusing all the possibilities Blender/Armory/Logic Nodes offer to us with under the hood the performing Haxe, and that we can’t expect to have with others environments and langages from where existing pattern are made for like with ECS maybe ?
I’m no expert on the subject of performance in Haxe in general, but I know that somebody was able to coax a lot of extra performance from Haxe with a data oriented design by using abstractions over native arrays for the different Haxe targets. He made a library with the abstractions called hotmem. He gave me a little perspective on what makes it faster in his answer to my question.
He actually built a very fast ECS in Haxe called ecx. I think he said he can’t really maintain it as it was a learning project, but it still might be a good guide for performance or ECS design in Haxe.
1 Like
Thanks @zicklag , very interesting to go deeper with ECS existing things/results, within the Haxe context.
Thanks @zicklag for the Luna link. I think too its a model for things like its explorer that could be great when using Logic Nodes/Haxe/animation in Armory …
Too this video of Bret Victor https://www.youtube.com/watch?v=8QiPFmIMxFc about “Inventing on Principle” is what we could have in the future in Armory, with a direct connection between code/Logic Nodes and 3D scene in Armory, that could realize the dream of “trying things as soon we think about them” as shown in this video.
@ziclag do you have links with the Luna Team or did you tell @lubos that it could be interesting to discuss with the Luna team of what could be a link between Armory and Luna ?
No I don’t have any connections with the Luna team and I haven’t brought it up with Lubos at all.
I’m building my own Blender integration with the Amethyst game engine, and I actually found Luna because an Amethyst team member said that they were going to work on integrating Luna with Amethyst.
@zicklag As you well know, the development of a new game engine involves many risks **, but also enthusiasm and fun .
In general it seems preferable that the development of the game engine be combined with a game… . The delay this causes is often compensated by a game engine that can actually deliver a real game, which no longer seems to be your appreciation for Armory.
Of my own experience all the best IAO tools I know of that have been commercially successful since then, were first created internally within a company as part of a specific project, and then exported/outsourced, for example, to a subsidiary that is responsible for its marketing. Take for example a tool like Catia https://www.3ds.com/fr/produits-et-services/catia/disciplines/
When @Lubos created all these examples for Armory3D, I thought he worked according to this principle, with a precise 3D game in mind and that these examples were extracts from his own game under development.
I thought too he was looking to develop an ecosystem around him to get enough ressources to reach the next level in his project.
If today it seems that your decision is taken to launch your own game engine coupled with Blender, in front of the wall of no reaction, deafining silence, that you encounter to your good ideas and contributions, as lastly what would need to be discussed carefully considering the integration of innovative technologies based on ECS as with RUST, Luna,… will you have on your side for Amethyst, a development strategy, which unlike that seems to be the Lubos one which isolates him and which seems today to be decreasing well the power of the project Armory, when seeing an active contributor like you leaving the project, this time a development strategy that provides enough resources and support to develop an engine while having a precise project of 3D game in mind and to develop ?
Secondly, what is the main focus of the futur engine too ? Are you shooting for example for a higher number of entities than in Armory? physicals behaviors ? graphical details ? IA ? Deep Learning for 3D motion? larger open-ended range of exploration? innovative way for players interactions with your game environment? efficient and easy way for developpers, graphist, animators, scenarist, … ?
What feature of your futur game engine would you say will most sets this game engine and games that it could produce apart from others existing ones ?
**
On my side, I think that given what is currently happening, there is a lot of work to be done with own artificial intelligence and animation, far or in concert with the Blender team, as well as with the collision detection by a middleware and efficient Inverse Kinematics.
For example, with the tests I did with robots+deep learning in Armory and the discussions on this forum, it’s really a combination of 3D animation, Inverse Kinematics, animation prediction with Deep Learning like in trajectory research, environment detection and dynamic objects that could really change “la done” and become a disruptive game engine …
The things/bricks to keep/adopt then for me is the approach with logic nodes and Luna for the developpers.
Then Rust seems very cool too for implementing the ECS for games.
For example, today, software development tools could delegate the task to a kind of AI to bring out “technical creativity” by finding ways to adjust a SW design for a given game needing as many assets in memory as possible without sacrificing quality, depending on the target platform and compiler available, with a Luna-like ergonomics, by proposing design choices adapted to the game under development for a given platform/compiler.
1 Like