FormulaAIandAdaptation - Revision history

Alesis-Novik: /* Timeline */

2008-04-12T00:28:07Z

‎Timeline

Alesis-Novik: /* The Knowledge Base */

2008-04-12T00:25:33Z

‎The Knowledge Base

Alesis-Novik: /* Details */

2008-04-08T01:35:06Z

‎Details

Alesis-Novik: /* Timeline */

2008-04-08T01:27:03Z

‎Timeline

Alesis-Novik: /* The Knowledge Base */

2008-04-08T01:23:37Z

‎The Knowledge Base

Alesis-Novik: /* Commits */

2008-04-06T20:50:12Z

‎Commits

Alesis-Novik at 21:27, 30 March 2008

2008-03-30T21:27:36Z

Alesis-Novik at 17:38, 30 March 2008

2008-03-30T17:38:24Z

Alesis-Novik: /* Details */

2008-03-24T23:24:34Z

‎Details

Alesis-Novik: /* Details */

2008-03-20T22:00:24Z

‎Details

@@ Line 18: / Line 18: @@
 ==Timeline==
-*The first part would be to integrate the knowledge base to the AI, since it would need grouping and connections. This part could be done prior to the beginning of the official coding start.
+*Until May 26: The first part would be to integrate the knowledge base to the AI, since it would need grouping and connections.
-*The second part would be to write a case base so it could store plans and create new plans, along with the probability of success. Since this would include the most communication with players, I believe getting this working and filling it would take most of the time until midterm.
+*May 26 - July 7: The second part would be to write a case base so it could store plans and create new plans, along with the probability of success. Since this would include the most communication with players, I believe getting this working and filling it would take most of the time until midterm.
-*The third part would be to write effective evaluation functions along with a probability engine to calculate success rate of possible plans. This may be done by using the Monte Carlo method (it is used when there are large arrays of data and discreet calculations are impossible). After writing this, the testing would begin, trying to see how the new AI scales with the old one.
+*July 7 - August 18: The third part would be to write effective evaluation functions along with a probability engine to calculate success rate of possible plans. This may be done by using the Monte Carlo method (it is used when there are large arrays of data and discreet calculations are impossible). After writing this, the testing would begin, trying to see how the new AI scales with the old one.
 ==Overall==

@@ Line 10: / Line 10: @@
 This would be the plan and strategy base, updated on each action taken. The base plans and tactics would be inserted from user experience. The others the AI would formulate itself, with probability of success. After setting the major goal, such as defence or attack, the AI could use genetic algorithms to evaluate or create the best plan. Since the variations are too great, there would be an iteration limit set (this could also relate to difficulty: the harder the opponent, the more iterations).
 ===The Knowledge Base===
