EP1915675A2 - Generische ki-architektur für ein multiagenten-system - Google Patents

Generische ki-architektur für ein multiagenten-system

Info

Publication number
EP1915675A2
EP1915675A2 EP06776496A EP06776496A EP1915675A2 EP 1915675 A2 EP1915675 A2 EP 1915675A2 EP 06776496 A EP06776496 A EP 06776496A EP 06776496 A EP06776496 A EP 06776496A EP 1915675 A2 EP1915675 A2 EP 1915675A2
Authority
EP
European Patent Office
Prior art keywords
level
agent
implementing
percept
game
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP06776496A
Other languages
English (en)
French (fr)
Inventor
Tobias Schild
Andreas Gerber
Gero Vierke
Christian Gerber
Markus Wilhelm
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
X-Aitment GmbH
Original Assignee
X-Aitment GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by X-Aitment GmbH filed Critical X-Aitment GmbH
Publication of EP1915675A2 publication Critical patent/EP1915675A2/de
Withdrawn legal-status Critical Current

Links

Classifications

    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/60—Generating or modifying game content before or while executing the game program, e.g. authoring tools specially adapted for game development or game-integrated level editor
    • A63F13/67—Generating or modifying game content before or while executing the game program, e.g. authoring tools specially adapted for game development or game-integrated level editor adaptively or by learning from player actions, e.g. skill level adjustment or by storing successful combat sequences for re-use
    • A63F13/10—
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/45—Controlling the progress of the video game
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N5/00—Computing arrangements using knowledge-based models
    • G06N5/04—Inference or reasoning models
    • G06N5/043—Distributed expert systems; Blackboards
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/60—Methods for processing data by generating or executing the game program
    • A63F2300/6027—Methods for processing data by generating or executing the game program using adaptive systems learning from user actions, e.g. for skill level adjustment

