|
Contents Domain Illustration Methods Conclusions
|
Domain A note...view source if you want to see the individual tables. Didn't come out right. The environment for PROJECT:GINSU is loosely based and inspired by the sword-fighting Playstation game Busido Blade. The basic premise is that we have an agent that will battle another agent so as to score a hit or "kill", ending the "game." The agents will have at their disposal a limited number of attack and defense moves, which correspond to decisions he must make about his environment (the fight). Thus the agents will use this to relay a sequence of moves or combos, ultimately ending in either one or both agents being killed (a double knockout, so to speak). At any point in time it can assess it's situation (death of either agent, distance from opponent, etc.) and decide then which action would be most appropriate to execute. The fight will be relayed to the user as a sort of story, entailing each of the agent's moves and the result after that "round" of combat. Here is a listing of the kinds of objects in each world: ACTIONS Interpretation highslash(opponent) executes a high slash. It is faster and will beat a big swipe. lowslash(opponent) Executes a low slash. It is also faster. bigswipe(opponent) Executes a stunning blow, must be a short distance away. parry(opponent) Blocks normal attacks. Agent becomes stunned, however. sidestep(opponent) Move to the side. avoids high and low slash but not big swipe dashback(opponent) Jump back. Avoids all attacks movein(opponent) moves in to melee range. These actions are based on the following rules and assumptions DISTANCE INTERPRETATION melee(A1,A2) close-quarters fighting. High and low slash attacks only. backoff(A1,A2) a short distance away from opponent.Only attack from here is big swipe. SPEED INTERPRETATION fast(action) fast hit. Beats a slow hit. High and Low slash are fast. slow(action) slow hit. Beaten by fast hit. Only big swipe is slow. POSITION INTERPRETATION side(A1,A2) A1 to side of A2. Only big swipe for attack front(A1,A2) A1 ahead of A2. High and Low slash only. also: stun(A1) A1 is stunned. Cannot make decision for next round. dead(A1) Well, A1 is DEAD. The final result dko(A1,A2) Double knockout. Also a possible final result. A scenario would go something like this: (loosely) Being the agressive agent that it is, Agent 1 goes for a high slash, which is parried by Agent 2. He then follows with a low slash, also deftly parried by his skillfull opponent. Agent 1 jumps back to await his opponent, as the other advances. A1 senses an attack and raises his sword in defense, while Agent 2 comes in with a high slash. A1 then sidesteps, while A2 follows up with a low slash. A1 then sends his own attack, a vicious lower cut, but his opponent sidesteps and avoids a gutting. A1 jumps back again, and sees A2 did the same. A1 utters a bellowing battlecry and goes for the kill with a massive swipe. A2 parries the blow, but becomes stunned momentarily. A1 opts for the high slash, and this time A2 is hit. A1 raises his arms in triumph over the now headless A2. The program is simple to understand in design, but hard in its implementation. For this assigment I chose C, as it was very versatile and easier to gives us the kind of story-like output I desired. I have given 7 decisions or actions that an agent can make. This translates to a state or search space of 49 possible permutations, given for each "round of combat" or moment in time. I felt an easy way to do a search on the space was to implement it as a two-dimensional array, or matrix. After every "round", the matrix would be updated to indicate which course of action was take by both agents. From the information stored in the matrix, each agent can update the different sets of things that in the world (who is stunned, where the opponent is, etc.) and can form a result that would not only inform it if it's goal was obtained, but would help it choose the next move. The decision making process, easily the hardest thing to implement, was done in this way. The agent would check it's current situation versus the rules and relations that applied to making each action true. The results were stored in an action array, with the index being then associated action that could be taken and the entry being it's possibility of use in the next move (0 for no, 1 for yes). In addition, the number would be raised if certain conditions were present, hence raising it's priority or "sense" as the next proper course of action. (For example, Agent 1 realizes that it can either attack with a high slash, parry, or sidestep. It then tests a condition to see if the other agent is stunned. If its opponent is stunned, it will raise the priority of the attack option, hence expressing its "reasoning" to achieve it's goal.) In the case of multiple courses of action having the highest priority, the agent checks them through an action count array, which stores how many times the action has been done in the past. It can then compare the possible actions with which one has been done the least, and in a sense "try a different approach" in the next round. The messaging algorithm is simple a set of case statements which map the actions taken with the phrases that could be associated with each agent for that time period. It then prints out those actions for that round in order. All of this is done inside a big while loop which ends when either one or both the agents have been killed. This project proved to be a bit more involved than I imagined at first. I realize that while the agents seem intelligent, they still do not show a real sense of planning or learning from each match. They simply try for the best possible course of action in each round, and don't pay attention to each other's patterns; they just observe the result of each round and take into account the last action of each agent. The code, however, can be modified to allow for more realistic planning and even a learning algorithm. In future attempts I will attempt to have only one agent act with a user. |