- May 1, 2019
- 267
- 148
There are quite a few game engines out there though I don't know of many with limited scopes like RPGM or RenPy. I have looked into about 4 or 5 game engines in the past but not those 2, though I have played games made with both.Ankmairdor I am rescinding my above admission about you being right on this.
I looked it up and GODOT is not like making an RPGM or Renpy game. the engine analogy is not a very good one as a car has 1 engine. Games have myriad "engines" working together, you got graphics engine, sound engine, etc.
GODOT serves as the base but this is not like an RPGM game where you use GUI to paint a map using tiles.
There had to have been a lot of system building for the final game engine.
This is more akin to someone making a renpy-like game in unity, it requires a lot of engine building.
The releases since 0.5.23c have been mostly fixes(and bugs) and polish that I put together in my free time, based on some input from the community, along with a few stray changes by Mav. Thus, I am quite familiar with what Godot provides for this game, and I would call Godot a game engine and not Strive. Though it seems that we have different definitions of what constitutes the engine and what constitutes the game, and it seems quite likely that the distinction that you stated isn't the one you intended to make.
From my perspective, the core distinctions are code abstraction and scope, though there is certainly a good measure of arbitrary distinction in naming for the purposes of specifying roles. Godot handles all of the OS, driver, code library, and rendering interfaces, which are each quite technical and tedious stuff to mess with. It packages all of the libraries needed for these into a nice unified bundle and abstracts away most of the technical knowledge so that someone like Mav with no formal training in programming can make a game in short order.
Godot handles GUI, rendering(2D and 3D), sound layering, garbage collection, file systems, error messaging, and so much more that I haven't even messed with. The scope of the game engine is quite generalized so that it can suit a large number of possible applications without having to be altered. It's possible to create generalized files on top of the game engine that fill similar rolls to parts of the game engine, but generally those would be called an extensions of the game engine or project libraries or resources rather than a new game engine. There's nothing that says you couldn't make the application a game engine as well. However, Strive makes little attempt at supporting generalizing functionality; if you see two things that look similar, then chances are that they were implemented separately. For instance, the save/load menu when in the main menu and the one in the mansion are separate, with their own GUIs and code.
Godot is open-source so technically I could download the source alter it to specifically suit Strive and compile it, and if I did so then the boundary between engine and game would become blurry. But we just use the public releases of Godot to release Strive.
This is not to say that Strive has a free ride to creating a game since it uses a game engine. Godot only provides the stuff under the hood of the game mechanics. There is still a whole layer of design that has to be added on top of the game engine. In this way the analogy of a car engine is rather fitting, Godot provides central converter of raw potential to movement for the game. Changing out an engine for another engine with the same external connections and interactions is an simple task and doesn't require the rest of the car to change, but if there are differences then the car will need to be adjusted to fit the new engine. While Strive uses a language specific to Godot that would make a switching to a new type of engine rather tedious, switching versions of the engine is quite simple most of the time. We currently use engine swapping for MacOS users as the current version doesn't support modding, but the previous version did so we just have them run the previous version of the engine with the current game data.
If you want to call each section of code that supports another section of code an engine that's fine, but I've not seen any place where it was common practice to do so.