Remember: game devs don’t create intelligent game entities; instead they create the illusion of intelligence. Game dev is a big smoke an mirrors charade.
Any system that could be queried needs to be built and maintained. Creating game entities that have models of feeling or have opinions about the groups of people they belong to has to be modeled and built. Unfortunately game dev is very informationally and financially sparse so creating these systems is a huge undertaking.
I heard a joke once about OOP: if you want to create a form that accepts payment information you must first create the universe. The joke speaks to a danger of overdoing your conceptual modeling. The real trick of a true craftsperson is to create a model that is excellent at solving the problem on hand.
What I’m saying is we’re a long way away from game entities behaving like west world hosts and embracing the ECS paradigm isn’t the answer. Just like how switching from OOP to functional doesn’t actually solve creating a profitable business.
The researchers behind the project have since moved on, but the idea of a db underpinning a game engine came up over a decade ago in Walker White's work at Cornell. Unsurprisingly, there's a whole lot of ways in which expertise from the db community can be commoditized to allow game devs to focus on the game, rather than hand optimizing code. For example, query optimizers can make it easier to scale up complex agent behaviors [0]. The project also spawned some interesting work on checkpointing, distributed replication, and computation over uncertain state.
There's a solid game design framework underlying that choice, beyond just being smoke and mirrors.
Most single player games are not "true games". They are puzzles. This is also how players perceive them.
As defined by Chris Crawford a game requires competition. Multiple agents who play, which creates the possibility of win and loss.
In most single player games, the game agents are not equal competitors who can win. They are only obstacles and challenges for the player. Even if the game is built with difficulty in mind.
So the mistake of thinking of actually intelligent game agents is like thinking why doesn't the Rubik cube ever win. It's not why someone plays it.
Notable exceptions are where software is used to substitute a player in a multiplayer game, where they do usually maintain the game structure and compete.
Maybe I focused too much on the terms. They certainly don't think of the word puzzle, but they do treat them as that.
Someone playing Zelda doesn't go into it ever expecting Ganondor to try to win. The player either solves the game, or they stop playing. But they can't lose, which is why I called it a puzzle.
In comparison to something like Chess AI where the computer agent is actually trying to win and make you lose.
So you'd find players asking whether it's single or multiplayer and competitive or casual and so on and they're really trying to place the game in that categorization. Is this game just a series of challenges for me, or are there opponent agents trying to win.
I put that in quotes because I didn't want to emphasize the terminology but maybe it didn't work. Whatever they call them, players treat games with equal opponents who can win, and games that are only a series of challenge entirely differently. The issue I'm talking about is developers trying to insert competitive agents into games which gamers expect to be a series of challenges.
Thinking back to the example in the article, there's no reason why the game designer can't just script in a player ambush, since it's a plausible thing to have happen next. I don't think you need any kind of "game intelligence" to tell a compelling story.
It depends on what kind of game you want. In many games scripted events are fine, but a game like Skyrim would feel much more alive if NPCs could do more than walk back and forth all day. In those cases scripting becomes a lot of work very quickly - the Mass Effect series had a lot of different outcomes based on player choices, in the end the final game was disappointingly linear and predictable and handling thousands of possibilities turned out to be a bit much. Immersive game worlds could use a lot of improvements.
The problem is that this is hard. Just think about how game engines consist of a graphics engine and a physics engine. You would need various other engines that can just be plugged in. A realistic economy requires a complicated supply chain for example. This means just so your NPC vendors can sell a sword, you would have natural resources that can be extracted, manufacturing processes that require inputs and machinery/tools and labor and all of this for something that the player clicks "buy" on and never looks back.
This problem has been solved many times, for example the goal-oriented action planning method allows dynamic behaviour and real games have implemented this.
But you are correct in that this means more effort for developers and doesn't sell more lootboxes.
Any system that could be queried needs to be built and maintained. Creating game entities that have models of feeling or have opinions about the groups of people they belong to has to be modeled and built. Unfortunately game dev is very informationally and financially sparse so creating these systems is a huge undertaking.
I heard a joke once about OOP: if you want to create a form that accepts payment information you must first create the universe. The joke speaks to a danger of overdoing your conceptual modeling. The real trick of a true craftsperson is to create a model that is excellent at solving the problem on hand.
What I’m saying is we’re a long way away from game entities behaving like west world hosts and embracing the ECS paradigm isn’t the answer. Just like how switching from OOP to functional doesn’t actually solve creating a profitable business.