-This would hold the information on every aspect of the game and would be updated with user created content as available. For example it would know that some two units are both archers, along with their statistics. This is quite straight forward: arrays of information on units (probably split into logical groups) with connections between (so we can select healers from elves or elves from healers, depending on how we sort them. The knowledge base would also hold information on terrain effects on units. After seeing the source, I would say that something as simple as a vector of simplified unit_stats would be able to hold the information on the units. There vectors could be grouped, making them specialized for certain unit groups, as I mentioned. The knowledge base would have information on the relations between those groups.
+This would hold the information on every aspect of the game and would be updated with user created content as available. For example it would know that some two units are both archers, along with their statistics. This is quite straight forward: arrays of information on units (probably split into logical groups) with connections between (so we can select healers from elves or elves from healers, depending on how we sort them. The knowledge base would also hold information on terrain effects on units. After seeing the source, I would say that something as simple as a vector of simplified unit_stats would be able to hold the information on the units. The information on units can be collected from the unit .cfg files, and accessed easily from any other AI class (most importantly the similarity engine). There vectors could be grouped, making them specialized for certain unit groups, as I mentioned. The knowledge base would have information on the relations between those groups.
 ===The Similarity Engine===
 This would compare the existing plans to the available resources and choose the best solution. For example, if we know that two fighters can defeat an enemy, it scales what are the chances of, lets say a fighter and a healer or two rangers. It wouldn't chose what looks closer, but what *looks  better* (lets say in this case, the two rangers). Simple evaluation function could look something like (unit.hitpoints/hitpoints_in_plan * i + unit.damage/damage_in_plan * j) where i and j would be based on priorities (to survive or to do more damage)

@@ Line 11: / Line 11: @@
 ===The Knowledge Base===
 This would hold the information on every aspect of the game and would be updated with user created content as available. For example it would know that some two units are both archers, along with their statistics. This is quite straight forward: arrays of information on units (probably split into logical groups) with connections between (so we can select healers from elves or elves from healers, depending on how we sort them. The knowledge base would also hold information on terrain effects on units. After seeing the source, I would say that something as simple as a vector of simplified unit_stats would be able to hold the information on the units. There vectors could be grouped, making them specialized for certain unit groups, as I mentioned. The knowledge base would have information on the relations between those groups.
 ===The Similarity Engine===
 This would compare the existing plans to the available resources and choose the best solution. For example, if we know that two fighters can defeat an enemy, it scales what are the chances of, lets say a fighter and a healer or two rangers. It wouldn't chose what looks closer, but what *looks  better* (lets say in this case, the two rangers). Simple evaluation function could look something like (unit.hitpoints/hitpoints_in_plan * i + unit.damage/damage_in_plan * j) where i and j would be based on priorities (to survive or to do more damage)
 ==Timeline==

@@ Line 16: / Line 16: @@
 ==Timeline==
-*The first part would be to integrate the knowledge base to the AI, since it would need grouping and connections.
+*The first part would be to integrate the knowledge base to the AI, since it would need grouping and connections. This part could be done prior to the beginning of the official coding start.
-*The second part would be to write a case base so it could store plans and create new plans, along with the probability of success.
+*The second part would be to write a case base so it could store plans and create new plans, along with the probability of success. Since this would include the most communication with players, I believe getting this working and filling it would take most of the time until midterm.
-*The third part would be to write effective evaluation functions along with a probability engine to calculate success rate of possible plans. This may be done by using the Monte Carlo method (it is used when there are large arrays of data and discreet calculations are impossible)
+*The third part would be to write effective evaluation functions along with a probability engine to calculate success rate of possible plans. This may be done by using the Monte Carlo method (it is used when there are large arrays of data and discreet calculations are impossible). After writing this, the testing would begin, trying to see how the new AI scales with the old one.
 ==Overall==

@@ Line 10: / Line 10: @@
 This would be the plan and strategy base, updated on each action taken. The base plans and tactics would be inserted from user experience. The others the AI would formulate itself, with probability of success. After setting the major goal, such as defence or attack, the AI could use genetic algorithms to evaluate or create the best plan. Since the variations are too great, there would be an iteration limit set (this could also relate to difficulty: the harder the opponent, the more iterations).
 ===The Knowledge Base===
-This would hold the information on every aspect of the game and would be updated with user created content as available. For example it would know that some two units are both archers, along with their statistics. This is quite straight forward: arrays of information on units (probably split into logical groups) with connections between (so we can select healers from elves or elves from healers, depending on how we sort them. The knowledge base would also hold information on terrain effects on units.
+This would hold the information on every aspect of the game and would be updated with user created content as available. For example it would know that some two units are both archers, along with their statistics. This is quite straight forward: arrays of information on units (probably split into logical groups) with connections between (so we can select healers from elves or elves from healers, depending on how we sort them. The knowledge base would also hold information on terrain effects on units. After seeing the source, I would say that something as simple as a vector of simplified unit_stats would be able to hold the information on the units. There vectors could be grouped, making them specialized for certain unit groups, as I mentioned. The knowledge base would have information on the relations between those groups.
 ===The Similarity Engine===
 This would compare the existing plans to the available resources and choose the best solution. For example, if we know that two fighters can defeat an enemy, it scales what are the chances of, lets say a fighter and a healer or two rangers. It wouldn't chose what looks closer, but what *looks  better* (lets say in this case, the two rangers). Simple evaluation function could look something like (unit.hitpoints/hitpoints_in_plan * i + unit.damage/damage_in_plan * j) where i and j would be based on priorities (to survive or to do more damage)

@@ Line 23: / Line 23: @@
 ==Commits==
-*An additional formula and functions in pathutil [http://svn.gna.org/viewcvs/wesnoth?rev=25349&view=rev]
+*An additional formula to get close enemies and functions in pathutil for close tiles selection[http://svn.gna.org/viewcvs/wesnoth?rev=25349&view=rev]
 ==Other==
 On a side note, I'd like to say that I am really interested in game development and would gladly continue working on Wesnoth after Google Summer of Code. Also, the reason why I can't contribute much now is that I have to attend the university and we are having some midterm exams, so I need to study a bit.
 [[Category:Summer of Code]]

@@ Line 6: / Line 6: @@
 ==Details==
-After the discussions about the AI on the IRC, I was reading up and thought about an, in my opinion, interesting approach to the problem. First of all, from playing the game and talking to other player (done before summer begins) we get the idea of tactics and ideas they use while playing. We also need to make the AI be able to add to the tactic and strategy base on its own considering the outcome of each move. Obviously, with the mass of the possible options in the game, the full base would never be completed, so we need to use another method to ensure the effect. The AI would not only have the information on the tactics, but a large base of environment relations (like how one unit scales with the other and the land effect on them). Based on the current case, the strategy and tactics base and the world information it would compare and scale how close to a successful plan it can get from the current state, a similarity engine, if you will (for example, if one powerful unit could defeat the enemy, and we have two weaker units, maybe their combined power can defeat the enemy too). This type of strategy is a valid option in a TBS AI development and was used in other games like Civilization.
+After the discussions about the AI on the IRC, I was reading up and thought about an, in my opinion, interesting approach to the problem. First of all, from playing the game and talking to other player (done before summer begins) we get the idea of tactics and ideas they use while playing. We also need to make the AI be able to add to the tactic and strategy base on its own considering the outcome of each move. Obviously, with the mass of the possible options in the game, the full base would never be completed, so we need to use another method to ensure the effect. The AI would not only have the information on the tactics, but a large base of environment relations (like how one unit scales with the other and the land effect on them). Based on the current case, the strategy and tactics base and the world information it would compare and scale how close to a successful plan it can get from the current state, a similarity engine, if you will (for example, if one powerful unit could defeat the enemy, and we have two weaker units, maybe their combined power can defeat the enemy too). This type of strategy is a valid option in a TBS AI development and was used in other games like Civilization. Of course, there will always be some uncertainty, and that will be solved with probabilistic reasoning.
 ===The Case (Strategy and tactics) base===
 This would be the plan and strategy base, updated on each action taken. The base plans and tactics would be inserted from user experience. The others the AI would formulate itself, with probability of success.