Definitions

  • AI artificial intelligence
  • Jörg Müller describes a number of different design and architecture approaches in "The Design of Intelligent Agents” [JPM99].
  • the agent architecture InteRRaP is presented, in which the capabilities of an agent in the three areas of "reactive behavior”, “rational planning” and “cooperation” are modeled by layers. InteRRaP each layer has its own knowledge base.
  • the agent has an interface that allows him to interact with his virtual or real environment. Only the lowest layer has access to the interface. The other layers must use the behavioral layer control to affect the environment. task
  • the object of the invention is to facilitate the use of artificial intelligence in simulations and computer games.
  • AI AI
  • the development of a generic AI (AI) architecture was motivated by the plight of current computer games in terms of their artificial intelligence for the computer-controlled players (agents). While the graphics and physics of games have steadily increased in professionalism over the years, the implementation of AI has been accepted as a necessary evil.
  • the generic AI architecture presented here a platform is to be provided which makes it very easy for the game developer to integrate an AI without having to deal with the subject of AI in detail. It is to create an AI engine, which acts for a game developer as another human player. That's why we set our the goal, the AI architecture (engine) generic as possible.
  • the architecture should provide an environment for the agents within which they can interact.
  • the generic architecture creates a metal level for the game environment, so an agent can be used in different games without having to consider the exact implementation in the game.
  • a computing unit for implementing multi-agent systems is proposed with means for implementing a first level, which represents a system.
  • This level defines z.
  • the first level is usually a simulation world, but it can also be the real world if the agents control robots.
  • the first level is a system that changes over time. It can be changed by actions. Furthermore, its state or changes in its state can be perceived.
  • the arithmetic unit includes means for implementing a second level comprising a world server having an abstract, concept-reduced representation of the first level system. The world server reduces z.
  • B objects of the system of the first level to a few parameters. There is an interface between the first level (game engine) and the second level (world server).
  • the arithmetic unit contains means for implementing a third level, which comprises means for implementing the agents of the multi-agent system (agent engine).
  • a third level comprises means for implementing the agents of the multi-agent system (agent engine).
  • the second level the world server
  • the second level separates the first level (the game or the game engine) from the agents.
  • This setup allows a heuristic treatment of virtual physical effects, through the world server, which can simulate a much more complex world with higher computational efficiency.
  • the architecture thus allows a significantly increased processing speed of simulation problems.
  • arithmetic unit z As arithmetic unit z.
  • a stand-alone computer and a network of computers for example an in-house, closed network, or even computers that are connected to one another via the Internet are considered computer systems.
  • the computer system can be realized by a client-server constellation, wherein parts of the invention run on the server, others on a client.
  • the interface for communication between the first level (game engine) and the second level (world server) has a structure corresponding to the structure of an interface between the first level and a human operator or player.
  • the AI middleware ie the world server and the agents
  • acts or the agents according to the invention act like other human players. It does not require any elaborate adaptation of the game and no separate programming of the AI.
  • the communication between the second and the third level takes place via the interface via actions and perceptions.
  • An additional exchange There is no need for it.
  • the second level (the world server) encapsulates the data of the first level system (the game engine) using actions and concepts.
  • An action is an interaction that is introduced into the system of the first level and can change it.
  • Percepts Through a percept the world is perceived. Through a percept, an agent can interrogate or perceive states of the world. Simulate concepts a. the senses of a human being. Percepts have the advantage that they are self-contained data packets that are not tied to interface definitions.
  • an agent For an agent to receive or perceive a percept, it must have a suitable sensor. This simulates z. B. a sense organ, ie z. For example, the ability to see or hear.
  • each agent is typically assigned at least one predetermined virtual sensor, and the perceptions are matched to match the respective sensors of the agent. In other words, the information available to the agents is filtered according to what the respective agents can perceive. As a result, very realistic and flexible multi-agent systems can be implemented.
  • the object is further achieved by an arithmetic unit, which consists only of the second and third levels, as well as the interfaces between the first and second levels and the second and third levels.
  • an arithmetic unit which consists only of the second and third levels, as well as the interfaces between the first and second levels and the second and third levels.
  • a system already exists which is not made available by the arithmetic unit itself; to the system of the first level is merely docked.
  • Such a constellation may occur, for example, when the third-level agents are robots in the real world.
  • this constellation occurs when the second and third levels provide Artificial Intelligence for an already existing first level computer game.
  • the object of the invention is further achieved by a simulator for a multi-agent system.
  • the simulator has means for implementing a first level representing a system. It also has means for implementing a second level that has an abstract, concept-reduced representation of the first level system. Finally, it still has means for implementing a third level, which has means for implementing the agents of the multi-agent system.
  • the simulator has an interface for communication between the first and second levels, as well as an interface for communication between the second and third levels.
  • the simulator can be implemented both in hardware and in software.
  • the object of the invention is further solved by an architecture or software architecture for implementing a multi-agent system.
  • the architecture has a first level that represents a system. Furthermore, a second level, which has an abstract, reduced to concepts representation of the system of the first level. Finally, a third
  • a level comprising means for implementing the agents of the multi-agent system.
  • An interface provides communication between the first and second levels. Another interface for communication between the second and the third level.
  • the object of the invention is further characterized by an architecture of a computer program or software architecture for implementing a multi-agent system. This consists only of the second and third levels, as well as the interfaces between the first and second levels and the second and third levels.
  • a system already exists which is not provided by the architecture itself; to the system of the first level is merely docked.
  • the object of the invention is further solved by a middleware for the development of a computer program for implementing a multi-agent system.
  • the middleware is based on the described software architecture, but does not contain the complete implementation or the game as middleware.
  • the first level system is not part of the middleware.
  • the middleware is designed to complement these. Therefore, the middleware provides only the second and third levels, which provide the capabilities of the agents.
  • simulations or computer games can be extended by the AI capabilities of agents or these can be easily integrated in the development.
  • the middleware is thus a tool or software tool for the development of simulations or computer games.
  • the object of the invention is further achieved by a method.
  • individual process steps are described in more detail. The steps do not necessarily have to be performed in the order given, and the method to be described may also have other steps not mentioned.
  • a first level representing a system is implemented.
  • a second level is implemented that provides an abstract concept-reduced rep presentation of the first level system.
  • a third level is implemented that includes means for implementing the agents of the multi-agent system.
  • Information is exchanged between the first and second levels, and between the second and third levels, but not between the first and third levels.
  • the object is achieved by a computer program which, when running on a computing unit, a microcontroller, DSP, FPGA or computer or on a plurality thereof in a network, carries out the method according to the invention in one of its embodiments.
  • the object is achieved by a computer program with program code means in order to carry out the method according to the invention in one of its embodiments when the program is executed on a computer, a microcontroller, DSP, FPGA or computer or on a plurality thereof in a network.
  • the program code means may be instructions stored on a computer-readable medium.
  • the object is achieved by a data carrier on which a data structure is stored, which after loading into a working and / or main memory of a computing unit, a microcontroller, DSPs, FPGAs or computers or a plurality thereof in a network, the inventive Execute method in one of its embodiments.
  • a computer program product having program code means stored on a machine-readable carrier in order to carry out the method according to the invention in one of its embodiments, if the program is on a computer, a microcontroller, DSP, FPGA or computer or on a plurality thereof in a network leads.
  • the program is understood as a tradable product. In principle, it can be in any form, for example on paper or a computer-readable data carrier, and in particular can be distributed via a data transmission network.
  • a modulated data signal which contains instructions executable by a computing unit, a microcontroller, DSP, FPGA or computer or a plurality thereof in a network for carrying out the method according to the invention in one of its embodiments.
  • both a stand-alone computer or microcontroller, DSPs or FPGAs are considered, as well as a network of microcontrollers, DSPs, FPGAs or computers, such as an in-house, closed network, or even computers, over the Internet connected to each other.
  • the computer system can be realized by a client-server constellation, wherein parts of the invention run on the server, others on a client.
  • Fig. 2-1 is an overview of the components in the AI engine;
  • Fig. 3-1 is a schematic model of an X-Ait agent;
  • Fig. 4-1 is a schematic representation of the process, if a
  • Fig. 4-2 is a schematic illustration of the process when a speech act is sent from Agent A to Agent B;
  • Fig. 4-3 is a schematic representation of the process, when a
  • Fig. 4-4 is a schematic representation of the process when a percept request from agent A is made, which can be satisfied by the cache in the world representation;
  • Fig. 4-5 is a schematic representation of the process, if a
  • Fig. 4-6 is a schematic representation of the process, when a
  • Fig. 5-1 is a schematic representation of the AI engine in one
  • Fig. 5-2 is a schematic representation of the AI engine in a
  • Fig. 2-1 shows the general data flow of the AI components and the game.
  • the world server (WorldServer) separates the game from the agents and encapsulates the game engine data through actions, percepts, from the point of view of agents.
  • the world server thus provides the agent with all the information about the game and keeps the data sources transparent to the agents, since the data required by the agents can either be buffered in the global world representation (Worldrepresentation), or directly from the game engine be read out.
  • the goal is to allow a separation of logic in agents and data in the game. Only the action handlers and percept handlers access interface methods that need to be deployed in the game engine.
  • the actions and perceptions provide the agents with a standardized interface for data and function calls to the game engine.
  • the implementations of the agents can be 100% reused and only the interface methods within the game engine need to be implemented to handle the very simple actions and data requests ( Datarequest).
  • Datarequest The data requirements are another form of perceptions.
  • the interface between the game and the world server or agent has been designed to be in principle the same as the input and output of a human player. This can be seen in Fig. 2-1 on the data flow of the AI interface (AI interface) towards game and that of a human player. 2.1 The human player
  • the human player it has a very limited interface to manipulate the gameplay. This is essentially limited to the input devices available to him (keyboard, mouse, joystick). So that the game can inform the player feedback about his actions, there are output devices such as monitor and sound output. These things are enough to allow the player to gather enough information from the game to successfully control the gameplay. We will also use this approach in the AI engine, as we will see later.
  • the game consisting of various components such as graphics, sound, physics, etc., is not explained here.
  • the key part of the game is the AI interface, which allows the AI engine to communicate with the game itself and its components.
  • the interface between game and AI engine was modeled after the model of the human player. We want to reduce the data to be exchanged to a minimum and only refer to information that a human player can receive or hand over to the game.
  • the entire interface between game and AI engine is divided into two parts. On the one hand there is the AI interface and on the other hand the game interface. A task that is performed in both interface parts is the conversion of IDs (identifiers).
  • the game and the AI engine assign different IDs for the same game object. Within the game, there are IDs for moving game objects that have an artificial intelligence by the agent in the AI engine, which in turn has a different ID. The different IDs allow a better arrangement of agent data structures. To make this transparent to the game and the AI engine, the common IDs within the actions, perceptions and events in the interface are automatically converted. The dealers are responsible for the special cases (see below).
  • the AI interface is part of the game and gives the game the ability to send information to the AI engine. This includes sending events and initializing as well as manipulating parameters of the AI engine. Events are generated by the game engine when z. B. a sound is played. In an event only rudimentary information is included, such. For example, who triggered the event and what event it is. So that the AI engine can get computing time, there is an update method, which starts the data flow of the AI engine in the play and synchronizes also the KI internal music box. The complete function reference to the AI interface can be found in chapter 6 (see below).
  • the game interface is located in the AI engine and enables the communication of the AI engine in the direction of the game. There are two main functions with which the communication to the game takes place:
  • Actions generated in the AI engine are sent to the game.
  • An action is a message in the form of a C ++ struct. This contains elementary commands such as "move left”, “move right”, “take”, etc. These commands correspond to actions that a human user or player can make, such B. makes entries via a keyboard. They must be able to be implemented by a game engine in the same way as human player inputs. This facilitates or enables processing by the game engine.
  • the PerformAction method invokes a callback function defined in the game to initialize the AI engine. This callback function must now implement the actions in the game world for a particular agent. The calls to the callback function are triggered by the game at a point defined by the game. Examples of actions and a corresponding callback function are given in Section 6.5.
  • the RequestData function also uses a callback function to retrieve data from the game.
  • the task of the function is the answering or filling of a data request (DataRequest) of the AI engine to the game. This is to replace the missing in comparison to the human player monitor output.
  • DataRequest data request
  • the queried data are based on the data types available in games, so that no complicated conversions need to be made.
  • the world server within the AI engine provides a certain level of abstraction between the actual game and the agents acting in it.
  • the various agents can interact with the world server through actions and perceptions.
  • the world server accepts actions and perceptions from the agents and transforms them so that the game can interpret the data correctly.
  • the world server is made up of various components that direct data flow from the agent to the game engine and back.
  • the action manager takes care of the timing of actions that need to be taken into play.
  • the action manager consists mainly of a queue, which can take actions and a 1-to-1 assignment, which assigns exactly one action handler to a certain type of action.
  • Actions can be taken by the Action Manager at any time by the agents. These are then first inserted into a FIFO queue. Periodically, the Action Manager is assigned time to process the data in its queue. This point in time is determined by the game, as during the execution of the actions callback calls occur within the game. Now that the action manager has time, he takes one action at a time from the queue and calls the appropriate action handler for each type of action, passing the action to the action handler. Then the reference to the action is removed from the queue and the next action is continued.
  • An action handler performs operations on a particular type of action. There can only be one action for each action handler to work on, but there can be more than one action handler for an action. There is thus a one-to-many relationship between action and action handler. This has the advantage that in an action handler we can perform various post-processing operations that adapt an action to the particular game. In the process, no new information can be introduced into the action, but those in the
  • Action included Data can be converted if necessary. The agent can thus continue to send the known actions, without having to pay attention to the variation in the game.
  • One of the most common applications for the action handler is the conversion of IDs.
  • actions can contain additional IDs about game objects in addition to the standard IDs that are converted in the interface. These must also be converted for the game to handle the action properly.
  • the event manager takes over the timing for sending events to the AI engine. It consists, as does the Actionmana- ger, from a queue that can receive new events and has an assignment of events to event handlers.
  • the Actionmana- ger from a queue that can receive new events and has an assignment of events to event handlers.
  • This multiple relationship is set to a 1-to-1 relationship at the initialization stage of the AI engine.
  • the event manager can record new events from the game at any time. However, these are stored in the FIFO queue until the world server assigns the event manager computation time so that he can process the events further. Once the event manager has the calculation control, he processes all events in his queue. This prevents an overflow of the queue in case there is always too little computation time available. To do this, he calls the appropriate event handler for each event and hands the event over to the event handler. In contrast to the Action Manager, the event is not always deleted from the queue. Should the event handler If the event can not be processed, the further processing of the event is postponed until the next call by leaving the event in the queue.
  • An event handler performs operation on a specific event.
  • the task of the event handler is the transformation of an event into a percept and the update of the global world representation (Worldrepresentation) if this is necessary for an event.
  • Each event handler has a list of Agent IDs and associated SubIDs for which to generate perceptions from the event. To do this he takes the event and in the first step carries out an update of the global world representation, if this is necessary for the event.
  • a frame is a frame of a simulation or a computer game. Typically, one would like to offer about 25, 50 or more per second to the human user, so that movements are fluent and not jerky. Therefore, about 10-40 ms are usually available for calculating a frame. If now an update of the world representation has been carried out, the event processing can be continued. Now, for each agent component registered with the event handler, a per- zept generated and this forwarded to the respective agent.
  • the event handler can perform further operations. So he can z. For example, at a sound event, generate additional information for the agent, such as the volume of the sound it receives, if not already done by the game engine. Furthermore, the task of converting IDs, for IDs that go beyond the standard in the event struct, is an issue. So you can edit the event in the event handler as you like, because you pass on another data structure, the concept.
  • the percept manager takes over the timing to send perceptions to the game engine. Like any other previously introduced manager, the percept manager also has a FIFO queue, which accepts new perceptions from the agent. In order to be able to process the percept, there is again an assignment table from percepts to percept handlers. Between perceptions and perceptuals, there is a one-to-many relationship, so that one can approach the information for a percept in different ways. At the initialization phase, the corresponding percept handlers are defined in order to arrive at a one-to-one relationship. Since we do not want to load the corresponding percept handlers here every time for all possible concepts, we also use the principle of registering here.
  • an agent now wants to make a percept request, then he has to register with the world server for the respective perceptions. If a percept handler does not already exist for the respective percept, a new percept handler is created in the world server and this is then registered with the percept manager. To When registering, the agent can send perceptions to the percept manager.
  • the percept handler should only read out data for processing the perception of the game.
  • the read-out data is passed on to the perceptual manager so that it can buffer it for the ProcessData step.
  • the percept manager performs this procedure for all the perceptions in its queue without deleting the queue.
  • the percept manager then returns the calculation control to the world server.
  • the second step is a ProcessData step. During this step, the perceptual manager takes a percept with the corresponding data request from the queue and executes the appropriate percept handler with the process data step. In this
  • the percept handler can edit the previously collected data and send it back to the agent in a percept.
  • the percept handler can tell the perceptual manager that he was unable to complete the processing of the perceptual in due time, and wants to be called again at the next ProcessData.
  • the perceptual manager remembers these perceptions and will not do any more FetchData steps for them next time.
  • the ProcessData step all the perceptions are processed until the queue is empty, so that there is no overflow in the queue if there is too little computation time available for the KI engine.
  • a percept handler is needed to fill a certain percept with information from the game. It thus represents a general interface between the data formats of the agents and the game.
  • the percept handler collects the information from the game he needs to fill the percept with information. He gets the data via the so-called DataRequest structs. These are sent through the game interface to the game and filled there with a callback function. After returning the callback function, the DataRequest is filled with valid data. The filled DataRequest are passed to the Perceptmanager. This has the advantage that you do not have to store any perceptual-specific information in the percept handler. The percept handler is only responsible for the processing of the percepts, and therefore only one percept handler exists for all perceptions of one type. After all data has been requested by the game, the step FetchData is completed.
  • the percept handler receives the percept to fill and the set of DataRequests that he previously collected in FetchData. With this data, the percept handler now fills the percept. Should he take too long to work, he can tell the perceptual manager that he wants to be called again the next time. To process the data, the percept handler can use additional Percept Plugins (Percept Puggins) as well as the world representation. During the calculation, the percept handler is subject to a level of detail (LOD) mechanism. The LOD corresponds to the priority of the respective agent who requested the percept. Should the agent has a low priority, the perceptual handler should avoid intensive arithmetic operations.
  • LOD level of detail
  • Synthetic Vision the synthetic view of an agent on the virtual world
  • the Perzept Plugin Synthetic Vision consumes a lot of computing time.
  • the plugin determines the visible objects within an image. You can also approximate this by asking directly at the game engine which objects are within a defined visible range.
  • a percept plugin supports the percept handler in calculating the perceptions.
  • a percept plugin may e.g. Synthetic Vision, which extracts the visible objects from an image.
  • the internal clock stores the current music box. This is not to be confused with the system clock. There are many games that have their own music box, so they can realize slow motion.
  • the world representation serves to abstract the game world for the agent.
  • the data in the world representation can be obtained in an offline process, or as an online process during the game.
  • One of the main tasks of the world representation is to store a navigation graph so that the agents can navigate in the virtual world.
  • the various game genres have different forms of world representation, which are controlled via a uniform interface. Examples include the navigation mesh graph, which is often used in first-person shooters, and a heightmap for navigating real-time strategy games.
  • the world representation can also serve as a cache of information that you do not always want to extract from all game agents. This can be, for example, the position of certain objects. In addition, you have the ability to efficiently perform neighborhood tests to z. B. to avoid collisions, if the game is not already available.
  • Agent Engine symbolizes all agents that are in the AI engine.
  • the agent management as well as the administration time of the agents are carried out by the world server. At this point, only the rough components of an agent are briefly explained (see Fig. 3-1). The detailed description follows in Chapter 3.
  • the agent consists of two main components. This is on the one hand the X-ait agent engine, and on the other hand the knowledge base (KB).
  • the agent architecture models the flow of data in a cognitive environment. A detailed description of the individual components of the architecture follows in Chapter 3.1. 2.4.1.2 knowledge base
  • the knowledge base (KB) provides each agent with their individual knowledge. As already mentioned, here again part of the world representation can be found.
  • the X-ait agent engine gets most of its knowledge directly from the knowledge base. Excluded are z. For example, some events that the agent was unable to see. The exact structure of the knowledge base is also explained in section Agent.
  • the X-ait agents are a further development of the InteRRaP architecture, which consists of three levels in which each higher level has a higher abstraction than the lower one [JPM99].
  • the three levels are divided vertically into two modules: One module contains the knowledge base of each level and the other contains various control components that interact with the corresponding levels of the knowledge base.
  • Distributed vertically across all levels is the local world representation, which contains all 3D information (position of objects and agents, room layout, etc.).
  • the InteRRaP architecture has a world interface, i. H. an interface to the world.
  • the world interface consists of several components.
  • the agent interacts with the world only through actions and perceptions.
  • Behavior In the reactive level (Behavior) of the InteRRaP architecture, the so-called “behaviors” are programmed and stored. These are encapsulated behaviors and actions of the agent.
  • the example of computer football would be elementary behaviors (atomic actions) of an agent or player, such.
  • a plan may be a sequence of "elementary behaviors.”
  • An example of a plan might be, for example, ⁇ "lead”, “dribble with ball,””shot,”> a script equivalent.
  • Co-operation level In the co-operation level (Cooperation) social plans are created, with the example football this would be the interaction of the eleven players of a football team. In general, these are fixed plans, such as the interaction of the players through coordinated running behavior and passing play, with the goal of scoring a goal. So the agent can give instructions to other agents by instructing the execution of elementary behaviors.
  • the ID stored by the planner for the corresponding action is used.
  • the PDDL Planning Domain Definition Language
  • PDDL Types, Predicates, Actions
  • the modified InteRRaP model has an optimized data flow, which makes it easier to exchange information between the different levels of the InteRRaP model.
  • the focus was on making the model as flexible as possible so that the X-Ait agent can be set up in a modular way and no longer has to manage the data flow in the newly implemented modules.
  • Each one must be in the original InteRRaP model Manage module, whether it responds to an action or percept. This decision is either very easy to make, assuming that certain actions and perceptions can only be handled by individual levels, or very difficult when it comes to changing already generated actions in their content, if a deeper level is something wants to execute.
  • the new approach is based on the targeted actions and concepts. When two levels communicate with each other, they do so through perceptions.
  • Percepts have the advantage that they are self-contained data packets that are not tied to interface definitions. These are very basic concepts that are self-evident for some level within the InteRRaP. For example, the reactive level must be able to understand a percept with a plan, since it is the definition of the reactive level that it executes plans. One reason why we do not use a concrete interface for internal communication is the fact that you can better control the processing time with concepts. If a percept is sent from one level to another, this percept must pass through the percept queue. This is only emptied to every frame. Thus, there is automatically a suspend between the filling of the word in the sender level and the reception in the receiver level.
  • the common knowledge base provided by the framework ie the generic AI architecture
  • the local world representation is a copy of the global world representation with individual changes.
  • the percept memory stores perceptions between and also makes percept requests to the KI world server, if information in the store is too old or missing.
  • the knowledge bases for co-operation, local planning, and reactive-level presented in the original InteRRaP still exist, but are not provided by the framework.
  • the knowledge bases are special implementations that are dependent on the respective module.
  • Actions One of the elementary data structures with which the agent can interact with its environment is the actions (actions).
  • An action describes an elementary control event, similar to a keystroke on the keyboard by a human.
  • An action always contains the following information:
  • Action-specific information is added to the information in each action. This could be the pressed key in the case of a "key press" action.
  • Another main purpose of actions is the translation of speech acts (Speechact).
  • the speech acts are used for communication between the agents. However, these are always sent through the game so that the game has full control over the communication between the agents.
  • the speech acts are sent into the game as an action and sent from the game as an e-vent to the target addressee in the AI engine.
  • this is represented by the speech acts (Speechacts) which are also sent to the action manager. As shown in the diagram, actions are only started from the co-operation and reactive levels. 3.2.2 speech acts
  • Speech files are very compact data structures that are exchanged between two communication partners.
  • a speech act is intended to model the communication between two people. At first, one does not commit oneself to a specific medium, but analyzes the pure communication between two people. From the analyzes of this traffic and the additional necessity of information for the administration by the framework, the following basic data arise, which are preferably present in each speech act:
  • the percepts are also very elementary data structures. These allow the agent to extract information from the game world via the KI world server or to communicate within the agent. Percepts have - just like action - predefined basic information. These are preferably: • type of percept (hearing, seeing, speech act, etc.),
  • the Perzept InQueue handles all incoming perceptions. These can have been generated both externally and internally.
  • the Perzept InQueue is a simple FIFO queue. This is completely processed each time an agent receives the arithmetic control. This is to prevent an overflow in the queue if too little computing time is available.
  • Percept Distribution is an extension of Percept InQueue. This is responsible for the fact that the perceptions in the queue can be forwarded to the corresponding components (react, plan, cooperate). This process is triggered each time the agent gets processing time. In this case, the corresponding component of the agent is determined with the SubID within the period and then the corresponding handle method (processing method) of the component is called with the percept. The handle method of the component then processes the percept. This is done until the queue is empty. In this case, none of the handle methods should create new perceptions, which in turn are sent to the current agent. If this happens, new perceptions that arrive during the processing of the queue will not be considered in this step. This is achieved by not having the queue until it is empty, but iterates over the queue until the end specified at the beginning of the process.
  • SubIDs within an agent are split into a static and a dynamic range.
  • the static range is set quickly.
  • These are the three main components of the agent, the cooperative level, planning level and the reactive level.
  • the classification is as follows:
  • SubIDs are static, so that internal communication is possible at all. In addition, they are the same across all agents, so that one level of cooperation of one agent can communicate with the level of cooperation of another agent. All other SubIDs are assigned dynamically during runtime. Possible components are z. B. further sub-components within the reactive plane, or parts of the memory Perzept, z. B. seeing, hearing, so the 5 senses. These components come with a dynamically assigned SubID because they only need it to request new data from the KI world server. These components do not communicate with other components within one agent or the components of another agent.
  • the level of cooperation is the highest level in an agent modeled by InteRRaP. In it the communication between two agents takes place. For this purpose, various communication protocols can be used in the communication level. One of the most commonly used protocols at this level is the well-known Contract Net Protocol.
  • the cooperation component can send speech acts in the form of actions to other agents. For this, the cooperation component only needs the ID of the Other agents know that the cooperation component of each agent must register for speech acts on the World Server, and there deposit the corresponding SubID, which is used as the recipient ID.
  • the cooperation layer can now also send plans directly to the reactive layer via the Percept InQueue. This has the advantage that you do not have a great deal of communication overhead for very simple agents that only accept commands and execute them.
  • the preferred modified X-Ait agent is less computationally intensive in this regard.
  • the normal task of the cooperation level is to communicate with other agents and finally, or during communication, to send orders to the local planning level.
  • Communication within the agent works through perceptions. For this purpose, various concepts for communication between communication level and local planning as well as communication level and reactive levels are available. These are: • Communication level ⁇ -> Planning level: o PerceptGoal: The planning should generate a plan for a certain goal. o PerceptGoalFB: For the response to a previously sent PerceptGoal. It contains whether the goal could be carried out or not and justification in case of failure.
  • This percept contains whether the plan was successful or not failed, and when it failed, in which plan step.
  • the planning level accepts targets / tasks from the communication level and generates a possible plan. This plan is then sent to the reactive layer for execution.
  • the planning level is not intended to be able to send actions. It serves as a planning tool between communication level and reactive level. For this she uses the same concepts as the communication level.
  • Planning level ⁇ -> communication level o PerceptGoal: Contains a destination for which the planning levels should generate a plan.
  • o PerceptGoalFB For the response to a previously sent PerceptGoal. This includes whether or not the target could be executed and, if necessary, the reason for the failure.
  • Planning level ⁇ -> Reactive level o PerceptPlan: Contains a plan that is to be executed by the reactive level.
  • o PerceptPlanFB This turns the reactive level into the
  • PerceptPlan Response to a previously transmitted PerceptPlan sent to the planning level. This percept contains whether the plan was successful or failed, and if it failed, in which plan step.
  • the reactive level At the reactive level, the actual control of the agent happens. Here, individual behaviors are executed, which in turn generate control inputs for the game.
  • the reactive level can not make their own decisions. However, it can react to certain events with predefined behaviors. This would be z. For example, when an enemy is spotted and a behavior then automatically targets and shoots at it.
  • the reactive level can communicate with both the communication level and the planning level. This depends on who sent the current plan to the reactive layer. The adoption of new plans, as already described on the other two levels, is done through perceptions.
  • the reactive level must understand the following two concepts:
  • PerceptPlan Contains a plan to be executed by the reactive layer.
  • PerceptPlanFB This transfers the response from the reactive level to a previously transmitted PerceptPlan to the planning or communication level. This percept contains whether the plan was successful or failed, and if it failed, in which plan step.
  • the local knowledge base stores the knowledge that is available across all components of the X-Ait Agent. This is done by trying to put the data into a general form so that the knowledge can be used in each component without having to understand complicated knowledge representations. If a component needs special knowledge, it will be created and managed within the component.
  • the general knowledge base can be divided into two parts due to its enjoyment. On the one hand, this is knowledge about the landscape or geometry of the environment. This information is stored in the local world representation (Local World Representation). This part of the knowledge base provides information to the agent how its environment is built and also gives it the ability to start pathfinding for the environment.
  • the local world representation resembles the spatial thinking ability of a human being. He can thus find his way around his surroundings. He recognizes thereby whether he is in one
  • the local world representation is a copy of the global representation of the world, but it may contain deviations that have been created by the experiences of the agent.
  • the second part of the knowledge base is the Percept Memory (Percept Memory).
  • the percept memory is a cache which caches perceptual requests. Because perceptions contain factual knowledge, percept memory is a form of factual knowledge. Each percept has a certain lifetime, which gives information about how long the percept is already in the percept
  • each percept in the percept memory has a lifetime that, when exceeded, signals the memory that the percept should be removed from memory. Since the components for a percept request interact with the knowledge base, they can indicate to the knowledge base and thus the percept memory how old the requested information may be. If the information within the percept memory is below this limit, the percept memory can return the desired information directly to the respective component. If the information is too old or the lifetime of the perpective is exceeded, the percept memory can start a new perceptual request to the game. This caching mechanism thus allows a component programmer to make the agent more human by not always relying on up-to-date information from the game, but also being misinformed once he allows for a certain amount of information.
  • Another application scenario is the division of behaviors into knowledge-building and knowledge-requesting behaviors. So one can write a Behavior, which writes knowledge in the Percept memory, if it z. B. sees new objects. On the other hand, one can write behaviors that use exactly that knowledge, no matter how old it is, and in the absence of information, do not send new perceptual requests to the game.
  • the control flow in the agent is both data-driven and goal-driven.
  • the entrance of percepts leads to a change of the local or global world model.
  • different behaviors are activated, terminated, or executed.
  • the execution of a behavioral pattern is determined by the local planning level and the
  • Targets are dictated by the components within an agent, either statically from a file, or dynamically in response to an environmental change. These goals initiate a flow of data.
  • This data flow can be visualized within the AI engine.
  • the agent can place perceptual requests to the game, which will be answered by the game at a later time.
  • We use a modified interaction diagram to represent the data flow (see Fig. 4-1). This diagram has the time in the vertical axis. The horizontal axis shows the individual components that participate in the data flow. In addition to the normal marking that work is done in this component, the blocks are marked with different hatching, where
  • Another change is the aggregation of multiple data flow steps using a thick border. This symbolizes that one can not separate this sequence of steps externally; one can separate the data flow only at places, at which a new border begins. If the first processing step within a border is started, all steps are processed until the border changes into a new border. In the case of the transition from two different borders, a possible separation can lead to a very large time delay, depending on whether the KI
  • Engine is optimized for multithreads or singlethreads. More specifically, the data flow is stopped at the transitions, e.g. B. by a queue, and can be continued later. 4.1 Send actions to the game
  • Actions are sent by the agent to the game to change the state of the agent.
  • Agent A creates an action, either directly in a component or through the ActionCreator, and sends it to the action manager in the WorldServer.
  • the action manager executes the corresponding ActionHandler on the action.
  • the ActionHandler performs a corresponding conversion of the data in the action so that the game can correctly interpret the action. (e.g., object ID conversion) and sends the action through the AI interface to the game engine.
  • the AI object IDs of an action are converted to the game object ID.
  • the game engine accepts the action in a callback function and implements the action in the game, or postpones it until later.
  • the action handler converts the receiver and sender IDs of the speech act and passes the action to the game via the AI interface.
  • the AI interface converts the AI Sender ID of the action into a corresponding object ID of the game.
  • the action is parsed in a callback function and the speech act is encapsulated in an event and sent back to the AI interface. Or the speech act is discarded. Resending as an event can also be delayed by the game engine, such as when an agent sends too many messages.
  • the AI interface converts the sender ID of the event and forwards the event to the event manager.
  • If the event manager receives the calculation control he works off his queue and calls the suitable event handler for the speech act.
  • the event handler converts the event into a percept and sends it to the agent B, which serves as the recipient in the
  • Speech act is called.
  • this agent must have registered with the event handler for speech acts, otherwise the speech act is discarded.
  • the percept is forwarded to the communication component, which then extracts the speech act from the percept.
  • events are constantly triggered. These may be sounds or events triggered by the game logic, such as: B. a lap start. Events are usually displayed visually on the monitor, in the form of text or images, or in the form of sound. These events are sent as events to the KI engine so that the agents can also interpret the gameplay correctly.
  • the game sends an event to the AI engine the event arrives at the agents as shown schematically in Figure 4-3: a) The game creates an event struct for the event and sends it to the AI interface. b) The AI interface converts the sender ID of the event and passes the event to the event manager. c) If the event manager is handed over the calculation control, he calls the appropriate event handler for each event in the queue.
  • a percept is generated from the event. This percept can now contain more information than the event. In the case of a sound event, the noise can be propagated through the world through the update in the world representation.
  • the percept which is sent to the agents then additionally contains the volume of the noise source, or they do not receive the percept, if they can no longer perceive the sound. The generated perceptions are then sent to the agents.
  • the agent accepts the percept and, if he has the computational control, forwards it to the appropriate component.
  • a percept handler which uses the world representation as a cache for the information sought in the percept. Furthermore, in this case, the information in the world representation is valid.
  • the data flow then proceeds as shown schematically in FIG. 4-4: a) Agent A creates an empty percept and sends this via the world server to the percept manager. b) The perceptual manager now gets the calculation control for the step FetchData. He forwards the empty percept to the percept handler by also executing the method FetchData for the percept handler. c) The percept handler now makes a request to the world representation for the required data in the percept. The data stored in the world representation must not exceed a certain age. d) The world representation returns valid data in this case (Reply). e) The percept handler has now collected all the information.
  • the percept handler Since the data in the world representation correspond to the required data in the percepts (AI internal data), this data is already written into the percept. The percept handler has then completed the step FetchData and returns the percept to the percept manager. f) If the percept manager then receives the calculation control for the step ProcessData, then it executes the percept handler with the method ProcessData. g) The percept handler now has the option of postprocessing the previously stored data in the percept. If he has done this, he sends the filled percept back to the agent A h) After the agent A has been assigned computation time, he takes the percept from his InQueue and sends it to the component that previously sent the request.
  • the game engine fills the DataRequest with the requested data and returns the DataRequest to the percept handler via the KI interface.
  • the percept handler has now collected all the necessary information and returns the percept together with the DataRequest to the percept manager. It does not perform any processing on the DataRequest because it is in the FetchData step.
  • the percept manager eventually receives the calculation control for the step ProcessData, he executes the method ProcessData in the case of the percept handler, and passes at the percept and the previously collected data in the form of the DataRequests.
  • the percept handler now processes the data from the data request and thus fills the percept.
  • agent A After agent A has been assigned processing time, he takes the percept from his InQueue and sends it to the
  • the third case occurs when the requested data must always be up-to-date (eg: the current position of the agent for the navigation), that it is not worth buffering data in the world representation.
  • the request and the update of the world representation are therefore completely eliminated in this step.
  • the data flow then proceeds as shown diagrammatically in FIGS. 4-6: a) Agent A creates an empty percept and sends this via the world server to the percept manager. b) The perceptual manager now gets the calculation control for the step FetchData. He forwards the empty percept to the percep- table handler by also executing the FetchData method in the percept handler. c) The percept handler sends a request (DataRequest) directly to the game engine via the AI interface.
  • DataRequest dataRequest
  • the game engine fills the DataRequest with the required data and returns the DataRequest to the percept handler via the KI interface.
  • the percept handler has now collected all the necessary information and gives the percept together with the DataRe quest back to the percept manager. It does not perform any processing on the DataRequest because it is in the FetchData step.
  • the percept manager receives the calculation control for the step ProcessData, he executes the method ProcessData in the context handler, passing the percept and the previously collected data in the form of the DataRequests.
  • the percept handler now processes the data from the data request and thus fills the percept. He then sends the filled percept back to the agent.
  • the agent A After the agent A has been assigned computation time, he takes the percept from his InQueue and sends it to the component that previously sent the request.
  • the computation time control within the AI engine distributes the available computation time to the various components.
  • the world server distributes the available computing time to the various managers and to the agents.
  • each agent has a rudimentary computing time control for its internal components. We therefore differentiate the global computation time control and the local computation time control within the agents.
  • Global Computing Time Control distributes computation time to key components, such as the managers within the WorldServer and the individual agents.
  • key components such as the managers within the WorldServer and the individual agents.
  • One model is designed for use in single-threaded applications and the other model for use in multi-threaded applications, so that a possibly available second CPU core can be used.
  • Action Manager The Action Manager sends all actions it has received to the game through the action handlers.
  • Event Manager The event manager sends events received to the agents. Since we have already run the action manager in front of the event manager, the events also include speech acts that were only sent to the game in this frame.
  • Percept manager FetchData The percept manager performs the FetchData step for the respective percept handlers for all percepts received by him. 4.
  • Percept Manager ProcessData Since we are in a single-threaded application, the next step for all percepts in the percept manager is the ProcessData step. Then the percepts are processed. 5.
  • AI scheduler + agent scheduler Next there is an iterated switch between the AI scheduler, which allocates computation time to an entire agent, and the agent scheduler, which allocates computation time to the individual components within an agent. First, the AI scheduler gets the remaining time of the AI engine and distributes it to the individual agents. Here, all agents can get computation time or only a part if too little computation time is available. By a round robin procedure, the other agents will then be given computation time in the next frame. The agent scheduler distributes the total time for an agent to the three major components in the agent.
  • Fig. 5-2 you can see the update history for the AI engine in a multithreaded application.
  • the game uses the AI interface to execute the sync (update) function of the AI engine.
  • This sync method now waits for the AI thread to complete its calculations for a frame. Thereafter, by executing the action manager, the actions stored in the action manager are sent into the game. Then the Sync Still try the FetchData step at the Percept Manager so that requests from the agents to the game can be satisfied. All data is sent to the game, or taken from the game.
  • the two threads can now split and go their separate ways until the next frame, when the thread thread re-executes the sync method of the AI interface.
  • the AI thread executes all updates, and also allocates processing time to the individual agents, as in the single-threaded application. If all computing time has been used up, the AI thread waits until the game executes a sync again.
  • the AI thread is assigned processing time, as in the single-threaded application. This will keep the game in control of the AI engine. Should z. For example, if the AI thread does not get the right processing power from the operating system, because the game is running on a single-core CPU or hyperthreading CPU, then it must still be possible for the AI to get enough CPU time. If the AI engine only performs a sync until the game thread is re-synced, it may be that the AI engine has not performed any calculations yet. The assigned computing time in the sync method thus ensures that the AI engine receives a minimum of computation time. The game thread must wait for the AI thread; This means that all CPU processing power is available to the AI thread.
  • Local computing time control refers to individual agents. Each agent has its own little computational time control. Within the agent, there are two components that are responsible for the computation time distribution. This is on the one hand the component scheduler and on the other the scheduler FSM.
  • the component scheduler can work with a static number of objects.
  • Each component has a priority that determines whether a component gets much or little processing time. The priority depends on the situation in which the agent is currently located. If the agent is currently in a planning phase, the planning level gets more computing time than the reactive and cooperation levels. However, if the agent is attacked during the planning phase, the reactive level must suddenly be allocated more computation time. This task is handled by the scheduler FSM.
  • the scheduler FSM Finite State Machine
  • the scheduler FSM is a simple state machine with predefined states. These states describe common mental states such as: • Neutral: The agent is in a neutral state. This is when there is no threat and the agent simply goes from A to B. • Think: The agent needs to think more. This is the case when he works out a new plan.
  • Panic This condition occurs when the agent is in a threatening situation. When he is under attack.
  • the designer can determine which priorities the components in the agent receive. If a state change now occurs, the scheduler FSM sets the new priorities for the state in the agent scheduler. In the state "Panic" z. B. the reactive level get the highest priority. The reactive layer thus receives excessive computing time, and thus the agent can escape the threat.
  • the individual states are changed directly by the respective components. In order to prevent the components from competing with one another for the computing time, priorities are assigned to the respective states. This priority should not be confused with the priorities assigned in a state to the respective components in the agent.
  • the scheduler FSM can only ever change from a lower priority state to a higher priority state. Only the component that has chosen the higher state can reset it to the normal state.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Theoretical Computer Science (AREA)
  • Evolutionary Computation (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • Computational Linguistics (AREA)
  • Artificial Intelligence (AREA)
  • Multi Processors (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Processing Or Creating Images (AREA)

Abstract

Es wird eine Architektur eines Computerprogramms zum Implementieren eines Multiagenten-Systems vorgeschlagen. Die Architektur erlaubt die Interaktion von Agenten mit einer Simulationsoder Spielwelt in einer ersten Ebene bzw. von Robotern mit der realen Welt[GV1] . Dazu hat die Architektur eine zweite und eine dritte Ebene. Die zweite Ebene enthält eine abstrakte, auf Konzepte reduzierte Repräsentation der Simulationswelt der ersten Ebene. Die dritte Ebene implementiert die Agenten des Multiagenten-Systems. Schnittstellen bestehen lediglich zwischen der ersten und zweiten Ebene, sowie zwischen der zweiten und dritten Ebene, nicht jedoch zwischen der ersten und dritten Ebene. Die zweite und dritte Ebene implementieren Künstliche Intelligenz der Agenten, so dass die Simulationswelt der ersten Ebene um Agenten ergänzt werden kann, die über künstliche Intelligenz verfügen. Auf diese Weise stellt die Architektur eine KI-Middleware für z. B. Computerspiele zur Verfügung.

Description

Generische KI -Architektur für ein MuItiagenten-System
Beschreibung
Gebiet der Erfindung
Die gängigen Simulationsprogramme oder Computerspiele weisen eine sehr gute Grafik und Simulation der physikalisch relevan- ten Effekte auf, jedoch nur eine begrenzte KI (KI = Künstliche Intelligenz, im Englischen: AI = artificial intelligence) der vom Computer gesteuerten Spieler (Agenten) . Während die Grafik und die Physik in Spielen über die Jahre hinweg stetig an Professionalität zugenommen haben, wurde die Implementierung der KI als notwendiges Übel hingenommen.
Stand der Technik
Das Forschungsgebiet der MuItiagenten Systeme und Architekturen ist breit. Jörg Müller beschreibt in "The Design of In- telligent Agents" [JPM99] eine Reihe von unterschiedlichen Design- und Architekturansätzen. Insbesondere wird die Agentenarchitektur InteRRaP vorgestellt, in der die Fähigkeiten eines Agenten in die drei Bereiche "Reaktives Verhalten" , "Rationales Planen" und "Kooperation" durch Schichten modelliert werden. In InteRRaP verfügt jede Schicht über eine eigene Wissensbasis.
Der Agent verfügt über ein Interface, mit dem er auf seine virtuelle oder reale Umwelt einwirken kann. Nur die unterste Schicht hat dabei Zugriff auf das Interface. Die anderen Schichten müssen sich der Steuerung durch die Verhaltensschicht bedienen, um auf die Umgebung einzuwirken. Aufgabe
Aufgabe der Erfindung ist es, den Einsatz von Künstlicher Intelligenz bei Simulationen und Computerspielen zu erleichtern.
Lösung
Diese Aufgabe wird durch die Erfindungen mit den Merkmalen der unabhängigen Ansprüche gelöst. Vorteilhafte Weiterbildungen der Erfindungen sind in den Unteransprüchen gekennzeichnet. Der Wortlaut sämtlicher Ansprüche wird hiermit durch Bezugnahme zum Inhalt dieser Beschreibung gemacht. Die Erfindung umfasst auch alle sinnvollen und insbesondere alle erwähnten Kombinationen von unabhängigen und/oder abhängigen Ansprüchen.
Die Entwicklung einer generischen KI Architektur (KI = Künstliche Intelligenz, im Englischen: AI = artificial intelli- gence) wurde durch die Misere aktueller Computerspiele in Bezug auf deren Künstliche Intelligenz für die vom Computer gesteuerten Spieler (Agenten) motiviert. Während die Grafik und die Physik in Spielen über die Jahre hinweg stetig an Professiona- lität zugenommen haben, wurde die Implementierung der KI als notwendiges Übel hingenommen.
In den Bereichen Grafik und Physik sind die Spielentwickler bereits soweit, dass eine Grafik- oder Physik-Middleware zum guten Ton gehört. Im Bereich KI gibt es hingegen keine Gesamt - konzepte, welche dem Spielentwickler die Programmierung einer eigenen KI abnehmen.
Mit der hier vorgestellten generischen KI -Architektur soll eine Plattform bereitgestellt werden, welche es dem Spielentwickler sehr leicht macht, eine KI zu integrieren, ohne sich mit dem Thema KI im Detail auseinander setzen zu müssen. Es soll eine KI-Engine geschaffen werden, die für einen Spielentwickler wie ein weiterer menschlicher Spieler wirkt. Wir haben uns deshalb als Ziel gesetzt, die KI -Architektur (Engine) so generisch wie möglich zu halten. Die Architektur soll eine Umgebung für die Agenten bereitstellen, innerhalb deren sie in- teragieren können. Wie wir später sehen werden, erzeugt die ge- nerische Architektur ein Metalevel für die Spielumgebung, so dass ein Agent in verschiedenen Spielen eingesetzt werden kann, ohne die genaue Umsetzung im Spiel berücksichtigen zu müssen.
Erfindungsgemäß wird zur Lösung der Aufgabe eine Recheneinheit zum Implementieren von Multiagenten-Systemen vorgeschlagen mit Mitteln zum Implementieren einer ersten Ebene, die ein System darstellt. Diese Ebene definiert z. B. das zu implementierende Computerspiel und wird deshalb häufig auch als Game- Engine bezeichnet. Etwas allgemeiner gesprochen stellt die erste Ebene in der Regel eine Simulationswelt dar. Sie kann aber auch die reale Welt sein, wenn die Agenten Roboter steuern. Allgemein gesprochen handelt es sich bei der ersten Ebene um ein System, das sich mit der Zeit verändert. Es kann durch Aktionen verändert werden. Ferner können sein Zustand bzw. Veränderungen seines Zustands wahrgenommen werden. Ferner enthält die Recheneinheit Mitteln zum Implementieren einer zweiten Ebene, die einen Weltserver aufweist, der eine abstrakte, auf Konzepte reduzierte Repräsentation des Systems der ersten Ebene aufweist. Der Weltserver reduziert z. B. Objekte des Systems der ersten Ebene auf wenige Parameter. Zwischen der ersten Ebene (Game-Engine) und der zweiten Ebene (Weltserver) gibt es eine Schnittstelle.
Schließlich enthält die Recheneinheit Mitteln zum Implementieren einer dritten Ebene, die Mittel zum Implementieren der Agenten des Multiagentensystems aufweist (Agent-Engine) . Zwischen der zweiten Ebene (Weltserver) und der dritten Ebene (Agent -Engine) gibt es ebenfalls eine Schnittstelle, nicht jedoch zwischen der ersten und dritten Ebene. Die zweite Ebene (der Weltserver) trennt die erste Ebene (das Spiel bzw. die Game-Engine) von den Agenten.
Dieser Aufbau erlaubt eine heuristische Behandlung virtueller physikalischer Effekte, durch den Weltserver, wodurch eine wesentlich komplexere Welt mit höherer Recheneffizienz simuliert werden kann. Die Architektur erlaubt also eine wesentlich gesteigerte Verarbeitungsgeschwindigkeit von Simulationsproblemen .
Als Recheneinheit kommen z. B. ein Computer oder Computer- System, ein MikroController, ein DSP, ein FPGA oder ähnliches oder eine Mehrzahl davon in einem Netzwerk in Frage. Als Computersystem kommen sowohl ein Stand-alone Computer in Betracht, als auch ein Netzwerk von Rechnern, beispielsweise ein hausinternes, geschlossenes Netz, oder auch Rechner, die über das In- ternet miteinander verbunden sind. Ferner kann das Computersystem durch eine Client-Server-Konstellation realisiert sein, wobei Teile der Erfindung auf dem Server, andere auf einem Client ablaufen.
Vorzugsweise weist die Schnittstelle zur Kommunikation zwischen der ersten Ebene (Game-Engine) und der zweiten Ebene (Weltserver) eine Struktur auf, die der Struktur einer Schnittstelle zwischen der ersten Ebene und einem menschlichen Bediener oder Spieler entspricht. D. h. für eine Simulation oder ein Spiel wirkt die KI-Middleware (also der Weltserver und die A- genten) bzw. wirken die erfindungsgemäßen Agenten wie weitere menschliche Spieler. Es bedarf keiner aufwändigen Anpassung des Spiels und keiner gesonderten Programmierung der KI.
Zur Vereinfachung der Struktur und Erhöhung der Verarbeitungsgeschwindigkeit erfolgt die Kommunikation zwischen der zweiten und der dritten Ebene mittels der Schnittstelle über Aktionen und Perzepte. Eines darüber hinaus gehenden Austau- sches bedarf es nicht. Mit anderen Worten: die zweite Ebene (der Weltserver) kapselt aus Sicht der Agenten die Daten des Systems der ersten Ebene (der Game-Engine) mithilfe von Aktionen und Perzepten. Unter einer Aktion wird dabei eine Interaktion verstanden, die in das System der ersten Ebene eingeleitet wird und dieses verändern kann.
Durch ein Perzept wird die Welt wahrgenommen. Durch ein Per- zept kann ein Agent Zustände der Welt abfragen bzw. wahrnehmen. Perzepte simulieren u. a. die Sinne eines Menschen. Perzepte haben den Vorteil, dass sie in sich abgeschlossene Datenpakete sind, welche nicht an Schnittstellendefinitionen gebunden sind.
Damit ein Agent ein Perzept empfangen bzw. wahrnehmen kann, muss er einen geeigneten Sensor aufweisen. Dieser simuliert z. B. ein Sinnesorgan, also z. B. die Fähigkeit zu Sehen oder zu Hören. Daher wird jedem Agent in der Regel mindestens ein vorgegebener virtueller Sensor zugeordnet, und die die Perzepte werden passend zu den jeweiligen Sensoren des Agenten gefil- tert . Mit anderen Worten: es wird eine Filterung der den Agenten zur Verfügung stehenden Informationen danach vorgenommen, was die jeweiligen Agenten wahrnehmen können. Dadurch können sehr realistische und flexible Mulitagente-Systeme implementiert werden.
Die Aufgabe wird ferner durch eine Recheneinheit gelöst, die lediglich aus der zweiten und dritten Ebene besteht, sowie aus den Schnittstellen zwischen der ersten und zweiten Ebene und der zweiten und dritten Ebene. In der ersten Ebene ist ein Sys- tem bereits vorhanden, was von der Recheneinheit selbst nicht zur Verfügung gestellt wird; an das System der ersten Ebene wird lediglich angedockt. Eine derartige Konstellation kann zum Beispiel auftreten, wenn die Agenten der dritten Ebene Roboter in der realen Welt steuern. Ebenso tritt diese Konstellation auf, wenn die zweite und dritte Ebene Künstliche Intelligenz für ein bereits vorhandenes Computerspiel in der ersten Ebene bereitstellen.
Die Aufgabe der Erfindung wird ferner durch einen Simulator für ein Multiagenten-Systems gelöst. Der Simulator hat Mittel zum Implementieren einer ersten Ebene, die ein System darstellt. Ferner hat er Mittel zum Implementieren einer zweiten Ebene, die eine abstrakte, auf Konzepte reduzierte Repräsentation des Systems der ersten Ebene aufweist. Schließlich hat er noch Mittel zum Implementieren einer dritten Ebene, die Mittel zum Implementieren der Agenten des Multiagenten-Systems aufweist. Der Simulator hat eine Schnittstelle zur Kommunikation zwischen der ersten und der zweiten Ebene, sowie eine Schnittstelle zur Kommunikation zwischen der zweiten und der dritten Ebene. Der Simulator kann sowohl in Hardware als auch in Software ausgeführt sein.
Die Aufgabe der Erfindung wird ferner durch eine Architektur bzw. Software-Architektur zum Implementieren eines Multiagenten-Systems gelöst. Die Architektur weist eine ersten Ebene auf, die ein System darstellt. Ferner eine zweite Ebene, die eine abstrakte, auf Konzepte reduzierte Repräsentation des Sys- tems der ersten Ebene aufweist. Schließlich noch eine dritte
Ebene, die Mittel zum Implementieren der Agenten des Multiagenten-Systems aufweist. Eine Schnittstelle sorgt für die Kommunikation zwischen der ersten und der zweiten Ebene. Eine weitere Schnittstelle für die Kommunikation zwischen der zweiten und der dritten Ebene.
Die Aufgabe der Erfindung wird ferner durch eine Architektur eines Computerprogramms bzw. Software-Architektur zum Implemen- tieren eines Multiagenten-Systems gelöst. Diese besteht lediglich aus der zweiten und dritten Ebene, sowie aus den Schnittstellen zwischen der ersten und zweiten Ebene und der zweiten und dritten Ebene. In der ersten Ebene ist ein System bereits vorhanden, was von der Architektur selbst nicht zur Verfügung gestellt wird; an das System der ersten Ebene wird lediglich angedockt .
Die Aufgabe der Erfindung wird ferner durch eine Middleware für die Entwicklung eines Computerprogramms zum Implementieren eines Multiagenten-Systems gelöst. Die Middleware beruht auf der beschriebenen Software-Architektur, enthält jedoch als Middleware folglich nicht die komplette Implementation oder das ganze Spiel. Insbesondere ist das System der ersten Ebene nicht Teil der Middleware. Die Middleware ist so aufgebaut, dass sie diese ergänzt. Daher stellt die Middleware lediglich die zweite und dritte Ebene zur Verfügung, die die Fähigkeiten der Agenten bereitstellt. Dadurch können Simulationen oder Computerspiele um die KI -Fähigkeiten von Agenten erweitert werden bzw. diese können bei der Entwicklung leicht integriert werden. Die Middleware ist damit ein Werkzeug oder Software-Tool für die Entwicklung von Simulationen oder Computerspielen.
Die Aufgabe der Erfindung wird ferner durch ein Verfahren gelöst. Im Folgenden werden einzelne Verfahrensschritte näher beschrieben. Die Schritte müssen nicht notwendigerweise in der angegebenen Reihenfolge durchgeführt werden, und das zu schildernde Verfahren kann auch weitere, nicht genannte Schritte aufweisen. Gemäß dem vorgeschlagenen Verfahren zum Implementieren eines Multiagenten-Systems wird zunächst eine erste Ebene implementiert, die ein System darstellt. Sodann wird eine zweite Ebene implementiert, die eine abstrakte, auf Konzepte reduzierte Rep- räsentation des Systems der ersten Ebene aufweist. Schließlich wird eine dritte Ebene implementiert, die Mittel zum Implementieren der Agenten des Multiagenten-Systems aufweist.
Informationen werden zwischen der ersten und der zweiten E- bene, sowie zwischen der zweiten und der dritten Ebene ausgetauscht, nicht jedoch zwischen der ersten und der dritten Ebene .
Ferner wird die Aufgabe gelöst durch ein Computerprogramm, das bei Ablauf auf einer Recheneinheit, einem Mikrocontroller, DSP, FPGA oder Computer oder auf einer Mehrzahl davon in einem Netzwerk das erfindungsgemäße Verfahren in einer seiner Ausgestaltungen ausführt.
Weiterhin wird die Aufgabe gelöst durch ein Computerprogramm mit Programmcode-Mitteln, um das erfindungsgemäße Verfahren in einer seiner Ausgestaltungen durchzuführen, wenn das Programm auf einer Recheneinheit, einem Mikrocontroller, DSP, FPGA oder Computer oder auf einer Mehrzahl davon in einem Netzwerk ausgeführt wird. Insbesondere können die Programmcode-Mittel auf ei- nem computerlesbaren Datenträger gespeicherte Instruktionen sein.
Außerdem wird die Aufgabe gelöst durch einen Datenträger, auf dem eine Datenstruktur gespeichert ist, die nach einem Laden in einen Arbeits- und/oder Hauptspeicher einer Rechenein- heit, eines MikroControllers, DSPs, FPGAs oder Computers oder einer Mehrzahl davon in einem Netzwerk das erfindungsgemäße Verfahren in einer seiner Ausgestaltungen ausführen kann.
Auch wird die Aufgabe gelöst durch ein Computerprogramm- Produkt mit auf einem maschinenlesbaren Träger gespeicherten Programmcode-Mitteln, um das erfindungsgemäße Verfahren in einer seiner Ausgestaltungen durchzuführen, wenn das Programm auf einer Recheneinheit, einem Mikrocontroller, DSP, FPGA oder Computer oder auf einer Mehrzahl davon in einem Netzwerk ausge- führt wird. Dabei wird unter einem Computer-Programmprodukt das Programm als handelbares Produkt verstanden. Es kann grundsätzlich in beliebiger Form vorliegen, so zum Beispiel auf Papier oder einem computerlesbaren Datenträger und kann insbesondere über ein Datenübertragungsnetz verteilt werden.
Schließlich wird die Aufgabe gelöst durch ein moduliertes Datensignal, welches von einer Recheneinheit, einem Mikrocont- roller, DSP, FPGA oder Computer oder von einer Mehrzahl davon in einem Netzwerk ausführbare Instruktionen zum Ausführen des erfindungsgemäßen Verfahrens in einer seiner Ausgestaltungen enthält.
Als Computersystem zum Ausführen des Verfahrens kommen sowohl ein Stand-alone Computer oder Mikrocontroller, DSPs oder FPGAs in Betracht, als auch ein Netzwerk von Mikrocontrollern, DSPs, FPGAs oder Rechnern, beispielsweise ein hausinternes, geschlossenes Netz, oder auch Rechner, die über das Internet miteinander verbunden sind. Ferner kann das Computersystem durch eine Client-Server-Konstellation realisiert sein, wobei Teile der Erfindung auf dem Server, andere auf einem Client ablaufen.
Weitere Einzelheiten und Merkmale ergeben sich aus der nachfolgenden Beschreibung von bevorzugten Ausführungsbeispielen in Verbindung mit den Unteransprüchen. Hierbei können die jeweiligen Merkmale für sich alleine oder zu mehreren in Kombination miteinander verwirklicht sein. Die Möglichkeiten, die Aufgabe zu lösen, sind nicht auf die Ausführungsbeispiele beschränkt. Die Ausführungsbeispiele sind in den Figuren schematisch dargestellt. Gleiche Bezugsziffern in den einzelnen Figuren bezeichnen dabei gleiche oder funktionsgleiche bzw. hinsichtlich ihrer Funktionen einander entsprechende Elemente. Im Einzelnen zeigt :
Fig. 2-1 einen Überblick der Komponenten in der KI Engine; Fig. 3-1 ein schematisches Modell eines X-Ait-Agenten;
Fig. 4-1 eine schematische Darstellung des Ablaufs, wenn eine
Aktion ins Spiel gesendet wird;
Fig. 4-2 eine schematische Darstellung des Ablaufs, wenn ein Sprechakt von Agent A zu Agent B gesendet wird;
Fig. 4-3 eine schematische Darstellung des Ablaufs, wenn ein
Event vom Spiel an mehrere Agenten in der KI -Engine gesendet wird;
Fig. 4-4 eine schematische Darstellung des Ablaufs, wenn eine Perzeptanfrage von Agent A gestellt wird, die durch den Cache in der Weltrepräsentation befriedigt werden kann; Fig. 4-5 eine schematische Darstellung des Ablaufs, wenn eine
Perzeptanfrage von Agent A gestellt wird, wobei die Informationen in der Weltrepräsentation nicht aktuell genug sind, und eine Anfrage an das Spiel gestellt werden muss; Fig. 4-6 eine schematische Darstellung des Ablaufs, wenn eine
Perzeptanfrage von Agent A gestellt wird, wenn die an- geforderten Daten immer so aktuell sein müssen, dass es sich nicht lohnt, Daten in der Weltrepräsentation zwischenzuspeichern; Fig. 5-1 eine schematische Darstellung der KI-Engine in einer
Singlethread Umgebung; und Fig. 5-2 eine schematische Darstellung der KI-Engine in einer
Multithread Umgebung.
1 INHALTSVERZEICHNIS DER AUSFUHRLICHEN FIGURENBESCHREIBUNG
2 ÜBERBLICK DER KOMPONENTEN
2.1 DER MENSCHLICHE SPIELER
2.2 SPIEL 2.2.1 Schnittstelle zwischen Spiel und KI Engine
2.3 WELTSERVER
2.3.1 Action-Manager
2.3.2 Action-Handler 2.3.3 Event -Manager
2.3.4 Event -Handler
2.3.5 Perzept-Manager
2.3.6 Perzept-Handler
2.3.7 Perzept-Plugins 2.3.8 Interne Uhr
2.3.9 Weltrepräsentation
2.4 AGENT ENGINE
2.4.1 Agent
2.4.1.1 X-ait-Agent Engine 2.4.1.2 Wissensbasis DER X-AIT-AGENT
3.1 Die Architektur der X-Ait -Agenten
3.2 DAS BEVORZUGTE MODIFIZIERTE INTERRAP MODEL DES X-AIT- AGENTEN 3.2.1 Aktionen
3.2.2 Sprechakte
3.2.3 Perzepte
3.2.4 Perzept InQueue
3.2.5 Perzept Verteilung 3.2.6 Kooperationsebene
3.2.7 Lokale Planungsebene
3.2.8 Reaktivebene
3.2.9 Lokale Wissensbasis DATENFLUSS 4.1 AKTIONEN INS SPIEL SENDEN
4.2 SPRECHAKTE VON EINEM AGENTEN ZUM ANDEREN VERSENDEN
4.3 SENDEN EINES EVENTS VOM SPIEL IN DIE KI-ENGINE
4.4 PERZEPTANFRAGE AN DAS SPIEL (PULL) - FALL 1 4.5 PERZEPTANFRAGE AN DAS SPIEL (PULL) - FALL 2
4.6 PERZEPTANFRAGE AN DAS SPIEL (PULL) - FALL 3 RECHENZEITKONTROLLE
5.1 GLOBALE RECHENZEITKONTROLLE 5.1.1 Singlethread Umgebung
5.1.2 Multithread Umgebung
5.2 LOKALE RECHENZEITKONTROLLE
5.2.1 Komponenten-Scheduler
5.2.2 Scheduler-FSM
2 Überblick der Komponenten
Fig. 2-1 zeigt den allgemeinen Datenfluss der KI Komponenten und des Spiels (Game) . Um Daten nicht redundant zu halten, trennt der Weltserver (Worldserver) das Spiel von den Agenten und kapselt aus Sicht der Agenten (Agents) die Daten der Spiel- Engine mithilfe von Aktionen (Actions) , Perzepten (Percepts) . So kann die Entwicklung der KI-Engine getrennt von der Implementierung der Spiel-Engine gehalten werden. Der Weltserver stellt den Agenten also alle Informationen über das Spiel zur Verfügung und hält die Datenquellen transparent für die Agenten, denn die von den Agenten benötigten Daten können entweder schon in der globalen Weltrepräsentation (Worldrepresentation) gepuffert sein, oder müssen direkt aus der Spiel-Engine ausgelesen werden. Ziel ist es hierdurch eine Trennung der Logik in Agenten und Daten im Spiel zu ermöglichen. Lediglich die Ac- tion-Handler und Perzept -Handler greifen auf Interface-Methoden zu, die in der Spiel-Engine bereitgestellt werden müssen. Die Aktionen und Perzepte bieten, zusammen mit den jeweiligen Handlern, den Agenten eine standardisierte Schnittstelle für Daten und Funktionsaufrufe zur Spiel-Engine. So können bei einem ä- quivalenten Spiel (gleiches Genre) die Implementierung der A- genten zu 100% wieder verwendet werden und lediglich die Interface-Methoden innerhalb der Spiel-Engine müssen implementiert werden, damit sie die sehr einfach gestrickten Aktionen und die Datenanforderungen (Datarequest ) ausführen können. Die Datenanforderungen sind eine weitere Form der Perzepte.
Die Schnittstelle zwischen dem Spiel und Weltserver bzw. A- gent wurde so konzipiert, dass sie vom Prinzip her mit den Ein- und Ausgaben eines menschlichen Spielers übereinstimmt. Dies kann man in Fig. 2-1 am Datenfluss des KI-Interfaces (AI- Interface) in Richtung Spiel und dem eines menschlichen Spielers erkennen. 2.1 Der menschliche Spieler
Betrachtet man den menschlichen Spieler (Human Gamer) , so hat dieser ein sehr begrenztes Interface um den Spielablauf zu manipulieren. Dies beschränkt sich im Wesentlichen auf die Ihm zur Verfügung stehenden Eingabegeräte (Tastatur, Maus, Joystick) . Damit das Spiel dem Spieler Feedback über seine Aktionen miteilen kann, gibt es Ausgabegeräte wie Monitor und Soundausgabe. Diese Dinge reichen, damit der Spieler genügend Informationen aus dem Spiel entnehmen kann, um den Spielablauf er- folgreich zu kontrollieren. Diesen Ansatz werden wir auch in der KI - Engine verwenden, wie man später sieht.
2.2 Spiel
Das Spiel, bestehend aus verschiedensten Komponenten wie Grafik, Sound, Physik usw., wird hier nicht näher erläutert. Der entscheidende Teil innerhalb des Spiels stellt das KI- Interface dar. Dieses erlaubt die Kommunikation der KI -Engine mit dem eigentlichen Spiel und den darin enthaltenen Komponenten.
2.2.1 Schnittstelle zwischen Spiel und KI-Engine
Die Schnittstelle zwischen Spiel und KI-Engine wurde nach dem Vorbild des menschlichen Spielers modelliert. Wir wollen dazu die auszutauschenden Daten auf ein Minimum reduzieren und beziehen uns nur auf Informationen die auch ein menschlicher Spieler erhalten kann, oder an das Spiel übergeben kann.
Die gesamte Schnittstelle zwischen Spiel und KI-Engine ist in zwei Teile unterteilt. Zum einen gibt es das KI-Interface und zum anderen das Game-Interface . Eine Aufgabe, die in beiden Schnittstellenteilen vorgenommen wird, ist die Konvertierung von IDs (Identifikatoren) . Das Spiel sowie die KI-Engine vergeben verschiedene IDs für das gleiche Spielobjekt. Innerhalb des Spiels gibt es IDs für bewegliche Spielobjekte, die eine künst- liehe Intelligenz durch den Agenten in der KI-Engine erhalten sollen, welcher wiederum eine andere ID hat. Die verschiedenen IDs ermöglichen eine bessere Anordnung der Agentendatenstrukturen. Damit dies transparent für das Spiel und die KI-Engine vonstatten geht, werden die gängigen IDs innerhalb der Aktionen, Perzepte und Events in der Schnittstelle automatisch konvertiert. Für die Spezialfälle sind die Handler verantwortlich (siehe unten) .
2.2.1.1 KI - Interface
Das KI-Interface (AI-Interface) ist Teil des Spiels und gibt dem Spiel die Möglichkeit, Informationen an die KI-Engine zu senden. Dazu gehört das Senden von Events und das Initialisieren sowie das manipulieren von Parametern der KI-Engine. Events werden von der Spiel-Engine erzeugt, wenn z. B. ein Sound abgespielt wird. In einem Event sind nur rudimentäre Informationen enthalten, wie z. B. wer das Event ausgelöst hat und um welches Event es sich handelt. Damit die KI-Engine Rechenzeit bekommen kann, gibt es eine Update Methode, welche den Datenfluss der KI-Engine in das Spiel startet und ebenfalls die KI interne Spieluhr synchronisiert. Die komplette Funktionsreferenz zum KI-Interface findet sich in Kapitel 6 (siehe unten) .
2.2.1.2 Game - Interface Das Spiel-Interface (Game-Interface) befindet sich in der KI-Engine und ermöglicht die Kommunikation der KI-Engine in Richtung des Spiels. Dabei gibt es zwei Hauptfunktionen mit der die Kommunikation zum Spiel stattfindet:
PerformAction:
Aktionen, welche in der KI-Engine generiert wurden, werden in das Spiel gesendet. Eine Aktion ist eine Nachricht in Form eines C++ Structs . Diese enthält elementare Befehle wie "bewege links", "bewege rechts", "nimm", usw.. Diese Befehle entsprechen den Aktionen, die ein menschlicher Nutzer oder Spieler erzeugen kann, der z. B. Eingaben über eine Tastatur tätigt. Sie müssen in gleicher Weise wie Einga- ben eines menschlichen Spielers durch eine Spiel-Engine umgesetzt werden können. Dies erleichtert oder ermöglicht die Verarbeitung durch die Game-Engine. Die PerformAction Methode ruft dazu eine zur Initialisierung der KI-Engine definierte Callback-Funktion im Spiel auf. Diese Callback- Funktion muss nun die Aktionen in der Spielwelt für einen bestimmten Agenten umsetzen. Die Aufrufe der Callback- Funktion werden durch das Spiel zu einem vom Spiel definierten Punkt getriggert . Beispiele von Aktionen und einer entsprechenden Callback-Funktion gibt es in Abschnitt 6.5.
RequestData :
Die RequestData Funktion verwendet ebenfalls, wie die PerformAction Methode, eine Callback-Funktion um Daten aus dem Spiel abzurufen. Die Aufgabe der Funktion ist das Beantwor- ten bzw. Befüllen einer Datenanforderung (DataRequest) der KI-Engine an das Spiel. Dies soll die im Vergleich zum menschlichen Spieler fehlende Monitorausgabe ersetzen. Die abgefragten Daten orientieren sich aber an den in Spielen vorhandenen Datentypen, damit keine komplizierten Konver- tierungen vorgenommen werden müssen.
2.3 Weltserver
Der Weltserver (Worldserver) innerhalb der KI-Engine stellt einen gewissen Abstraktionslevel zwischen dem eigentlichen Spiel und den darin agierenden Agenten zur Verfügung. Die verschiedenen Agenten können mit dem Weltserver über Aktionen und Perzepte interagieren. Der Weltserver nimmt Aktionen und Per- zepte von den Agenten entgegen und wandelt sie so um, so dass das Spiel die Daten richtig interpretieren kann. Dadurch müssen für verschiedene Spiele nur das KI-Interface und evtl. Teile des Weltservers angepasst werden, damit ein unveränderter Agent mit dem Spiel interagieren kann. Der Weltserver besteht aus verschiedenen Komponenten, welche den Datenfluss vom Agenten zur Spiel -Engine und zurück leiten.
2.3.1 Action-Manager
Der Actionmanager übernimmt das Timing von Aktionen, die ins Spiel geleitet werden müssen. Dabei besteht der Actionmanager hauptsächlich aus einer Queue, welche Aktionen entgegen nehmen kann und einer 1-zu-l Zuweisung, die einem bestimmten Typ von Aktion genau einen Actionhandler zuweißt. Aktionen können von dem Actionmanager jeder Zeit von den Agenten entgegen genommen werden. Diese werden dann zuerst in eine FIFO-Queue gesteckt. In regelmäßigen Abständen wird dem Actionmanager Zeit zugewiesen, damit dieser die in seiner Queue befindlichen Daten abarbeiten kann. Dieser Zeitpunkt wird durch das Spiel bestimmt, da es bei der Abarbeitung der Aktionen zu Callback-Aufrufen inner- halb des Spiels kommt. Nachdem der Actionmanager nun Zeit bekommen hat, nimmt er eine Aktion nach der anderen aus der Queue und ruft für den jeweiligen Typ der Aktion den passenden Actionhandler auf, wobei er dem Actionhandler die Aktion übergibt. Danach wird die Referenz auf die Aktion aus der Queue entfernt und mit der nächsten Aktion fortgefahren. Dieser Vorgang endet erst, wenn die komplette Queue abgearbeitet ist. Hier gibt es keine Unterteilung in Rechenschritte oder Rechenzeit. Dies würde dazu führen, dass ein stetig zu geringer Anteil an freier Rechenzeit, die Queue überlaufen lassen würde. Durch das komplette Abarbeiten der Queue wird das Spiel soweit ausgebremst, dass es mit den Eingaben der KI-Engine zurechtkommt. Dies ähnelt dem Prinzip einer Multiplayer Engine, welche alle Daten der Klienten bearbeiten muss, damit ein korrektes Gameplay zustande kommt. Da wir nicht immer für alle möglichen Aktionen die entsprechenden Actionhandler laden möchten, gibt es bei dem Actionmanager die Möglichkeit einzelne Actionhandler für eine gewisse Aktion zu registrieren. Will ein Agent eine gewisse Aktion an das Spiel senden, so muss er sich zu Beginn (während seiner Initialisierung) am Weltserver für eine bestimmte Aktion registrieren. Der Weltserver sorgt dann dafür, dass ein entsprechender Actionhandler angelegt wird, und am Actionmanager für die angeforderte Aktion registriert wird.
2.3.2 Action-Handler
Ein Actionhandler führt Operationen für einem bestimmten Typ von Aktionen aus. Es kann zu jedem Actionhandler nur genau eine Aktion geben, die er bearbeiten kann, aber es kann für eine Ak- tion mehr als einen Actionhandler geben. Es existiert somit eine 1-zu-x Beziehung zwischen Aktion und Actionhandler. Dies hat den Vorteil, dass wir in einem Actionhandler verschiedene Nachbearbeitungsoperationen durchführen können, welche eine Aktion auf das jeweilige Spiel anpassen. Dabei können keine neuen In- formationen in die Aktion eingeführt werden, aber die in der
Aktion enthalten Daten können konvertiert werden, wenn dies nötig ist. Der Agent kann somit weiterhin die ihm bekannten Aktionen schicken, ohne die Variation im Spiel beachten zu müssen. Eine der häufigsten Anwendungen für den Actionhandler ist die Konvertierungen von IDs. So können Aktionen, zu den bereits standardmäßig vorhandenen IDs, welche in der Schnittstelle konvertiert werden, weitere IDs über Spielobjekte enthalten. Diese müssen ebenfalls konvertiert werden, damit das Spiel die Aktion richtig verarbeiten kann.
2.3.3 Event-Manager
Der Eventmanager übernimmt das Timing für das Versenden von Events in die KI-Engine. Er besteht, ebenso wie der Actionmana- ger, aus einer Queue welche neue Events entgegen nehmen kann und besitzt eine Zuweisung von Events zu Eventhandlern. Hier haben wir wieder eine 1-zu-x Beziehung, da es zu jedem Event mehr als einen Eventhandler geben kann. Diese Mehrfachbeziehung wird zur Initialisierungsphase der KI-Engine auf eine 1-zu-l Beziehung festgelegt.
Ähnlich wie beim Actionmanager wollen wir nicht immer für alle möglichen Events die Eventhandler laden. Damit ein bestimmter Agent Events aus dem Spiel empfangen kann, muss er dies dem Eventmanager mitteilen. Dazu registriert er sich am Weltserver für ein gewisses Event. Dies führt dazu, dass der Weltserver einen neuen Eventhandler anlegt und diesen beim E- ventmanager registriert. Zusätzlich wird nun noch der Agent mit seiner ID sowie seiner SubID beim Eventmanager für ein gewisses Event registriert. Die Registrierungsinformation des Agenten wird dabei direkt im entsprechenden Eventhandler hinterlegt. Diese Information benötigt der Eventhandler, damit er bei einem eingehenden Event, das daraus resultierende Perzept an den korrekten Empfänger senden kann. Die bereits o. g. SubID ist eine ID, welche einzelne Komponenten innerhalb des Agenten adressiert. Damit umgeht man einen weiteren Verwaltungsaufwand für das Empfangen von Perzepten innerhalb des Agenten.
Der Eventmanager kann zu jedem Zeitpunkt neue Events aus dem Spiel aufnehmen. Diese werden aber solange in der FIFO-Queue gespeichert, bis der Weltserver dem Eventmanager Rechenzeit zuteilt, so dass dieser die Events weiterverarbeiten kann. Hat der Eventmanager einmal die Rechenkontrolle, so arbeitet er sämtliche Events in seiner Queue ab. Dies verhindert ein Überlaufen der Queue in dem Fall dass immer zu wenig Rechenzeit zur Verfügung steht. Dazu ruft er zu jedem Event den passenden E- venthandler auf, und übergibt das Event an den Eventhandler. Im Gegensatz zum Actionmanager wird das Event nicht in jedem Fall aus der Queue gelöscht. Sollte der Eventhandler mit der Bear- beitung des Events nicht fertig werden, so wird die weitere Bearbeitung des Events bis zum nächsten Aufruf verschoben, indem das Event in der Queue verbleibt.
2.3.4 Event-Handler
Ein Eventhandler führt Operation auf einem bestimmten Event aus. Die Aufgabe der Eventhandler ist die Transformation eines Events in ein Perzept und das Update der globalen Weltrepräsentation (Worldrepresentation) wenn dies für ein Event notwendig ist. Jeder Eventhandler hat eine Liste von Agenten IDs und zugehörigen SubIDs für die er Perzepte aus dem Event erzeugen soll. Dazu nimmt er das Event und führt im ersten Schritt ein Update der globalen Weltrepräsentation durch, wenn dies für das Event notwendig ist. Dies kann z. B. ein Soundevent sein, wel- ches zuerst durch die Welt propagiert werden muss, damit man feststellen kann, welchen Agent dieses Soundevent überhaupt erreicht. Da diese Berechnungen teilweise sehr lange dauern können, länger als der KI -Engine Rechenzeit pro Frame zusteht, kann ein komplexer Algorithmus an einer definierten Stelle die Verarbeitung unterbrechen und dem Eventmanager mitteilen, dass er für genau dieses Event wieder aufgerufen werden will. Der Eventmanager verschiebt dann die weitere Ausführung der Eventverarbeitung auf den nächsten Frame.
Ein Frame ist ein Einzelbild einer Simulation oder eines Computerspiels. Typischerweise möchte man davon ca. 25, 50 oder mehr pro Sekunde dem menschlichen Nutzer darbieten, damit Bewegungen fließend wirken und nicht ruckein. Daher stehen für die Berechnung eines Frames in der Regel etwa 10-40 ms zur Verfügung. Wurde nun ein Update der Weltrepräsentation durchgeführt kann die Eventbearbeitung fortgeführt werden. Es wird nun für jede beim Eventhandler registrierte Agentenkomponente ein Per- zept erzeugt und dieses an den jeweiligen Agenten weitergeleitet.
Neben dem Umkopieren der Daten aus dem Event -Struct in ein Perzept-Struct kann der Eventhandler weitere Operationen durch- führen. So kann er z. B. bei einem Soundevent weitere Informationen für den Agenten erzeugen, wie die Lautstärke des bei ihm empfangen Sounds, wenn dies nicht bereits durch die Spiele- Engine passiert ist. Desweiteren fällt die Aufgabe der Konvertierung von IDs an, für IDs die über den Standard im Event- Struct hinausgehen. Man kann also das Event im Eventhandler beliebig aufbereiten, da man eine andere Datenstruktur, das Per- zept, weiterleitet.
2.3.5 Perzept-Manager Der Perzeptmanager übernimmt das Timing zum Versenden von Perzepten an die Spiel-Engine . Wie jeder andere bisher vorgestellte Manager besitzt auch der Perzeptmanager eine FIFO- Queue, welche neue Perzepte vom Agenten entgegen nimmt. Damit die Perzepte bearbeitet werden können gibt es wieder eine Zu- Weisungstabelle von Perzepten zu Perzepthandlern. Zwischen Perzepten und Perzepthandlern gibt es eine 1-zu-x Beziehung, damit man auf verschiedene Arten und Weisen an die Informationen für ein Perzept herankommen kann. Zur Initialisierungsphase werden die entsprechenden Perzepthandler festgelegt, damit man auf ei- ne 1-zu-l Beziehung kommt. Da wir auch hier nicht jedes Mal für alle möglichen Perzepte die entsprechenden Perzepthandler laden wollen, benutzen wir auch hier das Prinzip des Registrierens . Will nun ein Agent eine Perzeptanfrage durchführen, so muss er sich beim Weltserver für die jeweiligen Perzepte registrieren. Falls nicht bereits ein Perzepthandler für das jeweilige Perzept existiert, so wird im Weltserver ein neuer Perzepthandler angelegt und dieser dann beim Perzeptmanager registriert. Nach der Registrierung kann der Agent Perzepte an den Perzeptmanager schicken.
Für die Bearbeitung der Perzepte in der FIFO-Queue unterscheiden wir zwei Bearbeitungsschritte. Zum einen haben wir den FetchData Schritt und zum anderen den ProcessData Schritt. Diese Unterteilung haben wir vorgenommen, um die Zeit während der Synchronisation zwischen dem Spiel und KI-Thread zu minimieren. Im FetchData Schritt soll der Perzepthandler lediglich Daten für die Bearbeitung des Perzepts beim Spiel auslesen. Die aus- gelesenen Daten werden zum Perzeptmanager durchgereicht, so dass dieser sie für den ProcessData Schritt Zwischenspeichern kann. Diesen Vorgang führt der Perzeptmanager für alle Perzepte in seiner Queue durch, ohne die Queue dabei zu löschen. Nachdem man für alle Perzepte einmal den FetchData Schritt ausgeführt hat, ist dieser Schritt abgeschlossen. Der Perzeptmanager gibt dann die Rechenkontrolle zurück an den Weltserver. Der zweite Schritt ist ein ProcessData Schritt. Während dieses Schritts, nimmt der Perzeptmanager jeweils ein Perzept mit dem zugehörigen DataRequest aus der Queue und führt damit den passenden Perzepthandler mit dem ProcessData Schritt aus. In diesem
Schritt kann der Perzepthandler die zuvor gesammelten Daten bearbeiten und in einem Perzept zurück an den Agenten schicken. Zusätzlich kann der Perzepthandler dem Perzeptmanager mitteilen, dass er die Bearbeitung des Perzepts nicht in angemessener Zeit abschließen konnte, und beim nächsten ProcessData wieder aufgerufen werden will. Der Perzeptmanager merkt sich diese Perzepte und führt für diese beim nächsten Mal keinen FetchData Schritt mehr durch. Im ProcessData Schritt werden alle Perzepte abgearbeitet bis die Queue leer ist, damit es nicht zu einem Überlauf in der Queue kommt, wenn zu wenig Rechenzeit für die KI -Engine zur Verfügung steht. 2.3.6 Perzept-Handler
Ein Perzepthandler wird dazu benötigt, ein gewisses Perzept mit Informationen aus dem Spiel zu füllen. Er stellt damit eine generelle Schnittstelle zwischen den Datenformaten der Agenten und dem Spiel dar.
Wie bereits im Perzeptmanager erklärt, gibt es zwei verschiedene Bearbeitungsschritte, die jeder Perzepthandler beherrschen muss. Zum einen ist dies der FetchData Schritt. Hier sammelt der Perzepthandler die Informationen aus dem Spiel, die er benötigt um das Perzept mit Informationen zu füllen. Die Daten bekommt er über die so genannten DataRequest Structs. Diese werden durch das Game-Interface an das Spiel gesendet und dort mit einer Callback Funktion befüllt. Nach dem Rückkehren der Callback Funktion ist das DataRequest mit gültigen Daten ge- füllt. Die gefüllten DataRequest werden an den Perzeptmanager gereicht. Dies hat den Vorteil, dass man keine perzeptspezifi- schen Informationen im Perzepthandler speichern muss. Der Perzepthandler ist lediglich für die Bearbeitung der Perzepte verantwortlich, und deshalb existiert für alle Perzepte eines Typs nur ein Perzepthandler. Nachdem alle Daten vom Spiel angefordert wurden, ist der Schritt FetchData abgeschlossen.
Im Bearbeitungsschritt ProcessData bekommt der Perzepthandler zum einen das zu füllende Perzept, und zum anderen eine Menge von DataRequests, die er zuvor in FetchData gesammelt hat. Mit diesen Daten füllt nun der Perzepthandler das Perzept. Sollte er für die Arbeit zu lange benötigen, so kann er dem Perzeptmanager mitteilen, dass er beim nächsten Durchgang erneut aufgerufen werden will. Für die Bearbeitung der Daten kann der Perzepthandler zusätzliche Perzept Plugins (Percept PIu- gins) sowie die Weltrepräsentation hinzuziehen. Während der Berechnung unterliegt der Perzepthandler einem Level of Detail (LOD) Mechanismus. Der LOD entspricht dabei der Priorität des jeweiligen Agenten, welcher das Perzept angefordert hat. Sollte der Agent eine geringe Priorität haben, so sollte der Per- zepthandler intensive Rechenoperationen vermeiden. Dies kann man am Beispiel von Synthetic Vision (die synthetische Sicht eines Agenten auf die virtuelle Welt) während einer Perzep- tanfrage erklären. Das Perzept Plugin Synthetic Vision verbraucht sehr viel Rechenzeit. Dabei stellt das Plugin die sichtbaren Objekte innerhalb eines Bildes fest. Man kann dies aber auch dadurch approximieren, dass man direkt bei der Spiel - Engine anfragt, welche Objekte innerhalb eines definierten ein- sehbaren Bereichs liegen.
Ist das Perzept nach den Berechnungen komplett gefüllt, wird es an den Agenten zurückgesendet, welcher als Absender im Perzept genannt ist.
2.3.7 Perzept-Plugins
Ein Perzept Plugin unterstützt den Perzepthandler bei der Berechnung der Perzepte. Ein Perzept Plugin kann z.B. Synthetic Vision sein, das aus einem Bild die sichtbaren Objekte extrahiert .
2.3.8 Interne Uhr
Die interne Uhr speichert die aktuelle Spieluhr. Diese ist nicht zu verwechseln mit der Systemuhr. Es gibt viele Spiele die ihre eigene Spieluhr haben, damit sie Zeitlupen realisieren können .
2.3.9 Weltrepräsentation
Die Weltrepräsentation dient dazu, die Spielwelt für den A- genten zu abstrahieren. Die Daten in der Weltrepräsentation können in einem Offline Prozess gewonnen werden, oder als Online Prozess während des Spiels. Eine der Hauptaufgaben der Weltrepräsentation ist die Speicherung eines Navigationsgraphen, damit die Agenten in der virtuellen Welt navigieren können. Für die verschiedenen Spielgenres gibt es verschiedene Formen der Weltrepräsentation, welche über ein einheitliches Interface angesteuert werden. Beispiele wären hier zum einen der Navigati- ons-Mesh-Graph, welcher häufig Verwendung in First-Person- Shootern findet, und zum anderen eine Heightmap zur Navigation in Echtzeit Strategie Spielen.
Die Weltrepräsentation kann auch als Cache für Informationen dienen, die man nicht immer für alle Agenten aus dem Spiel entnehmen will. Dies kann zum Beispiel die Position von gewissen Objekten sein. Zudem hat man die Möglichkeit effizient Nachbarschaftstests auszuführen, um z. B. Kollisionen zu vermeiden, wenn dies das Spiel nicht bereits zur Verfügung stellt.
2.4 Agent-Engine Die Agent-Engine symbolisiert alle Agenten die sich in der KI-Engine befinden. Die Agentenverwaltung sowie die Rechenzeitverwaltung der Agenten werden vom Weltserver durchgeführt . An dieser Stelle werden nur kurz die groben Bestandteile eines A- genten erklärt (siehe Fig. 3-1) . Die genaue Beschreibung folgt in Kapitel 3.
2.4.1 Agent
Der Agent besteht aus zwei Hauptbestandteilen. Dies ist zum einen die X-ait -Agent Engine, und zum anderen die Wissensbasis (Knowledge Base - KB) .
2.4.1.1 X-ait-Agent Engine
Die Agentenarchitektur modelliert den Datenfluss in einer kognitiven Umgebung. Eine genaue Beschreibung der einzelnen Komponenten der Architektur folgt im Kapitel 3.1. 2.4.1.2 Wissensbasis
Die Wissensbasis (Knowledge Base - KB) stellt jedem Agenten sein individuelles Wissen zur Verfügung. Wie bereits erwähnt findet sich hier auch wieder ein Teil der Weltrepräsentation. Die X-ait -Agent Engine bekommt den Großteil ihres Wissens direkt aus der Wissensbasis. Ausgeschlossen davon sind z. B. einige Events, die der Agent nicht wahrnehmen konnte. Der genaue Aufbau der Wissensbasis wird ebenfalls in Abschnitt Agent erklärt.
3. Der X-ait-Agent
3.1 Die Architektur der X-Ait-Agenten
Die X-ait-Agenten (siehe Fig. 3-1) sind eine Weiterentwick- lung der InteRRaP-Architektur , die aus drei Ebenen besteht, in der jede höhere Ebene eine höhere Abstraktion als die untere aufweist [JPM99] . Zusätzlich werden die drei Ebenen vertikal in zwei Module geteilt: Ein Modul enthält die Wissensbasis jeder Ebene und das andere enthält verschiedene Kontrollkomponenten, die mit den korrespondierenden Ebenen der Wissensbasis inter- agieren. Vertikal über alle Ebenen verteilt existiert die lokale Weltrepräsentation, die alle 3D- Informationen (Position von Gegenständen und Agenten, Raumaufteilung etc.) enthält.
Die InteRRaP-Architektur hat ein Welt-Interface, d. h. eine Schnittstelle zur Welt. Technisch besteht das Welt-Interface aus mehreren Komponenten. Der Agent interagiert mit der Welt ausschließlich über Aktionen und Perzepte .
In der Reaktivebene (Behaviour) der InteRRaP-Architektur werden die so genannten "Behaviours" programmiert und abgelegt. Das sind eingekapselte Verhaltensweisen und Aktionen des Agenten. Am Beispiel Computerfußball wären dies elementare Verhaltensweisen (atomare Aktionen) eines Agenten bzw. Spielers, wie z. B. "Vorlaufen", "Drehen", "Dribbeln mit Ball" und "Tor- schuss". Die Abfolge solcher Einzelverhaltensweisen wird durch spontane Reaktion im Spielgeschehen angestoßen, oder eine Abfolge der atomaren Aktionen wird in so genannten Skripten fest definiert oder durch die nächst höhere Ebene geplant . In der Planungsebene wird für jeden einzelnen Spieler ein typischer Funktionsplan aus den Elementar-Behaviours (atomaren Aktionen) zusammengestellt, d. h. ein Plan ist eine Abfolge von "Elementar-Behaviours". Ein Beispiel für einen Plan könnte z. B. lauten: < "Vorlaufen" "Dribbeln mit Ball" "Torschuss" >, was einem Skript entspricht.
In der Kooperationsebene (Cooperation) werden soziale Pläne erstellt, am Beispiel Fußball wäre das das Zusammenspiel der elf Spieler einer Fußballmannschaft. Im Allgemeinen werden dies feste Pläne sein, wie das Zusammenspiel der Spieler durch koor- diniertes Laufverhalten und Passspiel, mit dem Ziel zum Torerfolg zu kommen. So kann der Agent anderen Agenten Anweisungen geben, in dem er die Ausführung von Elementar-Behaviours anweist .
Als Grundlage für die Beschreibung der Aktionen z. B. wäh- rend der Kommunikation für die Kooperation dient die vom Planer für die entsprechende Aktion gespeicherte ID. Als Beschreibung für die Welt und die darin ausführbaren Aktionen dient dem Planer der PDDL-Standard (PDDL = Planning Domain Definition Langu- age) (Typen, Prädikate, Aktionen).
3.2 Das bevorzugte modifizierte InteRRaP Model des X-Ait-Agent
Das modifizierte InteRRaP Model hat einen optimierten Daten- fluss, der es erleichtert, Informationen zwischen den verschiedenen Ebenen des InteRRaP Models auszutauschen. Im Vordergrund stand, das Model so flexibel wie möglich zu gestalten, damit man den X-Ait-Agenten modular aufbauen kann und in den neu implementierten Modulen keine Verwaltung de Datenflusses mehr vornehmen muss. In dem ursprünglichen InteRRaP Model muss jedes Modul verwalten, ob es auf eine Aktion oder Perzept reagiert. Diese Entscheidung ist entweder sehr leicht zu treffen, wenn man davon ausgeht, dass gewisse Aktion und Perzepte nur von einzelnen Ebenen bearbeitet werden können, oder sehr schwer, wenn es darum geht, bereits erzeugte Aktionen in ihrem Inhalt zu verändern, wenn eine tiefere Ebene etwas ausführen will. Der neue Ansatz orientiert sich an den zielgerichteten Aktionen und Perzepten. Wenn zwei Ebenen miteinander kommunizieren, so tun sie dies über Perzepte. Perzepte haben den Vorteil, dass es in sich abgeschlossene Datenpakete sind, welche nicht an Schnittstellendefinitionen gebunden sind. Dies sind sehr grundlegende Perzepte, welche für eine gewisse Ebene innerhalb des InteRRaP selbstverständlich sind. So muss z.B. die Reaktivebene ein Perzept mit einem Plan verstehen können, da es die Definition der Reaktivebene ist, dass sie Pläne ausführt. Ein Grund warum wir zur internen Kommunikation keine konkrete Schnittstelle verwenden, ist die Tatsache, dass man mit Perzepten die Rechenzeit besser kontrollieren kann. Wird ein Perzept von einer Ebene zu einer weiteren geschickt, so muss dieses Perzept durch die Per- zept-Queue. Diese wird aber nur zu jedem Frame geleert. So gibt es automatisch einen Suspend zwischen dem Auffüllen des Per- zepts in der Absender-Ebene und dem Empfang in der Empfängerebene .
Eine weitere offensichtliche Änderung im Design der einzel- nen Komponenten im Vergleich zum ursprünglichen InteRRaP Model ist die Wissensbasis (Knowledge Base) . Die vom Framework (also der generischen KI-Architektur) bereitgestellte gemeinsame Wissensbasis besteht nur noch aus der lokalen Weltrepräsentation (Local Worldrepresentation) und dem Perzept Speicher (Percept Memory) . Die lokale Weltrepräsentation ist dabei eine Kopie der globalen Weltrepräsentation mit individuellen Änderungen. Ferner gibt es den Perzept Speicher. Dieser speichert Perzepte zwischen und stellt auch Perzept -Anfragen an den KI Weltserver, wenn Informationen im Speicher zu alt sind oder fehlen. Die in dem ursprünglichen InteRRaP dargestellten Wissensbasen für Kooperation, Lokale Planung und Reaktivebene existieren immer noch, aber werden nicht vom Framework zur Verfügung gestellt. Die Wissensbasen sind spezielle Implementierungen, die abhängig von dem jeweiligen Modul sind.
3.2.1 Aktionen
Eine der elementaren Datenstrukturen, mit denen der Agent mit seiner Umgebung interagieren kann, sind die Aktionen (Ac- tions) . Eine Aktion beschreibt ein elementares Steuerungsereignis, ähnlich einem Tastendruck auf der Tastatur durch einen Menschen. Eine Aktion enthält immer folgende Informationen:
• Typ der Aktion (Tastendruck, Mausbewegung, Texteingabe, usw. ) und
• ID des Agenten, der die Aktion ausführen will.
Zu den in jeder Aktion vorhandenen Informationen kommen noch Aktionstyp-spezifische Informationen hinzu. Dies könnte im Fall einer Aktion "Tastendruck" die gedrückte Taste sein. Ein weiterer Hauptverwendungszweck von Aktionen ist die Ü- bermittlung von Sprechakten (Speechact) . Die Sprechakte dienen zur Kommunikation zwischen den Agenten. Diese werden aber immer über das Spiel gesendet, damit das Spiel die volle Kontrolle über die Kommunikation zwischen den Agenten hat. Damit man nicht eine weitere Schnittstelle ins Spiel benötigt, werden die Sprechakte als Aktion ins Spiel gesendet und vom Spiel als E- vent zum Zieladressat in die KI-Engine gesendet. In Fig. 3-1 wird dies durch die Sprechakte (Speechacts) , welche ebenfalls zum Actionmanager gesendet werden, dargestellt. Aktionen werden, wie im Schaubild gezeigt, nur von der Koo- perations- und Reaktivebene losgeschickt. 3.2.2 Sprechakte
Sprechakte sind sehr kompakte Datenstrukturen, die zwischen zwei Kommunikationspartnern ausgetauscht werden. Ein Sprechakt soll die Kommunikation zwischen zwei Menschen nachmodellieren. Dazu legt man sich zuerst nicht auf ein spezielles Medium fest, sondern analysiert den reinen Sprechverkehr zwischen zwei Menschen. Aus den Analysen dieses Gesprächsverkehrs und der zusätzlichen Notwendigkeit von Information zur Verwaltung durch das Framework ergeben sich folgende Grunddaten, die in jedem Sprechakt vorzugsweise vorhanden sind:
• Typ des Sprechakts (Anweisung, Information, usw.),
• ID des Agenten, der diesen Sprechakt initiiert hat (Absender) und
• ID des Agenten, der den Sprechakt empfangen soll (Empfän- ger) .
• Eine Erkennungsmarke, mit der der Empfänger auf diese Anfrage antworten soll, wenn dies nötig ist.
• Die Erkennungsmarke mit der der Absender rechnet, wenn man auf eine Anfrage antwortet . Diese Informationen werden für die Kommunikation immer benötigt. Zusätzlich werden noch Nutzdaten benötigt.
3.2.3 Perzepte
Die Perzepte sind ebenfalls sehr elementare Datenstrukturen. Diese ermöglichen dem Agenten, Informationen aus der Spielwelt über den KI -Weltserver zu entnehmen, oder damit er innerhalb des Agenten kommunizieren kann. Perzepte haben - ebenso wie Aktion - vordefinierte Grundinformationen. Diese sind vorzugsweise : • Typ des Perzepts (Hören, Sehen, Sprechakt usw.),
• ID des Agenten, der das Perzept empfangen soll, und • SubID der Komponente innerhalb eines Agenten, für den das
Perzept bestimmt ist.
Zusätzlich zu den Grundinformationen, die für die Vermittlung und Verteilung der Perzepte durch das Framework benötigt wer- den, gibt es die Nutzinformationen die je nach Perzept verschieden sind.
3.2.4 Perzept InQueue
Die Perzept InQueue nimmt alle eingehenden Perzepte entge- gen. Diese können sowohl extern als auch intern erzeugt worden sein. Die Perzept InQueue ist eine einfache FIFO-Queue. Diese wird jedes Mal, wenn ein Agent die Rechenkontrolle bekommt, komplett abgearbeitet. So soll verhindert werden, dass es zu einem Überlauf in der Queue kommt, wenn zu wenig Rechenzeit zur Verfügung steht.
3.2.5 Perzept Verteilung
Die Perzept Verteilung (Percept Distribution) ist eine Erweiterung der Perzept InQueue. Diese ist dafür verantwortlich, dass die Perzepte in der Queue an die entsprechenden Komponenten (Reagieren, Planen, Kooperieren) weitergeleitet werden können. Dieser Vorgang wird jedes Mal getriggert, wenn der Agent Rechenzeit bekommt. Dabei wird mit der SubID innerhalb des Per- zepts die entsprechende Komponente des Agenten ermittelt und dann die entsprechende Handle Methode (Bearbeitungsmethode) der Komponente mit dem Perzept aufgerufen. Die Handle Methode der Komponente verarbeitet dann das Perzept. Dies wird so lange durchgeführt, bis die Queue leer ist. Dabei sollte in keiner der Handle Methoden neue Perzepte angelegt werden, welche dann wiederum an den aktuellen Agenten gesendet werden. Sollte dies dennoch vorkommen, so werden neue Perzepte, die während der Abarbeitung der Queue eingehen, in diesem Schritt nicht betrachtetet. Dies wird dadurch erreicht, dass man nicht die Queue abarbeitet bis sie leer ist, sondern über die Queue iteriert bis zu einem am Anfang des Vorgangs festgelegten Ende.
Die SubIDs innerhalb eines Agenten werden in einen statischen und in einen dynamischen Bereich aufgeteilt. Der stati- sehe Bereich ist schnell festgelegt. Dies sind die drei Hauptkomponenten des Agenten, die Kooperativeebene, Planungsebene und die Reaktivebene. Dazu ist die Einteilung wie folgt:
• 0 : Reaktivebene
• 1 : Planungsebene • 2 : Kooperativebene
Diese SubIDs sind statisch, damit eine interne Kommunikation überhaupt möglich wird. Zudem sind sie über alle Agenten hinweg gleich, so dass eine Kooperationsebene eines Agenten mit der Kooperationsebene eines anderen Agenten kommunizieren kann. Alle weiteren SubIDs werden dynamisch während der Laufzeit vergeben. Mögliche Komponenten sind z. B. weitere Teilkomponenten innerhalb der Reaktivebene, oder Teile des Perzept Speichers, z. B. Sehen, Hören, also die 5 Sinne. Diese Komponenten kommen mit einer dynamisch zugewiesenen SubID aus, weil sie diese nur dazu benötigen, um neue Daten vom KI-Weltserver anzufordern. Diese Komponenten kommunizieren nicht mit anderen Komponenten innerhalb eines Agenten oder den Komponenten eines anderen Agenten.
3.2.6 Kooperationsebene
Die Kooperationsebene ist die höchste Ebene in einem durch InteRRaP modellierten Agenten. In ihr findet die Kommunikation zwischen zwei Agenten statt. Dazu können in der Kommunikationsebene verschiedene Kommunikationsprotokolle zum Einsatz kommen. Eines der am häufigsten verwendeten Protokolle in dieser Ebene ist das bekannte Contract Net Protocol . Die Kooperationskomponente kann Sprechakte in Form von Aktionen an andere Agenten schicken. Dazu muss die Kooperationskomponente nur die ID des anderen Agenten wissen, da sich die Kooperationskomponente eines jeden Agenten für Sprechakte am Weltserver registrieren muss, und damit dort die entsprechende SubID, die als Epfänger- ID verwendet wird, hinterlegt. Durch die Änderung des Datenflusses im bevorzugten modifizierten X-Ait-Agenten kann nun auch die Kooperationsebene direkt über die Percept InQueue Pläne an die Reaktivebene senden. Dies hat den Vorteil, dass man keinen großen Kommunikationso- verhead für sehr simple Agenten hat, welche nur Kommandos ent- gegen nehmen und diese Ausführen. Der bevorzugte modifizierte X-Ait-Agent ist in dieser Hinsicht weniger rechenintensiv.
Die normale Aufgabe der Kooperationsebene ist das kommunizieren mit anderen Agenten und schließlich, oder während der Kommunikation, das Senden von Aufträgen an die lokale Planungs- ebene.
Die Kommunikation innerhalb des Agenten funktioniert über Perzepte . Dazu stehen verschiedene Perzepte zur Kommunikation zwischen Kommunikationsebene und lokaler Planung sowie Kommunikationsebene und Reaktivebenen zur Verfügung. Dies sind: • Kommunikationsebene <-> Planungsebene: o PerceptGoal : Die Planung soll einen Plan für ein gewisses Ziel (Goal) erzeugen. o PerceptGoalFB : Für die Antwort auf ein zuvor gesendetes PerceptGoal. Darin ist enthalten ob das Ziel aus- geführt werden konnte oder nicht und eine Begründung im Falle des Scheiterns.
• Kommunikationsebene <-> Reaktivebene: o PerceptPlan: Enthält einen Plan, der von der Reaktivebene ausgeführt werden soll. o PerceptPlanFB: Damit wird aus der Reaktivebene die
Antwort auf einen zuvor übertragenen PerceptPlan an die Kommunikationsebene übermittelt. In diesem Percept ist enthalten, ob der Plan erfolgreich war oder gescheitert ist, und wenn er gescheitert ist, in welchem Planschritt .
3.2.7 Lokale Planungsebene Die Lokale Planung (Local Planning) nimmt Ziele / Aufgaben aus der Kommunikationsebene entgegen und erzeugt daraus einen möglichen Plan. Dieser Plan wird dann zur Ausführung an die Reaktivebene gesendet. Für die Planungsebene ist es nicht vorgesehen, dass sie Aktionen versenden kann. Sie dient als PIa- nungswerkzeug zwischen Kommunikationsebene und Reaktivebene. Dazu bedient sie sich denselben Perzepte wie die Kommunikationsebene .
• Planungsebene <-> Kommunikationsebene: o PerceptGoal : Enthält ein Ziel für das die Planungs- ebenen einen Plan erzeugen soll. o PerceptGoalFB : Für die Antwort auf ein zuvor gesendetes PerceptGoal. Darin ist enthalten, ob das Ziel ausgeführt werden konnte oder nicht und ggf. die Begründung für das Scheitern. • Planungsebene <-> Reaktivebene: o PerceptPlan: Enthält einen Plan, der von der Reaktivebene ausgeführt werden soll. o PerceptPlanFB : Damit wird aus der Reaktivebene die
Antwort auf einen zuvor übertragenen PerceptPlan an die Planungsebene übermittelt. In diesem Perzept ist enthalten, ob der Plan erfolgreich war oder gescheitert ist, und wenn er gescheitert ist, in welchem Planschritt .
3.2.8 Reaktivebene
In der Reaktivebene passiert die eigentliche Steuerung des Agenten. Hier werden einzelne Behaviours ausgeführt, welche wiederum Steuerinputs für das Spiel erzeugen. Die Reaktivebene kann keine eigenen Entscheidungen treffen. Sie kann aber auf gewisse Ereignisse mit vordefinierten Behaviours reagieren. Dies wäre z. B. der Fall, wenn ein Gegner gesichtet wird und ein Behaviour dann automatisch auf diesen zielt und schießt. Die Reaktivebene kann sowohl mit der Kommunikations- als auch mit der Planungsebene kommunizieren. Dies ist davon abhängig, wer den aktuellen Plan an die Reaktivebene gesendet hat. Die Annahme von neuen Plänen läuft wie bereits bei den beiden anderen Ebenen beschrieben über Perzepte. Die Reaktivebene muss da- zu die beiden folgenden Perzepte verstehen:
• PerceptPlan: Enthält einen Plan, der von der Reaktivebene ausgeführt werden soll.
• PerceptPlanFB : Damit wird aus der Reaktivebene die Antwort auf einen zuvor übertragenen PerceptPlan an die Planungs- oder Kommunikationsebene übermittelt. In diesem Perzept ist enthalten, ob der Plan erfolgreich war oder gescheitert ist, und wenn er gescheitert ist, in welchem Planschritt .
3.2.9 Lokale Wissensbasis
Die lokale Wissensbasis (Local Knowledge Base) speichert das Wissen, welches übergreifend für alle Komponenten des X-Ait- Agenten zur Verfügung steht. Dazu wird versucht, die Daten in eine allgemeine Form zu bringen, damit das Wissen in jeder Kom- ponente verwendet werden kann, ohne komplizierte Wissensrepräsentationen verstehen zu müssen. Sollte eine Komponente spezielles Wissen benötigen, so wird dieses innerhalb der Komponente angelegt und verwaltet. Die allgemeine Wissensbasis kann aufgrund ihrer Generalität in zwei Teile unterteilt werden. Dies ist zum einen das Wissen über die Landschaft bzw. Geometrie der Umgebung. Diese Information wird in der lokalen Weltrepräsentation (Local Worldrepresentation) abgespeichert. Dieser Teil der Wissensbasis liefert dem Agenten Informationen darüber, wie seine Umgebung aufgebaut ist, und gibt ihm darüber hinaus die Möglichkeit, Pfadsuchen für die Umgebung zu starten. Die lokale Weltrepräsentation gleicht dem räumlichen Denkvermögen eines Menschen. Dieser kann sich damit auch in seiner Umge- bung zurechtfinden. Er erkennt dadurch, ob er sich in einem
Raum oder unter freiem Himmel befindet, und wie er von A nach B kommt. Die lokale Weltrepräsentation ist eine Kopie der globalen Weltrepräsentation, kann aber Abweichungen enthalten, die durch die Erlebnisse des Agenten entstanden sind. Der zweite Teil der Wissensbasis ist der Perzept Speicher (Percept Memory) . Der Perzept Speicher ist ein Cache, welcher Perzeptanfragen zwischenspeichert. Da Perzepte Faktenwissen enthalten, ist der Perzept Speicher eine Form des Faktenwissens. Jedes Perzept hat eine gewisse Lebenszeit, die Auskunft darüber gibt, wie lange sich das Perzept bereits im Perzept
Speicher befindet. Zusätzlich zu der aktuellen Lebenszeit hat jedes Perzept im Perzept Speicher eine Lebensdauer, die, wenn sie überschritten wird, dem Speicher signalisiert, dass das Perzept aus dem Speicher entfernt werden soll. Da nun die Kom- ponenten für eine Perzeptanfrage mit der Wissensbasis inter- agieren, können sie der Wissensbasis und damit dem Perzept Speicher angeben, wie alt die abgefragte Information sein darf. Ist die Information innerhalb des Perzept Speichers unterhalb dieser Grenze, so kann der Perzept Speicher die gewünschte In- formation direkt an die jeweilige Komponente zurückgeben. Sollte die Information zu alt sein oder die Lebensdauer des Per- zepts überschritten sein, so kann der Perzept Speicher eine neue Perzeptanfrage an das Spiel starten. Dieser Caching Mechanismus ermöglicht es also einem Programmierer einer Komponente, den Agenten menschlicher zu gestalten, indem er sich nicht immer auf aktuelle Informationen aus dem Spiel stützt, sondern auch einmal Fehlinformationen unterliegt, wenn er ein gewisses Alter an Informationen zulässt. Ein weiteres Anwendungsszenario ist die Unterteilung von Be- haviours in Wissensaufbauende und Wissensabfragende Behaviours . So kann man ein Behaviour schreiben, welches Wissen in den Per- zept Speicher schreibt, wenn es z. B. neue Objekte sieht. Zum anderen kann man Behaviours schreiben, die genau dieses Wissen benutzen, egal wie alt es ist, und bei NichtVorhandensein der Information keine neuen Perzeptanfragen an das Spiel senden.
4 Datenfluss Der Kontrollfluss im Agent ist sowohl daten- , wie auch zielgesteuert. Der Eingang von Perzepten führt zu einer Veränderung des lokalen oder globalen Weltmodells. Als Reaktion auf Veränderungen des Weltmodells werden unterschiedliche Verhaltensmuster aktiviert, beendet oder ausgeführt. Die Ausführung eines Verhaltensmusters wird durch die lokale Planungsebene und die
Kooperationsebene angestoßen, wobei die Planungsebene dafür zuständig ist, neue eigene Pläne und daraus resultierend neue a- gentenübergreifende Pläne zu erzeugen, um die Ziele des Agenten wieder zu erreichen. Dies führt schließlich zur Ausführung von Aktionen und zur Erzeugung von Nachrichten (Sprechakten) .
Ziele werden von den Komponenten innerhalb eines Agenten vorgegeben, entweder statisch aus einer Datei, oder dynamisch als Reaktion auf eine UmweltVeränderung. Diese Ziele initiieren einen Datenfluss. Diesen Datenfluss kann man innerhalb der KI- Engine visualisieren. Es gibt verschiedene Datenflüsse, die innerhalb der KI -Engine ablaufen können. Dies sind zum einen Aktionen die gesendet werden, inklusive der darin verpackten Sprechakte. Daneben gibt es Events, die durch das Spiel erzeugt werden können, unter anderem als Ursache einer Aktion, die man zuvor ins Spiel gesendet hat. Des Weiteren kann der Agent Per- zeptanfragen an das Spiel stellen, die zu einem späteren Zeitpunkt durch das Spiel beantwortet werden. Im Folgenden soll der genaue Verlauf dieser Datenflüsse dargestellt werden. Wir verwenden zur Darstellung des Datenflusses ein modifiziertes Interaktions-Diagramm (siehe Fig. 4-1). Dieses Diagramm hat in der vertikalen Achse die Zeit. Auf der horizontalen Achse sind die einzelnen Komponenten, die am Datenfluss teilhaben, dargestellt. Zusätzlich zu der normalen Markierung, dass in dieser Komponente Arbeit verrichtet wird, sind die Blöcke unterschiedlich schraffiert markiert, wobei
• ein ϊSsssssssδü Block den Lebensstart einer Aktion / Event / Per- zept markiert,
• ein Block einen Bearbeitungsschritt für die Aktion / Event / Perzept markiert,
0% Block das Lebensende einer Aktion / Event / Perzept markiert, und wobei
• ein ≡≡≡≡≡≡≡ Block zusätzliche Informationsabfragen signali- siert.
Eine weitere Änderung ist die Zusammenfassung von mehreren Datenflussschritten mithilfe einer dicken Umrandung. Dadurch wird symbolisiert, dass man diese Abfolge von Schritten extern nicht mehr zertrennen kann; trennen kann man den Datenfluss nur an Stellen, an denen eine neue Umrandung beginnt . Wird der erste Bearbeitungsschritt innerhalb einer Umrandung gestartet, so werden alle Schritte bearbeitet, bis die Umrandung in eine neue Umrandung übergeht. Beim Übergang von zwei unterschiedlichen Umrandungen kann, durch eine hier mögliche Trennung, eine sehr große Zeitverzögerung auftreten, je nachdem ob die KI-
Engine für Multithreads oder Singlethreads optimiert ist. Genauer gesagt, wird der Datenfluss an den Übergängen angehalten, z. B. durch eine Queue, und kann später fortgesetzt werden. 4.1 Aktionen ins Spiel senden
Aktionen werden vom Agenten ins Spiel gesendet, damit diese den Zustand des Agenten verändern. In Fig. 4-1 sehen wir, welche Komponenten eine Aktion durchläuft, bis sie von Agent A bis zur Spiel-Engine (Game-Engine) gekommen ist. Der Ablauf lässt sich folgendermaßen beschreiben: a) Der Agent A erstellt eine Aktion, entweder direkt in einer Komponente oder durch den ActionCreator und sendet diese an den im Worldserver befindlichen Actionmanager . b) Wird dem Actionmanager die Rechenkontrolle übergeben, so führt der Actionmanager den entsprechenden ActionHandler auf der Aktion aus. c) Der ActionHandler führt eine entsprechende Konvertierung der Daten in der Aktion durch, damit das Spiel die Aktion korrekt interpretieren kann. (z.B. Objekt-ID Konvertierung) und sendet die Aktion durch das KI -Interface an die Spiel-Engine . d) Im KI -Interface werden die KI -Objekt -IDs einer Aktion in die Spiele-Objekt-ID konvertiert. e) Die Game-Engine nimmt die Aktion in einer Callback Funktion entgegen und setzt die Aktion im Spiel um, oder verschiebt sie bis zu einem späteren Zeitpunkt.
4.2 Sprechakte von einem Agenten zum Anderen versenden Damit ein Agent einen Sprechakt zu einem anderen Agenten senden kann, muss er diesen Sprechakt in einer Aktion kapseln und diese an das Spiel senden. Das Spiel hat dann die Aufgabe, diesen Sprechakt wieder in die KI-Engine zu senden. Dieser Mechanismus hat den Vorteil, dass die Spiellogik volle Kontrolle über die Kommunikation zwischen den Agenten hat. Sie kann somit Fehler in das Kommunikationsprotokoll einbauen, oder die Kommunikation vollständig unterdrücken, wenn z.B. die Spiellogik vorgibt, dass ein Agent zeitweise taub ist, oder der Funk in- nerhalb eines gewissen Bereichs gestört ist. Die Daten laufen wie in Fig. 4-2 schematisch dargestellt: a) Agent A legt einen Sprechakt an, den er in eine Aktion kapselt, und sendet diese an den Actionmanager . b) Wenn der Actionmanager die Rechenkontrolle erhält, nimmt er alle Aktionen aus seiner Queue und führt für jede Aktion den entsprechenden ActionHandler auf der Aktion aus. c) Der Actionhandler konvertiert die Empfänger- und Absender- IDs des Sprechakts und reicht die Aktion über das KI- Interface an das Spiel weiter. d) Das KI-Interface konvertiert die KI -Absender- ID der Aktion in eine entsprechende Objekt- ID des Spiels. e) Im Spiel wird in einer Callback Funktion die Aktion ge- parst und der Sprechakt, in einem Event gekapselt und zu- rück an das KI-Interface gesendet. Oder der Sprechakt wird verworfen. Das Zurücksenden als Event kann auch durch die Spiel-Engine verzögert werden, z.B. wenn ein Agent zu viele Nachrichten versendet. f) Das KI-Interface konvertiert die Absender-ID des Events und reicht das Event an den Eventmanager weiter. g) Bekommt der Eventmanager die Rechenkontrolle, dann arbeitet er seine Queue ab und ruft für das Sprechaktevent den passenden Eventhandler auf . h) Der Eventhandler wandelt das Event in ein Perzept und ver- sendet es an den Agenten B, welcher als Empfänger im
Sprechakt genannt ist. Zusätzlich muss sich dieser Agent bei dem Eventhandler für Sprechakte registriert haben, sonst wird der Sprechakt verworfen. i) Im Agent B wird das Perzept an die Kommunikationskomponen- te weitergeleitet, die dann den Sprechakt aus dem Perzept entnimmt . 4.3 Senden eines Events vom Spiel in die KI -Engine
Während des Spielablaufs werden ständig Events ausgelöst . Dies können zum einen Geräusche sein oder Ereignisse, die durch die Spiellogik ausgelöst werden, wie z. B. ein Rundenstart. Er- eignisse werden normalerweise visuell auf dem Monitor ausgeben, in Form von Text oder Bildern, oder in Form von Sound. Diese Ereignisse werden als Events an die KI -Engine gesendet, damit die Agenten den Spielablauf ebenfalls korrekt interpretieren können. Sendet das Spiel ein Event an die KI-Engine, gelangt der Event wie in Fig. 4-3 schematisch dargestellt an die Agenten : a) Das Spiel legt ein Event Struct für das entsprechende Ereignis an und gibt dieses an das KI-Interface . b) Das KI-Interface konvertiert die Absender-ID des Events und gibt das Event an den Eventmanager weiter. c) Wird dem Eventmanager die Rechenkontrolle übergeben, so ruft er für jedes Event in der Queue den passenden E- venthandler auf . d) Je nachdem, welcher Eventhandler ausgeführt wird, kann es dazu kommen, dass ein Update in der Weltrepräsentation durchgeführt wird. Dieser Schritt ist jedoch optional. Nachdem die Weltrepräsentation ein Update erhalten hat, wird aus dem Event ein Perzept erzeugt. Dieses Perzept kann nun mehr Informationen enthalten, als das Event. Im Falle eines Soundevents kann durch das Update in der Weltrepräsentation das Geräusch durch die Welt propagiert werden. Das Perzept welches an die Agenten geschickt wird enthält dann zusätzlich noch die Lautstärke der Geräuschquelle, oder sie erhalten das Perzept überhaupt nicht, wenn sie das Geräusch nicht mehr wahrnehmen können. Die erzeugten Perzepte werden dann an die Agenten gesendet . e) Der Agent nimmt das Perzept entgegen und leitet es, wenn er die Rechenkontrolle hat, an die entsprechende Komponente weiter.
4.4 Perzeptanfrage an das Spiel (Pull) - Fall 1
Will ein Agent Informationen über seine Umgebung abfragen, so muss er eine Perzeptanfrage starten. Die Anfrage wird im A- gent immer damit gestartet, wenn er ein leeres Perzept an den Weltserver sendet, das dieser dann füllen soll. Der weitere Da- tenfluss kann in drei Fälle unterteilt werden, je nachdem wie aktuell die Informationen sein müssen und welcher Perzepthand- ler die Informationen besorgt.
Im ersten Fall wird ein Perzepthandler verwendet, welcher die Weltrepräsentation als Cache für die im Perzept gesuchten Informationen benutzt. Des Weiteren sind in diesem Fall die Informationen in der Weltrepräsentation gültig. Der Datenfluss läuft dann wie in Fig. 4-4 schematisch dargestellt ab: a) Der Agent A legt ein leeres Perzept an und sendet dies ü- ber den Weltserver an den Perzeptmanager . b) Der Perzeptmanager bekommt nun die Rechenkontrolle für den Schritt FetchData. Er leitet das leere Perzept an den Perzepthandler weiter, indem er ebenfalls beim Perzepthandler die Methode FetchData ausführt. c) Der Perzepthandler stellt nun eine Anfrage (Request) an die Weltrepräsentation für die benötigten Daten im Perzept. Dabei dürfen die in der Weltrepräsentation gespeicherten Daten ein gewisses Alter nicht überschreiten. d) Die Weltrepräsentation liefert in diesem Fall gültig Daten zurück (Reply) . e) Der Perzepthandler hat nun alle Informationen gesammelt.
Da die Daten in der Weltrepräsentation den geforderten Daten in dem Perzepten entsprechen (KI interne Daten) , werden diese Daten bereits jetzt in das Perzept geschrieben. Der Perzepthandler hat dann den Schritt FetchData beendet und gibt das Perzept zurück an den Perzeptmanager . f) Bekommt danach der Perzeptmanager die Rechenkontrolle für den Schritt ProcessData, dann führt er den Perzepthandler mit der Methode ProcessData aus . g) Der Perzepthandler hat nun die Möglichkeit die zuvor hinterlegten Daten im Perzept nachzubearbeiten. Hat er dies erledigt, so sendet er das gefüllte Perzept zurück an den Agenten A h) Nachdem der Agent A Rechenzeit zugewiesen bekommt, nimmt er das Perzept aus seiner InQueue und sendet es an die Komponente, welche zuvor die Anfrage gesendet hat.
4.5 Perzeptanfrage an das Spiel (Pull) - Fall 2 Der zweite Fall unterscheidet sich vom ersten Fall darin, dass die Weltrepräsentation in Punkt d) aus Fall 1 keine gültigen Daten zurückliefern kann. Der Ablauf ändert sich danach wie in Fig. 4-5 schematisch dargestellt: a) Der Perzepthandler bekommt keine gültigen Daten von der Weltrepräsentation und stellt deshalb eine Anfrage (Data-
Request) an die Spiel -Engine über das KI-Interface . b) Die Spiel-Engine füllt das DataRequest mit den geforderten Daten und gibt das DataRequest über das KI -Interface zurück an den Perzepthandler. c) Der Perzepthandler hat nun alle notwendigen Informationen gesammelt und gibt das Perzept zusammen mit dem DataRequest zurück an den Perzeptmanager. Er führt keine Bearbeitungsschritte auf dem DataRequest durch, da er sich im Schritt FetchData befindet. d) Bekommt der Perzeptmanager dann irgendwann die Rechenkontrolle für den Schritt ProcessData, so führt er beim Perzepthandler die Methode ProcessData aus, und übergibt da- bei das Perzept und die zuvor gesammelten Daten in Form der DataRequests . e) Der Perzepthandler bearbeitet nun die Daten aus dem Data- request und füllt damit das Perzept. Zusätzlich führt er ein Update bei der Weltrepräsentation aus, damit er beim nächsten mal wieder aktuelle Informationen der Weltrepräsentation hat. Danach sendet er das gefüllte Perzept zurück an den Agenten. f) Nachdem der Agent A Rechenzeit zugewiesen bekommt, nimmt er das Perzept aus seiner InQueue und sendet es an die
Komponente, welche zuvor die Anfrage gesendet hat.
4.6 Perzeptanfrage an das Spiel (Pull) - Fall 3
Der dritte Fall tritt ein, wenn die angeforderten Daten im- mer so aktuell sein müssen (z.B.: die aktuelle Position des A- gent für die Navigation) , dass es sich nicht lohnt Daten in der Weltrepräsentation zwischenzuspeichern. Die Anfrage und das Update der Weltrepräsentation fallen deshalb in diesem Schritt komplett weg. Der Datenfluss läuft dann wie in Fig. 4-6 schema- tisch dargestellt: a) Der Agent A legt ein leeres Perzept an und sendet dies ü- ber den Weltserver an den Perzeptmanager . b) Der Perzeptmanager bekommt nun die Rechenkontrolle für den Schritt FetchData. Er leitet das leere Perzept an den Per- zepthandler weiter, indem er ebenfalls beim Perzepthandler die Methode FetchData ausführt. c) Der Perzepthandler stellt über das KI-Interface direkt eine Anfrage (DataRequest ) an die Spiel -Engine . d) Die Spiel Engine füllt das DataRequest mit den geforderten Daten und gibt das DataRequest über das KI -Interface zurück an den Perzepthandler. e) Der Perzepthandler hat nun alle notwendigen Informationen gesammelt und gibt das Perzept zusammen mit dem DataRe- quest zurück an den Perzeptmanager . Er führt keine Bearbeitungsschritte auf dem DataRequest durch, da er sich im Schritt FetchData befindet. f) Bekommt der Perzeptmanager dann irgendwann die Rechenkon- trolle für den Schritt ProcessData, so führt er beim Per- zepthandler die Methode ProcessData aus, und übergibt dabei das Perzept und die zuvor gesammelten Daten in Form der DataRequests . g) Der Perzepthandler bearbeitet nun die Daten aus dem Data- request und füllt damit das Perzept. Danach sendet er das gefüllte Perzept zurück an den Agenten. h) Nachdem der Agent A Rechenzeit zugewiesen bekommt, nimmt er das Perzept aus seiner InQueue und sendet es an die Komponente, welche zuvor die Anfrage gesendet hat.
5 Rechenzeitkontrolle
Die Rechenzeitkontrolle innerhalb der KI-Engine verteilt die zur Verfügung stehende Rechenzeit an die verschiedenen Komponenten. Dazu wird vom Weltserver die zur Verfügung stehende Re- chenzeit an die verschiedenen Manager und an die Agenten verteilt. Des Weiteren hat jeder Agent eine rudimentäre Rechenzeitkontrolle für seine internen Komponenten. Wir unterscheiden deshalb die globale Rechenzeitkontrolle und die lokale Rechenzeitkontrolle innerhalb der Agenten.
5.1 Globale Rechenzeitkontrolle
Die globale Rechenzeitkontrolle verteilt die Rechenzeit an Hauptkomponenten, wie die Manager innerhalb des WeltServers und die einzelnen Agenten. Um der steigenden Parallelisierung von Rechenoperationen gerecht zu werden, haben wir zwei verschiedene Modelle für die Rechenzeitkontrolle. Ein Modell ist für die Verwendung in Singlethreaded Anwendungen ausgelegt und das andere Modell für die Verwendung in Multithreaded Anwendungen, damit ein evtl. zur Verfügung stehender zweiter CPU-Kern genutzt werden kann.
5.1.1 Singlethread Umgebung Wir haben zu Beginn gesehen, dass jeder Manager innerhalb des Weltservers mit Eingangsqueues ausgestattet ist, ebenso wie einzelne Agenten. In einer Singlethreaded Anwendung ist es für die gesamte Verzögerung, die durch die KI-Engine erzeugt wird, egal, in welcher Reihenfolge wir den Komponenten die Rechenkon- trolle übergeben. Wir müssen immer alle Komponenten ausführen, damit ein korrekter Datenfluss zustande kommt. Deshalb wollen wir die Rechenzeit so verteilen, dass die Latenzen zwischen Aktionen und Effekten minimiert werden.
Aus den Abhängigkeiten zwischen Aktionen, Events und Perzep- te (z.B. Aktionen können Sprechakte enthalten und sind dann E- vents) ergibt sich die Rechenzeitverteilung wie in Fig. 5-1 gezeigt. Das Spiel ruft beim KI -Interface die Update Methode auf. In dieser Methode werden dann die verschiedenen Komponenten der KI-Engine in folgender Reihenfolge ausgeführt: 1. Action-Manager : Der Actionmanager sendet alle bei ihm eingetroffenen Aktionen über die Actionhandler in das Spiel.
2. Event-Manager : Der Eventmanager sendet bei ihm eingegangene Events an die Agenten weiter. Da wir vor dem Eventmanager bereits den Actionmanager ausgeführt haben, sind unter den Events auch Sprechakte, die in diesem Frame erst in das Spiel gesendet wurden.
3. Percept-Manager FetchData: Der Perzeptmanager führt für alle bei ihm eingegangenen Perzepte den FetchData Schritt bei den jeweiligen Perzepthandlern durch. 4. Percept-Manager ProcessData: Da wir in einer Singlethreaded Anwendung sind, wird als nächster Schritt für alle Perzepte im Perzeptmanager der ProcessData Schritt ausgeführt. Damit sind dann die Perzepte abgearbeitet. 5. KI-Scheduler + Agent-Scheduler : Als nächstes gibt es einen iterierten Wechsel zwischen dem KI-Scheduler, der einem ganzen Agenten Rechenzeit zuweist, und dem Agent- Scheduler, welcher den einzelnen Komponenten innerhalb ei- nes Agenten Rechenzeit zuweist. Zuerst bekommt der KI- Scheduler die restliche Zeit der KI-Engine und verteilt diese an die einzelnen Agenten. Hier können alle Agenten Rechenzeit bekommen oder nur ein Teil, wenn zu wenig Rechenzeit zur Verfügung steht. Durch ein Roundrobin Verfah- ren bekommen dann im nächsten Frame die anderen Agenten Rechenzeit. Der Agent-Scheduler verteilt die Gesamtzeit für einen Agenten auf die drei Hauptkomponenten im Agenten.
Es wird also die komplette KI im Game-Thread ausgeführt.
5.1.2 Multithread Umgebung
In modernen Rechensystemen ist ein starker Trend zur Paral- lelisierung der Verarbeitung zu erkennen. Die KI-Engine wurde deshalb so designed, dass sie auch in der Lage ist, parallel zum eigentlich Spiel Threads zu verarbeitenFür Multithreading kommt man nicht ohne eine Synchronisierung der verschiedenen Threads aus. Damit durch das Synchronisieren möglichst wenig Rechenzeit verloren geht, werden die Komponenten in einer von Single-Threaded Anwendungen abweichender Reihenfolge aufgeru- fen, damit die Berechnungen während der Synchronisierung auf den reinen Datenaustausch minimiert werden.
In Fig. 5-2 kann man den Update Verlauf für die KI-Engine in einer Multithread Anwendung erkennen. Das Spiel führt über das KI-Interface die Sync (Update) Funktion der KI-Engine aus. Die- se Sync Methode wartet nun bis der KI-Thread seine Berechnungen für einen Frame abgeschlossen hat. Danach werden, durch das Ausführen des Actionmanagers , die im Actionmanager gespeicherten Aktionen in das Spiel gesendet. Anschließend führt die Sync Methode noch beim Perzept -Manager den FetchData Schritt aus, damit Anfragen von den Agenten an das Spiel befriedigt werden können. Damit sind alle Daten an das Spiel gesendet, bzw. aus dem Spiel entnommen. Die beiden Threads können sich nun trennen und getrennte Wege gehen bis zum nächsten Frame, wenn der Ga- me-Thread erneut die Sync Methode des KI-Interface ausführt.
Es wird also nur die Synchronisation vom Game-Thread ausgeführt, während der Rest der Berechnung in einem extra KI-Thread ausgeführt werden. Im KI-Thread bekommen nun noch die restlichen Komponenten Rechenzeit. Keine dieser Komponenten benötigt direkten Zugriff auf das Spiel, welches seinerseits Berechnungen für die Darstellung des Spiels ausführt. Der KI-Thread führt alle Updates aus, und vergibt ebenfalls, wie in der Singlethread Anwendung, Rechenzeit an die einzelnen Agenten. Wurde alle Rechenzeit aufgebraucht, so wartet der KI-Thread bis das Spiel wieder einen Sync ausführt.
Dem KI-Thread wird, wie in der Singlethread Anwendung, Rechenzeit zugewiesen. Dies bewirkt, dass das Spiel weiterhin die Kontrolle über die KI-Engine besitzt. Sollte z. B. der KI- Thread keine richtige Rechenleistung vom Betriebssystem zugeteilt bekommen, weil das Spiel auf einer Single-Core CPU oder einer CPU mit Hyperthreading läuft, dann muss es trotzdem möglich sein, dass die KI ausreichend Rechenzeit bekommt. Würde die KI-Engine nur solange Rechnen bis der Spielthread wieder einen Sync durchführt, kann es sein, dass die KI-Engine noch keine Berechnungen durchgeführt hat. Durch die zugewiesene Rechenzeit in der Sync Methode wird somit sichergestellt, dass die KI-Engine ein Minimum an Rechenzeit erhält. Der Spielthread muss auf den KI-Thread warten; damit steht alle Rechenleistung der CPU dem KI-Thread zur Verfügung.
Da während der Zustandsberechnung im Spiel weitere Events anfallen können, wurde die InQueue des Eventmanagers threadsafe programmiert. So kann nun, während der Spielthread und der KI- Thread getrennte Wege gehen, der Spielthread Events in die KI- Engine senden, ohne einen Fehler zu erzeugen.
5.2 Lokale Rechenzeitkontrolle
Die lokale Rechenzeitkontrolle bezieht sich auf einzelne A- genten. Jeder Agent hat seine eigene kleine Rechenzeitkontrolle. Innerhalb des Agenten gibt es zwei Komponenten, die für die Rechenzeitverteilung verantwortlich sind. Dies ist zum einen der Komponenten-Scheduler und zum andere die Scheduler-FSM.
5.2.1 Komponenten Scheduler
Da wir im Agenten nur drei verschiedene Komponenten (Kooperation, Lokale Planung, Reaktivebene) haben, kann der Komponen- ten-Scheduler mit einer statischen Anzahl von Objekten arbeiten. Jede Komponente hat eine Priorität, anhand der festgelegt wird, ob eine Komponente viel oder wenig Rechenzeit bekommt. Die Priorität ist dabei abhängig von der Situation, in der sich der Agent momentan befindet. Befindet sich der Agent momentan in einer Planungsphase, so bekommt die Planungsebene mehr Rechenzeit als die Reaktiv- und Kooperationsebenen. Wird der A- gent aber während der Planung unter Beschuss genommen, so muss der Reaktivebene schlagartig mehr Rechenzeit zugewiesen werden. Diese Aufgabe übernimmt die Scheduler-FSM.
5.2.2 Scheduler-FSM
Die Scheduler-FSM (Finite State Machine) ist eine einfache Zustandsmaschine, mit vordefinierten Zuständen. Diese Zustände beschreiben häufige Gedankenzustände wie: • Neutral: Der Agent befindet sich in einem neutralen Zustand. Dies liegt vor, wenn keine Bedrohung vorliegt und der Agent einfach von A nach B geht. • Think: Der Agent muss vermehrt nachdenken. Dies ist der Fall, wenn er einen neuen Plan erarbeitet.
• Panic: Dieser Zustand tritt ein, wenn sich der Agent in einer bedrohlichen Situation befindet, z. B. wenn er unter Beschuss ist.
• Communicate: Dieser Zustand beschreibt den Agenten, wenn er kommuniziert.
Für jeden dieser Zustände kann der Designer festlegen, welche Prioritäten die Komponenten im Agenten erhalten. Tritt nun ein Zustandswechsel ein, so setzt die Scheduler-FSM beim Agen- ten-Scheduler die neuen Prioritäten für diesen Zustand. In dem Zustand "Panic" könnte z. B. die Reaktivebene die größte Priorität erhalten. Die Reaktivebene erhält damit übermäßig viel Rechenzeit, und somit kann der Agent der Bedrohung entkommen. Die einzelnen Zustände werden direkt von den jeweiligen Komponenten geändert. Damit verhindert wird, dass die Komponenten sich gegenseitig die Rechenzeit streitig machen, werden den jeweiligen Zuständen Prioritäten zugewiesen. Diese Priorität sollte man nicht mit den Prioritäten verwechseln, welche in ei- nem Zustand den jeweiligen Komponenten im Agenten zugewiesen werden. Die Scheduler-FSM kann immer nur von einem Zustand niedrigerer Priorität in einen Zustand höherer Priorität wechseln. Alleine die Komponente, die den höheren Zustand gewählt hat, kann diesen wieder in den Normalzustand zurücksetzen.
Liste der zitierten Literatur
[JPM99] Jörg P. Müller: "The Design of Intelligent Agents . A Layered Approach" , Springer Verlag, Berlin (Februar 1999)

