Enemy AI, damage systems, crafting systems, etc. are still—at least potentially—game engine components. They’re thought of as “application layer” components of individual games because games don’t tend to share any code for these, rather coming up with their own implementations (usually just some finite-state machines.)
But if you had an in-engine system for doing realistic chemistry (maybe in bulk, on a voxel or particle level, on the GPU) then that’d be less of a gameplay idea, and more a module to drop into a game’s physics, no? Sort of like soft-body dynamics is a module to drop into a physics engine. It’d just be part of the game’s physics that’d constrain the way that a crafting system must be implemented if you’re using it; sort of like how using kinematics engines constrains the way you implement vehicles.
If the entire game is full of tracked atmospheric gases; and the heat of these gasses can convect into nearby solids/liquids; and the gasses can also condense if they get too cold, and things can crash out of liquid solutions if the liquids get colder, etc.; then inherently you’re going to be able to build things like a distillation apparatus under such physics; and inherently you’re probably not going to be able to build a Minecraft-like arbitrary-crafting system without going “out-of-engine” in a difficult way (because now you have to worry about how popping things into existence affects air pressure—you’ll be fighting the “chemistry engine” every step of the way to building it!)
And, also, you’ll get side-considerations, like it being hard not to have a weather system in games using such an engine, because each zone of bounded size inherently becomes a terrarium where the “ceiling” can form condensation. (And there would have to be such a ceiling—in fact, a whole physically-simulated “world box”—otherwise the gas escapes! Unless you want an Earth-sized spinning zone to keep your atmosphere sucked down...) Again, you’d have to fight the engine to use it but not have realistic weather. It’d be a lot easier to “trick” the engine by just putting materials into the game that would have the same real properties that would create an illusion of there being no weather in a real terrarium (i.e. a really big air conditioner, sitting “outside” the terrarium-edge-box, like the ceiling in The Truman Show.)
Or, in the sense of a damage system, I’m not really talking about the gameplay concept of a damage system, but rather choosing to implement player-controllable avatars (and mobs, and everything else “living” in the game) in terms of a scripted or player-controlled “mind” commanding a faithfully biologically-emulated “body” to move (think “body as kinematically-simulated robot, that has a movement AI, and accepts goal-pathing instructions; player control/NPC AI as source of such pathing instructions.”) And, since the body would be physical, entities would only be able to do what their bodies are able to do—such that if an entity’s body gets damage to a crucial muscle or organ, its body is now less able to follow commands to run, however much the control-layer sending those commands wants it to run. Sure, from a top-down sense, that’s a “choice of damage system”; but from a bottom-up sense, that’s a physiology modelling engine that could be put into any game engine and used for any number of things (from a game about trying to stab your opponent in their vital organs, to a game about poisoning, to a Wii Fit-like game that tries to model which of your muscle-groups will tire first, to...)
Consider why we have a “physics engine” in the first place. 2D games back in the 80s and 90s mostly just implemented one-off physics at the application layer; but then, soon after entering 3D, we wanted real physics, and there’s only one “real physics” to model, so we started reusing and generalizing our logic for “real” physics out into physics engines, and started building the “game physics logic” for games that wanted mostly-realistic physics, as just a policy layer on top of such a generic real-physics engine.
That’s what I’m talking about here: there are other such “engines” we could have, which would be scientifically-sound models of reality that players could predict the behaviour of based on their knowledge of the real world, where in-game systems could then be implemented the way most 3D games’ physics systems are: as configurations of, and scripting hooks into, a few polished, flexible, generic models.
The simulations you're talking about are beyond what can be done on our biggest supercomputers today. Games with realistic chemistry would be a great application of personal quantum computers. See you in fifty years. ;)
But if you had an in-engine system for doing realistic chemistry (maybe in bulk, on a voxel or particle level, on the GPU) then that’d be less of a gameplay idea, and more a module to drop into a game’s physics, no? Sort of like soft-body dynamics is a module to drop into a physics engine. It’d just be part of the game’s physics that’d constrain the way that a crafting system must be implemented if you’re using it; sort of like how using kinematics engines constrains the way you implement vehicles.
If the entire game is full of tracked atmospheric gases; and the heat of these gasses can convect into nearby solids/liquids; and the gasses can also condense if they get too cold, and things can crash out of liquid solutions if the liquids get colder, etc.; then inherently you’re going to be able to build things like a distillation apparatus under such physics; and inherently you’re probably not going to be able to build a Minecraft-like arbitrary-crafting system without going “out-of-engine” in a difficult way (because now you have to worry about how popping things into existence affects air pressure—you’ll be fighting the “chemistry engine” every step of the way to building it!)
And, also, you’ll get side-considerations, like it being hard not to have a weather system in games using such an engine, because each zone of bounded size inherently becomes a terrarium where the “ceiling” can form condensation. (And there would have to be such a ceiling—in fact, a whole physically-simulated “world box”—otherwise the gas escapes! Unless you want an Earth-sized spinning zone to keep your atmosphere sucked down...) Again, you’d have to fight the engine to use it but not have realistic weather. It’d be a lot easier to “trick” the engine by just putting materials into the game that would have the same real properties that would create an illusion of there being no weather in a real terrarium (i.e. a really big air conditioner, sitting “outside” the terrarium-edge-box, like the ceiling in The Truman Show.)
Or, in the sense of a damage system, I’m not really talking about the gameplay concept of a damage system, but rather choosing to implement player-controllable avatars (and mobs, and everything else “living” in the game) in terms of a scripted or player-controlled “mind” commanding a faithfully biologically-emulated “body” to move (think “body as kinematically-simulated robot, that has a movement AI, and accepts goal-pathing instructions; player control/NPC AI as source of such pathing instructions.”) And, since the body would be physical, entities would only be able to do what their bodies are able to do—such that if an entity’s body gets damage to a crucial muscle or organ, its body is now less able to follow commands to run, however much the control-layer sending those commands wants it to run. Sure, from a top-down sense, that’s a “choice of damage system”; but from a bottom-up sense, that’s a physiology modelling engine that could be put into any game engine and used for any number of things (from a game about trying to stab your opponent in their vital organs, to a game about poisoning, to a Wii Fit-like game that tries to model which of your muscle-groups will tire first, to...)
Consider why we have a “physics engine” in the first place. 2D games back in the 80s and 90s mostly just implemented one-off physics at the application layer; but then, soon after entering 3D, we wanted real physics, and there’s only one “real physics” to model, so we started reusing and generalizing our logic for “real” physics out into physics engines, and started building the “game physics logic” for games that wanted mostly-realistic physics, as just a policy layer on top of such a generic real-physics engine.
That’s what I’m talking about here: there are other such “engines” we could have, which would be scientifically-sound models of reality that players could predict the behaviour of based on their knowledge of the real world, where in-game systems could then be implemented the way most 3D games’ physics systems are: as configurations of, and scripting hooks into, a few polished, flexible, generic models.