I started creating this engine for Visuland in 2007, which was mainly an internet based application built around VOIP communication.
When the project was "cancelled", I kept using it for reserach and prototype purposes, and slowly the entire framework had radically changed, and now it has very small similarities with the original version.
The VLEngine is not a competition to the commercial game engines, but for my purposes I could not imagine a better tool. It is written in C/C++ (I usually use the term C+ or C with classes, as I'm not using too much from the modern C++, and not pushing OOP design too far either).
The engine is more than 500.000 lines of code and was entirely written by me. I use just the minimal amount of 3rd party libraries, only the very necessary ones that I couldn't write otherwise. JPeg/PNG/ZIP encoding/decoding and some audio codecs, nothing more.
As it has no dependencies and not full with code garbage, a full rebuild takes less than a minute on an average laptop, without any fancy build tools, and the final result is just a couple of megabytes in binary.

The original engine was made a long time ago targeting the then low end hardware. Originally it used DierctX8.1 with fixed function pipeline. According to the statistics 10-15% of our users had no shader nor hardware vertex processing support. The rendering used lightmapping and only the player characters used dynamic projected shadows.
As the original technology targeted internet based use, the entire engine was built around the "minimal data" principle. So, I compress everything, nothing is stored in raw format.
When we created Visuland we didn't want to make yet an other open world platform, it would have been an overkill for two person. It was organized around single game levels, which proven to be a good approach. Later I added open world functionalities, but it didn't change the original concept too much.

One of the best feature of the engine which was not intentional, but worked out pretty well is the capability of separating different projects in the code with minimal connection to the core. The GUI framework is a mini windows with applications, forms...etc
So, every game, prototype, test program I create is a new application in the game, that I register in the system, and from then on I can execute it from anywhere, at any time, even in multiple instances.
Anything can be an application, being a 3D game, 2D game, or even a standalone game feature, they are running simultaneously, and can work from separate data streams. This is a heritage from Visuland where the users could do different activities or play different games on the same location at the same time.
Adding/removing a "project" is just copying the files in the VS project and adding an include in a designated place, removing it is the same.

Early on, the engine was arranged into a separate DLL file because of the internet browser integration, and this made a good use to create a stand alone scene editor, which also proven to be a good choice.
The editor is a separate executable, but is running the engine in embedded mode. The very same functionalities are available as in the game, instantly. No waiting time to start anything. This is very useful for rapid iterations or just testing game mechanics while building the level. The same application framework is running, so starting a game or prototype in the editor is not a problem. Place your character on the scene with a hotkey, and you can start walking around while all editing functions are still active.
This architectural decision nicely separates the asset creation from the game itself. The engine only works with final resources that the editor feeds in. All importing converting and editing tools reside in the editor. There is only one instance of the game world, everything is saved in the final format, there is no need to spend time on building the editor world into game ready assets.