AI Wizdom 3 / p. 321
Case Based Reasoning = Analogy + (Case) Adaptation + (Knowledge) Retrieval + Learning
The approach is to store and reuse traces of how those solutions are derived. By capturing and replaying the reasoning trace involved in selecting problem-solving operators, rather than the problem solving steps themselves, the derivational analogy approach facilitates application of stored traces of processing to wider class of problems. Systems may also reuse reasoning traces for introspective reasoning and learning.
A problem description was formed and used to select a relevant case. However, the indices needed are inextricably tied to the contents of the case library (which may change). Consequently, CBR research is also investigating the role of bottom-up influences to guide retrieval, favoring features that are useful to discriminate between cases in memory.
Developing case adaptation criteria is a central open challenge for CBR. The case adaptation process in CBR systems is usually done by rule-based systems. Consequently, correct case adaptation requires that those rules capture both a theory of case adaptation, and the needed aspects of the domain theory to carry out changes. As a result, developers defining adaptation rules must re-confront the knowledge acquisition problem for rule-based systems. Additional problem may arise because available cases can lack the internal structure needed for effective adaptation. Nevertheless, difficulties with case adaptation have led many CBR systems to simply dispense with adaptation, replacing retrieve-evaluate-adapt cycle with retrieve and propose systems. Such systems exploit the memory process developed in CBR research, while relying on a human user to adapt and evolve solutions.
One issue in similarity assessment is how to determine the right features to compare. Decisions about which features are important are often based on explanations of feature relevance. Another problem what for some tasks, input problem descriptions are not sufficient to determine the similarity of old and new situations.
Building AI isn’t easy task itself, so here will come break down to small specific techniques and methods...
Expect more to come!
Types: Event-driven FSM AI DSL (?) Coroutines & lazy multitasking
Blackboard system for inter-agent communication and contributing toward the partial solution.
Solving resource allocation problem (extend one to one problem)
— high level - strategy & economics manager —-
— city management - builder —
rules based decision maker ( sort of expert system )
target(params): requirements > action; example: hire(unit_lvl1,num): require( dwelling_lvl1, resources_to_hire( unit_lvl1, num ), availability( unit_lvl1, num ) ) » hire ..
— hero management - tactician —-
Planning and realistic micromanagement 1) in strategy games is troublesome but definitely doable. Lets look in details:
Imainge we have a limited set of top-level request or tasks which AI might need to acomplish. No matter how difficult the tasks they could be decribed in terms of requirements and results or inputs and outputs respectively.
| Task | Acquire ‘X’ Peasants |
|---|---|
| Requires | X*5 Gold |
| Requires | Peasant Hut |
| Result | X Peasants |
| Result | -X*5 Gold |
| Task | Build Peasant Hut |
|---|---|
| Requires | 20 Gold |
| Requires | 10 Wood |
| Result | Peasant Hut |
| Result | -20 Gold |
| Result | -10 Wood |
| Task | Exchange Wood for Gold |
|---|---|
| Requires | X*2 Gold for wood |
| Requires | Black Market |
| Result | -X*2 Gold |
| Result | X Wood |
| Task | Build Black Market |
|---|---|
| Requires | 30 Gold |
| Result | Black Market built |
| Result | -30 Gold |
Accept surrender (supported): Enemies can become allies using during the game through various diplomacy mechanisms. Ask for directions (unsupported): A new command could ask neutral, newly aligned, or converted units to reveal portions of the map that they have seen. Attack (supported): Clicking on a target when a unit is selected causes it to attack. Befriend civilian (supported): Unaligned units at the beginning of a game become allied when a unit approaches them. Block pathway (supported): Villagers can construct walls to block the travel of units. Capture resources (supported): Monks can convert enemy units including some buildings. Defend (supported): Military units can be commanded to adopt a defensive stance. Destroy planning records (unsupported): A new technology of town centers or castles should disable an opponent’s spy technology. Destroy/disable enemy resources (supported): Enemy buildings and special units can be attacked and destroyed. Destroy/disable own resources (supported): A player’s units and buildings can be deleted. Distract enemy (unsupported): A new command for a military unit should cause enemy units in a defensive stance to move toward a specified location. Enlist spy (supported): Spies is a technology that reveals explored enemy territory. A more strategic implementation would create special spy units that could pass unnoticed in enemy territory, and could be enlisted as double agents. Flee/retreat (unsupported): A new combat stance should cause units to quickly move away from any enemy unit, perhaps at the cost of defensive strength. Gather war stories (unsupported): A new command should allow military units that have returned from battle to improve defensive technologies, or improve the ability of military units that they are grouped with. Move forces to location (supported): Clicking on a destination moves individual or groups of units. Patrol territory (supported): Military units can be commanded to patrol a specified territory. Pretend disorder (unsupported): A new combat stance should cause military units to move in unpredictable ways, possibly increasing their defensive strength. Pretend preparation (unsupported): A new combat stance should cause military units to appear to be preparing an attack, possibly increasing their defensive strength. Pretend to attack (unsupported): A new combat stance should cause military units to appear as if they are attacking, possibly increasing their defensive strength. Prohibit emissary movement (supported): Gates can be ordered locked and trade carts & ships can be commanded not to travel. Provide false information (unsupported): A new technology for town centers or castles should cause opponents with spy technology to report incorrect map information. Siege stronghold (supported): Siege weapons (and other military units) can attack enemy buildings. Signal own forces (unsupported): While the game allows signaling of allied forces in multiplayer games, it should also allow the triggering of units waiting for a signal (see Wait for signal, below). Supply forces (unsupported): A new command for trade carts should cause them to move between town centers and distant military units or siege weapons, replenishing their strength upon each arrival. Taunt opponent (supported): Preset taunts can be sent to other teammates & opponents using the chat interface, although it is unclear if computer players react to these taunts. Wait for signal (unsupported): A new command for a military unit should delay a specified command until a signal is received (see Signal own forces, above).
Defined as
A B C D 3 x x 1 [a x x x 5 [b 1 2 3 4 [c 1 2 x 4 [d order: # b switch D case 5: ret "b" case 1: if A == 3 ret "a" brk case 4: if ( A == 1 && B == 2 ) if ( C == 3 ) ret "c" else ret "d" ret ""