Claims

Patentansprüche
1. Recheneinheit zum Implementieren eines Multiagenten- Systems mit : a) Mitteln zum Implementieren einer ersten Ebene, die ein System darstellt; b) Mitteln zum Implementieren einer zweiten Ebene, die eine abstrakte, auf Konzepte reduzierte Repräsentation des Systems der ersten Ebene aufweist; c) Mitteln zum Implementieren einer dritten Ebene, die Mittel zum Implementieren der Agenten des Multiagenten-Systems aufweist ; d) einer Schnittstelle zur Kommunikation zwischen der ersten und der zweiten Ebene; und mit e) einer Schnittstelle zur Kommunikation zwischen der zweiten und der dritten Ebene.
2. Recheneinheit nach dem vorhergehenden Anspruch, dadurch gekennzeichnet, dass die Schnittstelle zur Kommunikation zwischen der ersten und der zweiten Ebene eine Struktur aufweist, die der Struktur einer Schnittstelle zwischen der ersten Ebene und einem menschlichen Bediener entspricht.
3. Recheneinheit nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Schnittstelle zur Kommunikation zwischen der zweiten und der dritten Ebene über Aktionen und Perzepte erfolgt.
4. Recheneinheit nach dem vorhergehenden Anspruch, dadurch gekennzeichnet. dass einem Agent mindestens ein vorgegebener virtueller Sensor zugeordnet ist; und dass die Perzepte dieses Agenten gemäß den jeweiligen Sensoren dieses Agenten gefiltert sind.
5. Recheneinheit zum Implementieren eines Multiagenten- Systems : a) wobei in einer ersten Ebene ein System vorhanden ist; wobei die Recheneinheit folgendes aufweist: b) Mittel zum Implementieren einer zweiten Ebene, die eine abstrakte, auf Konzepte reduzierte Repräsentation des Systems der ersten Ebene aufweist; c) Mittel zum Implementieren einer dritten Ebene, die Mittel zum Implementieren der Agenten des Multiagenten-Systems auf- weist; d) eine Schnittstelle zur Kommunikation zwischen der ersten und der zweiten Ebene; und mit e) eine Schnittstelle zur Kommunikation zwischen der zweiten und der dritten Ebene.
6. Simulator für ein Multiagenten-Systems mit: a) Mitteln zum Implementieren einer ersten Ebene, die ein System darstellt; b) Mitteln zum Implementieren einer zweiten Ebene, die eine abstrakte, auf Konzepte reduzierte Repräsentation des Systems der ersten Ebene aufweist; c) Mitteln zum Implementieren einer dritten Ebene, die Mittel zum Implementieren der Agenten des Multiagenten-Systems aufweist ; d) einer Schnittstelle zur Kommunikation zwischen der ersten und der zweiten Ebene; und mit e) einer Schnittstelle zur Kommunikation zwischen der zweiten und der dritten Ebene.
7. Architektur eines Computerprogramms zum Implementieren eines Multiagenten-Systems mit: a) einer ersten Ebene, die ein System darstellt; b) einer zweiten Ebene, die eine abstrakte, auf Konzepte reduzierte Repräsentation des Systems der ersten Ebene aufweist; c) einer dritten Ebene, die Mittel zum Implementieren der Agenten des Multiagenten-Systems aufweist; d) einer Schnittstelle zur Kommunikation zwischen der ersten und der zweiten Ebene; und mit e) einer Schnittstelle zur Kommunikation zwischen der zweiten und der dritten Ebene .
8. Architektur eines Computerprogramms zum Implementieren eines Multiagenten-Systems: a) wobei in einer ersten Ebene ein System vorhanden ist; wobei die Architektur folgendes aufweist : b) eine zweite Ebene, die eine abstrakte, auf Konzepte reduzierte Repräsentation des Systems der ersten Ebene aufweist; c) eine dritte Ebene, die Mittel zum Implementieren der A- genten des Multiagenten-Systems aufweist; d) eine Schnittstelle zur Kommunikation zwischen der ersten und der zweiten Ebene; und mit e) eine Schnittstelle zur Kommunikation zwischen der zweiten und der dritten Ebene.
9. Middleware für die Entwicklung eines Computerprogramms zum Implementieren eines Multiagenten-Systems: a) wobei das Computerprogramm in einer ersten Ebene ein Sys- tem simuliert; b) wobei die Middleware eine zweite Ebene aufweist, die eine abstrakte, auf Konzepte reduzierte Repräsentation des Systems der ersten Ebene aufweist; c) wobei die Middleware eine dritte Ebene aufweist, die Mittel zum Implementieren der Agenten des Multiagenten-Systems aufweist ; d) wobei die Middleware eine Schnittstelle zur Kommunikation zwischen der ersten und der zweiten Ebene aufweist; und e) wobei die Middleware einer Schnittstelle zur Kommunikation zwischen der zweiten und der dritten Ebene aufweist.
10. Verfahren zum Implementieren eines Multiagenten-Systems: a) wobei eine erste Ebene simuliert wird, die ein System darstellt ; b) wobei eine zweite Ebene simuliert wird, die eine abstrakte, auf Konzepte reduzierte Repräsentation des Systems der ersten Ebene aufweist; c) wobei eine dritte Ebene simuliert wird, die Mittel zum Implementieren der Agenten des Multiagenten-Systems aufweist; d) wobei Informationen zwischen der ersten und der zweiten Ebene ausgetauscht werden; und e) wobei Informationen zwischen der zweiten und der dritten Ebene ausgetauscht werden.
11. Computerprogramm, dadurch gekennzeichnet, dass es bei Ablauf auf einer Recheneinheit, einem MikroController, DSP, FPGA oder Computer oder auf einer Mehrzahl davon in einem Netz- werk das Verfahren nach dem Verfahrensanspruch ausführt.
12. Computerprogramm mit Programmcode-Mitteln, um ein Verfahren gemäß dem Verfahrensanspruch durchzuführen, wenn das Computerprogramm auf einer Recheneinheit, einem Mikrocontrol- ler, DSP, FPGA oder Computer oder auf einer Mehrzahl davon in einem Netzwerk ausgeführt wird.
13. Computerprogramm mit Programmcode-Mitteln gemäß dem vorhergehenden Anspruch, die auf einem computerlesbaren Datenträger gespeichert sind.
14. Datenträger, auf dem eine Datenstruktur gespeichert ist, die nach einem Laden in einen Arbeits- und/oder Hauptspeicher einer Recheneinheit, eines Mikrocontrollers, DSPs, FPGAs oder Computers oder einer Mehrzahl davon in einem Netzwerk das Verfahren nach dem Verfahrensanspruch ausführt.
15. Computerprogramm-Produkt mit auf einem maschinenlesbaren Träger gespeicherten Programmcode-Mitteln, um alle Schritte gemäß dem Verfahrensanspruch durchzuführen, wenn das Programm auf einer Recheneinheit, einem MikroController, DSP, FPGA oder Com- puter oder auf einer Mehrzahl davon in einem Netzwerk ausgeführt wird.
16. Moduliertes Datensignal, welches von einer Recheneinheit, einem Mikrocontroller, DSP, FPGA oder Computer oder von einer Mehrzahl davon in einem Netzwerk ausführbare Instruktionen zum Ausführen eines Verfahrens nach dem Verfahrensanspruch enthält .
EP06776496A 2005-07-28 2006-07-28 Generische ki-architektur für ein multiagenten-system Withdrawn EP1915675A2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102005035903A DE102005035903A1 (de) 2005-07-28 2005-07-28 Generische KI-Architektur für ein Multiagenten-System
PCT/EP2006/007527 WO2007012499A2 (de) 2005-07-28 2006-07-28 Generische ki-architektur für ein multiagenten-system

