Proposal: Create/implement a High-level "Wrapper" API around NovelRT Core/Engine

[capnkenny]

What is the current behaviour?
Currently (and for the foreseeable future) we expose an API that allows users fine-tuned control over the NovelRT Core for all things rendering, windowing, input, etc.

What is the expected change?
We would implement a higher-level API that hides some of the controls that a user would gain from using the NovelRT Core directly, in exchange for a simpler interface that still offers plenty of customisation.

What is the motivation / use case for changing the behavior?
For newer/inexperienced users of NovelRT (or C++ in general), we can provide an interface that is more traditionally seen in OOP vs. DOD. We would ultimately still provide both, but by being able to target OOP users unfamiliar with ECS, DOD, etc. we can entice a larger user base to "try out" NovelRT and as progression with NovelRT occurs, said users can then choose to either a) stick with the high-level API, or b) pivot to the lower-level Core API that introduces them to the more detailed nuances of ECS/DOD design as well as the potential for higher performance gains and more control over the Core.

Describe alternatives you've considered:

• Not providing the higher level APIs
  • We can continue to expose the APIs as-is, however we may face challenges onboarding newer users whom want to learn NovelRT but may be confused or overwhelmed by the Core at first.
• Provide a "wrapper" in Fabulist
  • We can provide this type of API inside Fabulist as the engine would be exposed, however this forces people to use Fabulist only and takes away other Closed Source or FOSS options they may want to incorporate.

Are there any potential roadblocks or challenges facing this change?

• If we expose this particular API as part of Interoperability, there will be a higher cost of maintenance to ensure that it works as expected.

Are there any downsides to implementing this change?

• There may be performance loss when using the higher level API due to additional context overhead, but this would be expected since we would be hiding the direct engine calls. This should ultimately still be minimal and would correlate more to the code from the end product itself instead of our wrapper or Core code.

Additional context

• An example:
  If a user would like to have a "GameObject" that they can add their own Components to, they can manage the object via the "GameObject" itself instead of directly making the calls to the engine for things such as:
• Adding Components
• Tying Components to a specific entity
• Identifying a group consisting of an entity AND its associated components
  For what it's worth, this could be considered relatable to a "prefab" in Unity terms.

[capnkenny]

If it helps, I was working on a demo application that may better illustrate/demonstrate this type of API - I can link it here if/when it's completed

[RubyNova]

I think I would need to see a working example of this before I have any questions on it.