Under the term “good old fashion AI” many attempts were made in the past to develop a universal Artificial Intelligence. That's a computer program who mimicry the thought process and the behavior of a human. A well known example for a cognitive architecture is the BDI paradigm which is a framework to develop agent systems. On the first look, it's unclear why cognitive architecture are not able to solve real world problems. Because if a software like Agentspeak or SOAR consists of working memory, an inference engine and a sensory buffer it should be well prepared for all sorts of philosophical problems.
It has to do with a missing understanding of environments vs agents. The connection between both of them is explained in the literature as grounding, but the definition is not precise enough. The terms agent and cognitive simulation are often used with the same purpose. For solving practical problems from robotics only the simulation part is more important, and the AI can be ignored. If the domain was converted into a simulation the problem was solved. That means, a simulation doesn't need a sophisticated Artificial intelligence.
But let us take a deeper look into the BDI framework. The Belief desire intention concept is often described as a software for creating AI-agents. But in reality, a BDI agent has at foremost the obligation to represent the problem. If the agent was designed for a robocup like game, the agent will contains of procedures and variables from the soccer domain. That means, it provides a variable ball, a function “moveto” and an event like “lost the ball”. According to strict border between agents and simulations these terms are not located in the agent but they are part of the environment. That means, the variable ball doesn't belong to a certain agent who likes to play the game, but it is provided by the game engine of the domain.
The question is not how to play a given game, but how to create a formalized game for a domain. Before a software program can be implemented which kicks the ball in Robocup, there is a need to write a simulator which allows agents to play the game. If the simulator has more features and was programmed well, it will become much easier to write an AI for it.
A typical mistakes of robotics engineers is, to leave out the step of programming a simulator. They are using a robot in hardware, for example an Arduino board and the idea is, that after pressing the on button the robot is able to play the robocup game. The beginner assumes, that the robot itself needs a certain amount of intelligence and knowledge to understand the game and determine the next action. This assumption leaves out the importance of a simulator:
Robocup domain -> agent plays the game
The robot who plays the game was programmed with an agent architecture. Such project will fail. The agent aka the AI is not able to interact with the domain in a meaningful way. The more elaborated workflow is:
Robocup domain -> simulator -> agent
To understand why the second pipleline is more efficient we assume that the agent is equal to a random generator. He can't inference anything, but the robot is producing random numbers all the time. On the first look this strategy will fail to solve the robocup game. Surprisingly it is working great if the underlying simulator was programmed already. The simulator provides meaningful motion primitives like “take ball”, “kick ball”. If the agent sends random numbers to the simulators, it's possible that the agent plays the game reasonable well.
The intelligence is not located within the robot but in the simulator. The domain simulator converts a domain into machine readable API. It's called grounding and is the most important part of an Artificial Intelligence system.
Creating complex simulations
There are some techniques available for creating complex realistic simulations for a domain. In traditional software engineering there are object oriented programming languages invented. They can be utilized for creating hierarchical object oriented models. That's an UML chart which contains lots of classes distributed in hierarchical layers. Sometimes the protege tool is recommended to design such object oriented model The idea behind Protege is, that the user can creates classes which are describing a domain.
Object oriented programming and the Protege tool is used for creating simulations. A given domain, for example a soccer game, is mapped into objects. All the allowed sensor rules, actions, and events are formalized in an object hierarchy. This is called by game programmers a game engine, or rule engine because it holds the game itself.
In a short but readable tutorial it was explained how to use object oriented programming for create videogames, https://gamedevelopment.tutsplus.com/tutorials/quick-tip-intro-to-object-oriented-programming-for-game-development--gamedev-1805 Three different domains were given: Asteroids, Tetris and Pacman. All the games can be realized by creating objects which have attributes and methods. This is equal to create a game simulator, it's a computer program which executes a certain game. After the game objects are created, it's possible to interact with the game engine. For example, in the Asteroids game it's possible to send a “turning” command to the spaceship which will modify the trust variable.
It's interesting to know, that without a simulation written in a object oriented language it's not possible to play a game. Also it doesn't make sense to discuss a possible AI which can play the game autonomously.
A convenient way for accessing lots of UML models for games is the “site:genmymodel.com pacman” website. It's possible to ask the site for a certain game, and it will result a list of UML diagrams which are used as a game engine. Easy games are containing not more than 10 classes, which are connected on the same hierarchical level. More complex games are realized by a hierarchical object model which allows to store 50 and more classes. It's interesting to know, that no object model is available for the problem of simulating an AI or a robot. Because this kind of game is to general. Instead, only concrete domains like pong, pacman, soccer and RPG games are available.
From a simulation to an AI
On the first look an existing UML Diagram for a video game or the written sourcecode for the game engine doesn't answer the question how to play this game autonomously by an AI. Because the question is not how to program a game, but how to realize the Artificial Intelligence ... It's interesting to know, that both is connected together. A well written game engine can be easily scripted. A script is short computer program which sends commands to the game API. If the Game API has more features it's much easier to write a script and vice versa.
Apart from scripts there are other options for utilizing an existing game engine API, for example neural networks, a random generator, reinforcement learning and so on. All these AI techniques become more powerful if they are not used from scratch but are producing commands for a given game API. That means, the intelligence of the resulting non player character isn't located in the neural network but in the game engine which provides the allowed actions for the neural network.
Let me explain this strange situation on a concrete example. Suppose a real time strategy game was programmed already. The game engine supports the creation of new buildings and it's possible to move units on the screen. The only missing part is the AI. Instead of programming a dedicated AI, the user writes a 10 line python scripts which is using a random generator for generating a number between 0 and 100, and then a random action from the game API is executed.
The resulting AI will produce only sense making actions. He will build first some buildings, move the units and builds more buildings, very similar to what a human user would do. The reason is, that the game API transforms the random generated numbers into semantic correct behaviors. If the strength of the AI is too low, not the AI has to be improved but the game engine.