Publications (1)

Publication Number Publication Date
EP1915675A2 true EP1915675A2 (de) 2008-04-30

Family

ID=37669858

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06776496A Withdrawn EP1915675A2 (de) 2005-07-28 2006-07-28 Generische ki-architektur für ein multiagenten-system

Country Status (4)

Country Link
US (1) US8095496B2 (de)
EP (1) EP1915675A2 (de)
DE (1) DE102005035903A1 (de)
WO (1) WO2007012499A2 (de)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090253517A1 (en) * 2008-04-04 2009-10-08 Zipzapplay, Inc. Open game engine and marketplace with associated game editing and creation tools
US8401992B2 (en) 2009-02-06 2013-03-19 IT Actual, Sdn. Bhd. Computing platform based on a hierarchy of nested data structures
FR2974217A1 (fr) * 2011-04-12 2012-10-19 Thomson Licensing Procede d’estimation d’une information representative d’une hauteur
US10664766B2 (en) 2016-01-27 2020-05-26 Bonsai AI, Inc. Graphical user interface to an artificial intelligence engine utilized to generate one or more trained artificial intelligence models
US11775850B2 (en) 2016-01-27 2023-10-03 Microsoft Technology Licensing, Llc Artificial intelligence engine having various algorithms to build different concepts contained within a same AI model
US11841789B2 (en) 2016-01-27 2023-12-12 Microsoft Technology Licensing, Llc Visual aids for debugging
US11868896B2 (en) 2016-01-27 2024-01-09 Microsoft Technology Licensing, Llc Interface for working with simulations on premises
US11120299B2 (en) 2016-01-27 2021-09-14 Microsoft Technology Licensing, Llc Installation and operation of different processes of an AI engine adapted to different configurations of hardware located on-premises and in hybrid environments
US11763143B2 (en) 2017-04-19 2023-09-19 AIBrain Corporation Adding deep learning based AI control
US11429406B1 (en) 2021-03-08 2022-08-30 Bank Of America Corporation System for implementing auto didactic content generation using reinforcement learning
DE102022206664A1 (de) 2022-06-30 2024-01-04 Siemens Aktiengesellschaft Verfahren zur Simulation einer Besprechung mittels einer elektronischen Recheneinrichtung, Computerprogrammprodukt, computerlesbares Speichermedium sowie elektronische Recheneinrichtung

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6767287B1 (en) * 2000-03-16 2004-07-27 Sony Computer Entertainment America Inc. Computer system and method for implementing a virtual reality environment for a multi-player game
US7089592B2 (en) * 2001-03-15 2006-08-08 Brighterion, Inc. Systems and methods for dynamic detection and prevention of electronic fraud
US7899915B2 (en) * 2002-05-10 2011-03-01 Richard Reisman Method and apparatus for browsing using multiple coordinated device sets
US20050071306A1 (en) * 2003-02-05 2005-03-31 Paul Kruszewski Method and system for on-screen animation of digital objects or characters
GB0306875D0 (en) * 2003-03-25 2003-04-30 British Telecomm Apparatus and method for generating behavior in an object
US7788109B2 (en) * 2004-04-03 2010-08-31 Altusys Corp. Method and apparatus for context-sensitive event correlation with external control in situation-based management
US7698270B2 (en) * 2004-12-29 2010-04-13 Baynote, Inc. Method and apparatus for identifying, extracting, capturing, and leveraging expertise and knowledge
US7693836B2 (en) * 2005-12-27 2010-04-06 Baynote, Inc. Method and apparatus for determining peer groups based upon observed usage patterns
US20070174429A1 (en) * 2006-01-24 2007-07-26 Citrix Systems, Inc. Methods and servers for establishing a connection between a client system and a virtual machine hosting a requested computing environment
US7801644B2 (en) * 2006-07-05 2010-09-21 Battelle Energy Alliance, Llc Generic robot architecture
US7668621B2 (en) * 2006-07-05 2010-02-23 The United States Of America As Represented By The United States Department Of Energy Robotic guarded motion system and method

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2007012499A2 *

