The terms "Engine" and "Framework" are simple to understand...
A Framework is something that requires something else in order to be usable., where-as an Engine is something capable of powering something on it's own.
With this said., these term essentially stem from Car Analogies (don't ask me why Software Engineers have a fascination with using such., but said analogies are commonplace).
You think about it like your Car... sure with a Chassis you can build something around that; but without an Engine., it'll just be a pretty paper weight; as it won't be able to do anything on it's own.
That's where the definition sits.
There are two much more pertinent questions though;
(1) Is AppGameKit a GOOD Game Engine?
(2) is AppGameKit a Comprehensive Game Engine?
And I'd say in both cases., that it isn't. Rather I'd say that it is an excellent Prototyping Engine... something to build quickly from Concept to Working Example Product; but it isn't something that is really capable or more aptly "Good" for a Finished Product.
Some elements of the Engine are comprehensive enough to be viable; while other elements are Framework (Bare Bones) Implementations that aren't.
Audio, for example is SO incredibly bare bones and needlessly difficult to work with; but for Games is an exceptionally important element for a Game Engine to get right.
Having full control over Voices, Lifetimes, Balancing, Positioning, Mixing, Post-Processing, Input-Output, etc.
And what does AppGameKit have... Load, Play, Volume.
In fact in many ways the same is true for most of the 3D Support as well... which might sound odd as there are several dozen 3D Commands., but the issue isn't the volume of commands, it's the quality and utility of what those actually do.
Ever tried to Load / Create Animated 3D Objects? Again a dozen Commands for such; but very little is actually supported to make things easier / simplified / possible.
This is wholly different from DBP., which has the same number of commands but not only would it load Animations from any 3D Format Supported (which also supported Animations) but you could quite easily manually craft them with the provided commands; and without needing to comprehensively know any 3D Formats.
Elements like this, just end up making the Engine worse as a whole; and showcase that TGC themselves simply don't have the experience with Game Development to understand what is and isn't important for such; and then as the majority of the Community are also NOT Game Developers., it's not like they in general know any better; and instead will assume said awkward / terrible implementations are "Fine" or hit a brick wall and become discouraged dropping their projects / AppGameKit as a whole.
I mean there is a SERIOUS problem at play when the AdSense "Extra" has a more comprehensive implementation than the entire Audio Subsystem.
What exactly are the Priorities there?
Another thing is a common thing for Game Engines isn't to simply bug-fix but strive towards Performance Optimisation., but again with AppGameKit it's like a deliberate avoidance from such, just to ensure Legacy Hardware support.
I've said this before and I'll say it again... What is the point in AppGameKit Studio adding Vulkan., when there is a refusal to increase the Minimum Support Specifications from OpenGL ES 1.1?
It makes Vulkan little more than a bullet point; when it could be a major performance and feature upgrade; ESPECIALLY IF Vulkan (Mobile) 1.0 was set as the Minimum Feature Support... or at least OpenGL ES 3.2; at least then it could be somewhat more modernised.
