Followup over comments found in https://www.gamedev.net/topic/675409-what-is-an-engine/ and defnitions of the engine. -- I used to think somewhat like Norman Barrows, "if it contains a main loop", but lately I've been on a similar quest to refine the definition of terms.
In my case I'm working on my own brand of "rpg maker" much like Enterbrain's official products; and in this case it's not just an engine infrastructure but also contains editor, platform modules, and assorted shared-resources objects. It's true that I would define "engine" to be the "main game loop" and "game state management", but in my personal context it's because I supply infrastructure that "most" people who use an RPG Maker would require in place, because they "want to make a game but don't want to learn to program". -- Taken (somewhat verbatim) from real comments on RMW.
Also in my case is a matter of keeping things open-source and creating a public SPI so that "real" programmers and game developers could extend the editor, engine, and platform modules in a way that none of Enterbrain's little programs could before. Because I want to provide a platform in which the definition of maps, characters, events, essentially a lot of the things an RM-user would be familiar with, yet allow custom things to be developed for both editor and engine to enhance the core parts, ... it takes a lot of work on my part.
While the RM releases allowed somewhat extensibility with Ruby scripting, the editor part was not extensible at all, and Enterbrain license appears to disallow such. For things like RPG Maker VX Ace (to name one recent example) I see quite a lengthy list of Ruby scripts developed by third-party users to enhance the engine with custom functionality, but poorly implemented in the way such things could only be added via "noteboxes" in certain panels of the editor. And with no way for a scripter or game author to add in custom tabs and panels into the editor itself, I view as a tragedy of the modern rpg-makers.
(To be fair, the newest RPG Maker, MV, goes a little further in allowing custom scripts to be added into the scripting portion of the "game database", but I feel that it does not go far enough, and Enterbrain developers are not truly considering the weaknesses of their products in terms of how "power users" would like to extend it, if they could only have the means to do so. Whether they develop their products in C, C++, or C#, Enterbrain could have some way of implementing some kind of plugin/SPI framework for both editor and engine. Such as what I'm attempting, for my own meta-projects.)
So, Definitions, Then...
In this specific example of my meta-projects, I use most common terminology that a past or present user of an RPG Maker system might agree on; except in my case I'm breaking things up into at lear five primary meta-projects.
The Editor infrastructure is the GUI/visual used to edit aspects of the game content; even though it is a container for the second aspect, where most of the UI is obtained.
The Project infrastructure is all the modules and components that actually "handle" the editing of the game-project's data files, templates, and metadata. It is used to translate, for example, compilation of XML files and project-resources into a more "binary logic" format, readable by the remaining two parts.
The Engine infrastructure "drives" the functionality of the game, much the same way a car engine drives the motion of the entire vehicle. In this sense, it handles the main game loop, the game flow, and game-state management (pushing and pulling states to/from a collection).
The Platform infrastructure is used to provide the baseline game-object functionality, of the actual data structures used in both project and engine.
but not called a platform in the same sense as RM's "RTP" infrastructure.
This is a set of "common libraries" and not the default-shared graphics.
The Shared-Resources infrastructure is to be somewhat comparable to the RPG Maker's RTP, because it is to contain various graphics, sounds, and prototype data as may be used in a game-author starting a new project with pre-made game assets. It is primarily useful in the project infrastructure, such as if I use a "new project" wizard for pre-generating a starting project for usage.
In the ultimate usage and inter-connected nature of all these modules, as far as would work for the common person using this system, I see it as a very complex set of relationships between modules. To a developer such as myself, the Editor depends upon the Project, Platform, and Engine modules, and also the Shared-Resource files which are not technically modules but file-locations; and the Project module depends upon the Platform modules, but not the Engine. The Engine modules depend upon the Platform modules alone.
What this all means for a developer of custom modules for my RPG-Maker, should be clear -- the editor, engine, and project infrastructures contain SPI infrastructure for "plugging in" custom Java libraries for custom functionality. One example from the rpg makers is in developing something they don't have, say a crafting or even a questing system as its own self-contained implementation. A developer might develop two or three separate libraries implementing the SPI interfaces for each one: a platform library to define a crafting recipe, an engine library to define how crafting is implemented in a game, and a project library to define those parts for the platform-data and engine-operability.
In summary, the platform libraries are meant for statically-defined game content, things which, once defined, do not change during game-play; the engine libraries are for controlling those things which do change, and/or can or will be saved or loaded with the game-saved data; the project libraries are for the editor's use, in containing the game-project's data files and compilation methodologies of each data types; and the editor libraries (perhaps only one or two) are for containing meta-project information, user preferences, and miscellaneous file links.
An editor, in my opinion, should be able to compile only the necessary data that the game requires, and be able to add in whatever functionality is customized to the particular game. A game which uses custom battle processing and resolution may be able to replace the "default" battle-processing with one from a custom source, and fully be able to customize its properties in the editor's project infrastructure, with such data being saved with the project files, to be compiled and presented into the game's engine at runtime.