Also Published As

Publication number Publication date
WO2007012499A3 (de) 2008-07-10
WO2007012499A2 (de) 2007-02-01
DE102005035903A1 (de) 2007-02-08
US8095496B2 (en) 2012-01-10
US20090204563A1 (en) 2009-08-13

Similar Documents

Publication Publication Date Title
EP1915675A2 (de) Generische ki-architektur für ein multiagenten-system
DE69635337T2 (de) Erweiterbares und austauschbares system von netzwerkkomponenten
DE69630329T2 (de) Verfahren zur Verwaltung des Deaktivierens und Ausschaltens eines Servers
EP1461697A2 (de) SYSTEM UND VERFAHREN ZUR KOMMUNIKATION ZWISCHEN SOFTWAREAPPLIKATIONEN&amp;comma; INSBESONDERE MES&amp;minus;APPLIKATIONEN
DE19955004A1 (de) Ableitung und Ausführung von Workload-Manager-Enklaven aus Workflows
DE102006051189A1 (de) Verfahren und System zum Ausführen und Konfigurieren von Applikationen abhängig von einer Einsatzumgebung
DE10206902A1 (de) Engineeringverfahren und Engineeringsystem für industrielle Automatisierungssysteme
DE112011100094T5 (de) Verfahren und System zum Abstrahieren eines auf nichtfunktionalen Anforderungen beruhenden Einsatzes von virtuellen Maschinen
EP2648094B1 (de) Verfahren und system zum erzeugen eines quellcodes für ein computerprogramm zur ausführung und simulation eines prozesses
DE102014016968A1 (de) Ein Computersystem von einer Künstlichen Intelligenz von einem Cyborg oder einem Android, wobei eine aufgenommene Signal-Reaktion des Computersystems von der Künstlichen Intelligenz von dem Cyborg oder dem Android, eine entsprechende Assoziation des Computersystems von der Künstlichen Intelligenz von dem Cyborg oder dem Android, und ein entsprechender Gedanke des Computersystems von der Künstlichen Intelligenz von dem Cyborg oder dem Android in dem Computersystem physisch gebaut werden, und ein Arbeitsverfahren von dem Computersystem von der Künstlichen Intelligenz von dem Cyborg oder dem Android
EP1516250A2 (de) Softwareapplikation, softwarearchitektur und verfahren zur erstellung von softwareapplikationen, insbesondere für mes-systeme
DE10161115A1 (de) Transformation von Objektbäumen, insbesondere in MES-Systemen
EP1497714A2 (de) System und verfahren zur projektierung von transformationen von objektb umen
DE102006051188A1 (de) Flexibles Verschaltungssystem
WO2008148238A1 (de) Fernbedienung eines browser-programms
Goel et al. GAIA: A CAD-like environment for designing game-playing agents
DE102011000185A1 (de) System und Verfahren zum Erzeugen eines Quellcodes für ein Computerprogramm
DE102017121757A1 (de) Verfahren zur Planung und Steuerung einer logistischen Prozesskette in der Agrarwirtschaft
DE102005018864B4 (de) Verfahren und System zum Erzeugen eines Quellcodes für ein Computerprogramm
DE102021201212A1 (de) Verfahren zum Steuern einer Mehrzahl an Fahrfunktionen in einem automatisierten oder autonomen Fahrzeug
DE102005010405B4 (de) Systemanordnung und Verfahren zur automatisierten Applikationsentwicklung mit Benutzerführung
McQuillan A survey of behaviour trees and their applications for game AI
Klink et al. A service-oriented information system for collaborative research and doctoral education
EP1533940A1 (de) Transformation Function eines TMN Systems
WO2009106638A1 (de) Verfahren zur steuerung einer interaktion zwischen modulen einer service-orientierten komponente sowie service-orientierte komponente

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20080124

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK RS

R17D Deferred search report published (corrected)

Effective date: 20080710

RIC1 Information provided on ipc code assigned before grant

Ipc: G06N 5/04 20060101AFI20080829BHEP

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20140201