Currently - āProcedurally generatedā and Iām sure it will change in future. Wait, thatās not a genreā¦
I think thereās no such genre because you can make your moving cube a racing, RPG, action, point-and-click, hidden objects, walking simulator, space shuttle simulator game or simply some tetrisā¦
Engines aregenre-agnostic. They provide you a scenegraph, scripting tools, and thatās all you need to implement vast majority of the games.
If youāre looking to implement a four dimensional shooter in non-euclidian space, youāll be probably out of luck, but aside from that thereās hardly a genre limited by an engine.
Thereās no such thing as a genre that is left out of an engine. There are systems that are left out of the junk that comes with an engine.
If thatās what you mean, then I would say that what gets left out tends to be whatever systems are on the upper end of the curve in terms of complexity, nicheness, non-standardisation and performance tanking.
AI is probably by far the biggest one. Cutscene editors, modular level editors, inventory management, things like that. All of these, despite being very commonly used in games, are so un-standardised that you probably couldnāt really serve even a majority of users with a tool of any reasonable scope.
But none of these belong to any genre in particular.
Games are made by developers. What games and what genres that are chosen arenāt driven by tools, they are driven by personal interest and market trends. At least ones that sell. Folks limited by thier tools have little to no impact on the market.
I partially disagree with that as engines are essentially a collection of APIās and toolsets, many titles (some very successful) would of never of seen the light of day without them. I donāt class large multi-million dollar outfits as āindiesā, so with that in mind creating a multi-platform engine and other tools like DCCās and THEN releasing a game atop of that isnāt feasable withing a reasonable timeline.
So all āindieāsā are limited by toolsets to some extent, but in reality these toolsets do exist so itās not an issue. Today the problem area is never ātype of gameā itās project scope. Certain toolsets / workflowās allowās iteration that many years ago simply wasnāt possible. Although explaining how one expands into large projects with limited resources is still a long arduous task better left for other threads that needs the content.
Not even that is a limitation⦠They arenāt shooters, but Monument Valley is non-Euclidean Unity (albeit in a pretty simple sliding-puzzle Escher way), and I think Antichamber which is very non-Euclidean was made with Unreal.
I actually disagree, partially. Game design is often driven by what can be done quickly and well. Physics-based games were possible before we had good physics libraries, but there werenāt very many of them. They were hard. But we added libraries, and then engines supported physics directly, and now physics-based games are weverywhere.
So in that regard, if thereās something that engines arenāt providing easy access to, there probably arenāt nearly as many of that type of game.
For instance, Portal / Narbacular Drop / etc. While itās possible to make it in Unity, very few people are doing so because itās so much work. If it were easy to do, I think youād see a lot more Portal-ish puzzle games.
Non-Euclidean games like Miegakure and Anti-Chamber. Very little support for this kind of thing is built-in, so they had to invent ways to make it happen.
Iām sure there are other āgenresā that arenāt considered such because there are so few games in the genre, possibly because of the lack of engine support.
I donāt understand the disagreement. If an engine puts pixels on screen, thatās all you need for anything. What you guys are disagreeing with is the quality of the result.
āPortalā is not a genre. The genre of Portal is puzzle/FPS. Ability to use portal is a gameās feature or a gimmick.
Something similar was done in Prey. In both cases engines original engine didnāt have any support for this kind of functionality, it was introduced by developers.
Engine is a collection of API. In case of things like portal (when you need a gimmick), it is developers job to figure out how to make it happen within constraints of the engine.
If those games were easy to do, we would see a bazillion of uninspired portal clones, as it happened with Minecraft. Which is probably not a good thing.
Iām talking about āa gap in the marketā. Not the limitations faced but amateurs, beginners and those just doing it for giggles. Physics based games have been around long before unity or other engines. Accessible engines have it possible for a lot more people to play at making games, but the have have opened up potential not limited it in any way for developers.
A poor artist blames thier tools. There are tons of successful games being produced by tons of developers from 1 person on up. And there is a huge and growing variety of game types and mechanics.
I get that some folks would rather put more effort into finding excuses instead solutions, but that is a personal limitation, not a market/industry one.
Are engines creating gaps in the market for genres or whatever? No. Period. That is a complete logical fail. Why are leprechauns so bad at gin rummy?
Youāre getting the idea because most game engines provide a cookie cutter set of features/modules games that tend to stand out from the crowd generally push the boundaries of what is possible or do it differently.
Minecraft - Went with a Voxel based sandbox world.
Portal - Added portals.
Kerbal Space Program / Starcitizen* - 64 bit solar system spanning play space.
Ashes of the Singularity - Massively multithreaded RTS system.
Think of any outstanding game and I bet the most memorable ones have features outside of those of a standard game engine and some probably use a ādedicatedā game engine or one with enhanced features.
What about the standout looking games, I bet a lot of them donāt use the standard shaders or lighting functions.
So what other game mechanics / features that have made great game stand out do modern game engines lack?