Hazel VS froggy

I used a workflow template for MSBuild-based projects. When doing this lab exercise I referred to this video by TheCherno, who used the same template for his Hazel Game Engine developed using Visual Studio. The Microsoft Build Engine, MSBuild, is what Visual Studio uses to load and build managed projects. Since I'm also developing my project using Visual Studio, this template seemed like the best option.

Don't write a full blown abstraction, you won't use it. Also Hazel is a great game engine which relies on Vulkan that you could use as well.

And sometimes I feel like 50% of those are copy-pasted from Hazel, which is also far from being commercially viable, despite its popularity.

They're coming from the precompiled header in that project: https://github.com/TheCherno/Hazel/blob/dcdbfe13ac1d06a1650f66719cb4f79ecf310c85/Hazel/src/hzpch.h

https://github.com/TheCherno/Hazel there's a youtube series following the development of this engine, and other useful series on the same channel

Also, I just created premake configurations for the Vulkan SDK. Actually, this is only for the shader compiler and spirv-cross, so there might be more stuff from the SDK to be added.

IIRC, all those engines provide an ECS that could be compared to entt.

Also, there is Hazel[0] which is based on entt and is the subject of an amazing youtube series[1].

IMHO, tinier means less features, at that point what could be considered comparable?

  [0] - https://github.com/TheCherno/Hazel

What I found in practice is that many people start using the ECS for speed, and then draw themselves into a corner of the design space. Now they have to weight every step on "how would it work in ECS?", and dedicate effort to fight the ECS paradigm.

For example, a mesh may contain multiple materials. Is each material chunk a separate entity? Or maybe each bone in a skeleton is a separate entity with its own "parent" and "transform" plus other component.

One of the different approaches is component graph systems [1]. It lacks the ability to mix and match components, but provides a more natural (and simpler) model to program for.

[1] https://github.com/kvark/froggy/wiki/Component-Graph-System

I had similar motivation back in the day for CGS in https://github.com/kvark/froggy, which was also powering https://github.com/three-rs/three. It's nice to see Rust ecosystem not locking itself on ECS, even if they are so cool :)