The game industry is a pretty saturated niche in the world of business. Competition is tough because way too many people are aspiring to become game developers, and it seems to us that one can hardly create and sell a profitable game without an insane degree of marketing budget these days. The digital marketplace is being flooded with countless numbers of brand new games which continuously pour out of the hands of both indie and AAA game developers on a daily basis, and it appears that even "being creative" is not an economic choice that will save one from this neverending struggle because nearly everyone is "creative" in today's world. How many countless times have we seen all sorts of quirky, out-of-box ideas showcased by random indie developers we hadn't even heard of before? I cannot even count such occasions because there are plenty and they all scream in unison, "Look! Look at me! I am special! I am different from anyone else!"
Because of such high competition, some game developers have chosen to abandon the idea of developing the actual end-product called "game" and shifted their attention to developing a game engine instead. Such people, most of them being hardcore engineers rather than either game development generalists or artists/designers, could be said to have circumvented many of their inherent difficulties by solely focusing on developing a kind of product which they are experts in developing (since a game engine does not necessarily require the talents of artists/designers due to its generic nature).
Making profit out of a game engine, however, has its own set of difficulties that are probably even worse than those which belong to the case of selling an actual game. Whereas marketing a game suffers from the problem of over-supply (because too many people are creating/selling games), marketing a game engine suffers from the problem of under-demand. First of all, only a tiny fraction of the population are game developers, and this factor alone contributes to a drastic reduction of the consumer base. Within this tiny fraction, there are hardcore engineers who prefer to build nearly everything from scratch (aside from the usage of external graphics, sound, and physics libraries) and therefore do not require a game engine. The rest might choose to utilize a game engine, yet we must be aware that the majority of them are doing so for the highest level of efficiency and thus tend to choose the most popular game engines which convey the utmost degree of community support and cross-platform compatibility (such as Unity or Unreal) instead of engines that are being developed/maintained by relatively small groups of people.
When it comes to game development, what we face is a fairly high level of demand but an even higher level of supply. And when it comes to game engine development, what we face is a fairly low level of supply but an even lower level of demand. So what we can easily recognize here is that it is a considerable challenge to make profit out of both a game and a game engine for two opposite reasons.
There is a delicate middle ground that can resolve this dilemma, however.
If we consider games as belonging to the left side of the spectrum of market niches and game engines as belonging to the right side of it, we can enable ourselves to draw two separate curves corresponding to the level supply and the level of demand, respectively.
On the left side, we have the so called "game industry" which is flooded with almost all genres of games, whether they be casual or hardcore, single-player or multi-player, RTS or MOBA, and so on. This cluster of niches, obviously, have extremely high supply due to the fact that so many people with a variety of backgrounds have a tendency to pursue their dreams as game developers. Since a game is more of an interdiscipinary form of art rather than a highly specialized piece of technology that is only comprehensible by a few (such as, say, a control module for a nuclear fusion reactor), it can be developed and published by any nearly anyone. And this is even more so nowadays due to the presence of free game development tutorial videos on YouTube, free and easy-to-use game engines which do not even require text-based coding, and assets (e.g. 3D models, textures, etc) that can be downloaded from the internet for relatively small (or even zero) prices. And even if we assume that the public's demand for videogames is pretty high, it will be rash to dare to suppose that it is high enough to overcome the insanely high level of supply. After all, games do not occupy the top of the pyramid of our spendings, do they? We do not "consume" games in the same sense that we consume food, electricity, and tap water, since games are not absolutely necessary for sustaining our lives; hence, the same exact games can be replayed over and over again indefinitely (since a piece of software does not degrade over time), which technically implies that we do not really need brand new games as long as old ones still manage to entertain us.
On the right side of the spectrum, we have the "game engine industry" which is a much narrower niche than the so-called "game industry". From a supply point of view, it looks like competition in this arena is much more relaxed because far fewer people are undertaking their own colossal journey of creating a game engine. A game engine is an extremely sophisticated system that is way more massive in scale than games (with a few exceptions such as those which belong to a large-scale simulation genre), and therefore only a relatively small portion of the population possesses the willingness to create/sell game engines. The problem with this, as I have mentioned before, is that there is only a small group of consumers who are willing to pay for a game engine unless it is sufficiently popular and is part of the industry standard. Besides, game developers are pretty darn smart compared to the rest of the population to whom the entertainment industry's childish monetization tricks can appeal with relative ease, so they know how to minimize their spendings when they are developing their own games.
Here is a solution.
We have the choice to put ourselves in the middle of the spectrum, in which one is expected to develop neither a game nor a game engine, but instead a "software toy". A software toy is similar to a game in the sense that the user can still play around with it, interacting with its components in real time without having to delve into boring technical details such as scripting, folder structure management, importing/exporting resource files, and so forth. Yet, it is not quite the same thing as a game because it does not spoon-feed the user with any specific narrative, nor does it present the user with any fixed set of rules under which he/she will be either rewarded or punished. It is not a game engine either because its apparent capabilities are not as generic as to allow the user to create virtually anything out of nothing. Minecraft, for instance, could be considered a software toy rather than a game engine (although you could technically create a mini game inside a Minecraft world) because it presents the user with a set of built-in gameplay elements which are quite limited in scope. One cannot create a game inside Minecraft whose underlying mechanics are based upon smooth surfaces or microscopic particles, for example, since Minecraft's possibility space is confined within the domain of discrete block-based interactions.
The boundary between a game and a software toy can sometimes be quite blurry, as there are sandbox games (or "god games") which focus on providing the player with the utmost degree of freedom whilst also providing him/her with a set of goals and plots to follow. Minecraft, Garry's Mod, Kerbal Space Program, Factorio, SimCity, The Sims, and many other simulation games fall into this category. On the other hand, we may as well state that the boundary between a game engine and a software toy is pretty vague as well, since some of the educational game engines such as Scratch, Kodu Game Lab, and Greenfoot are so easy to use (compared to professional engines such as Unreal, of course) that they have entertainment values in their own right.
Despite this perceived ambiguity, however, we can still somehow distinguish software toys as their own independent category due to the agreed upon notion that we are often reluctant to classify them as either games or game engines in a definite sense.
So, what's so amazing about software toys? The fact that they are a sort of "gray" beings, which belongs to neither of the two extremes of the spectrum, suggests that their market niche is a Goldilocks zone in terms of having a chance to make profit out of it. They occupy a fuzzy middle ground upon which the two curves (i.e. supply and demand) can potentially meet and even reveal a crossover. Since a software toy is not a game, passionate game developers who have stuffed their hearts of ambition with all sorts narrative and artistic elements are hesitant to develop such a thing. And since a software toy is not a game engine either, hardcore engineers who are not willing to sacrifice their coding time rendering their software product sufficiently easy to use as to be able to let laymen directly play with it are hesitant to develop such a thing.
Aside from low supply, what we can also observe is that the relative level of demand for software toys is not too low. It is not as high as to let ourselves state that their brand values support the existence of a massive fanbase (such as that of an eSports-type of game), yet we may as well expound that the availability of demand for software toys in a variety of small niches compensates for the apparent lack of boiling passion in any one of them.
A software toy, under a supposition that it is well crafted and user-friendly, can find its use cases in the fields of education, training, research, content creation, and many other areas which are not very often being associated with the game industry. A moderately entertaining yet thought-provoking software toy, since it is an interactive medium that may not be as fun as a typical videogame yet nevertheless far more engaging than a book, easily finds its usage in education where the teacher often struggles to gain his/her students' attention. A software toy with realistic physics may find its use in serious training applications in military, medicine, and other high-risk fields of expertise in which simulations must precede real practices. Academics may find a software toy a sufficiently explorable subject of study, that they would start researching its inner workings in a professional manner. Some hobbyists who are not hardcore gamers and are looking for a piece of entertainment that is somewhat more "intellectual" than mere beat-em-ups and betting rounds, may find a software toy interesting as well.
The following question is, "What kind of software toy should we create in order to make money off of it, then?"
One can think of many choices, including industrial simulators, traffic simulators, a purely exploratory sandbox game which excites the intellectual mind of a science lover, an accounting/tax simulator that is somewhat more casual and entertaining (with the help of a few gameplay elements such as progression (e.g. level-ups)) than, say, TurboTax, and so on.
The trickiest aspect of the development of any of these is that they are too broad in scope. A typical videogame would simply require the developer to focus on a specific genre of gameplay, such as racing, battle, defense, etc, so it is pretty narrow in scope. A typical game engine, despite its colossal scale in terms of the sheer variety of things which can be implemented on top of it, is quite narrow in scope from a contextual standpoint because it merely serves as a "common template" for developing a virtual world, rather than a world which exists for the sake of its own existence.
So to summarize, a software toy could be conceptualized as a virtual universe which exists on its own without requiring any external agent to bring it into existence, yet does not immure itself in a specific set of narratives. Devising such a product is a highly sophisticated task, and requires a great deal of insight.
One clue we do have is that a nicely designed software toy consists of a fairly small number of emergent elements, each of which is easy to conceptualize while also being robust enough to give birth to myriads of interesting scenarios when applied in combination with one another. Examples of such elements include:
(1) A "crafting table" through which the user can combine ingredients to produce new types of items.
(2) Dynamic physical installations (doors, switches, elevators, conveyor belts, etc) which are capable of modifying the spatial characteristics of their surrounding areas under the occurrence of specific events. For instance, opening a door creates a connection between two discrete spaces which used to be separate from each other.
(3) Different types of AI agents which behave differently under the exact same circumstance. Type-1 agents may only move, type-2 agents may only attack, type-3 agents may move AND attack simultaneously, type-4 agents may heal others but only when they have enough energy, and so on.
A virtual world in which these elements exist from the very beginning of user experience, without assuming that the user will take time manually devising them out of nowhere, is a toy that is not necessarily a game (because the presence of such emergent elements do not necessarily present the user with narratives), yet not a game engine either because it is not the user who is inventing all the individual gameplay elements. A software toy, in this respect, could be defined as a "partial game engine" - an engine that lets us create and customize parts of the game while still preserving some of its core mechanics as the backbone of the system which cannot be modified. The coexistence between customizability and immutability is the heart of a software toy, which presents us with a fountain of endless goals by keeping its level of freedom neither too low nor too high. It is because too little freedom (as in a story-driven arcade game) limits the scope of motivation, while too much freedom (as in general-purpose editing programs such as Photoshop and Blender) hardly motivates the user to undertake any adventure at all.