-
Notifications
You must be signed in to change notification settings - Fork 11
Documenting AI Part I
Competent Artificial Intelligence has been a real big resounding problem for this project. My goal when writing this document was to come up with a way to organize AI where regardless of the programming language used, the flow of AI can be understood and expanded. I hoped that it’ll make AI have equitable access, without the hassle of having to read down a specific code base.
As you can imagine, this will come with its set of problems. Behavior and decision making isn’t always something that lends itself to an easy to read format. Behavior trees do have the weird ability of being very large and cumbersome, and writing out each decision is going to feel the same way. It looks like we are going to have to dig deep in order to come up with a valid solution.
Obviously, there is no easy textual solution to this. So, I had to base my research on something that has been around for generations. What better specimens do we have to study when it comes to mass decision making than our own human minds?
You see, I realized something about us, that even though we have a near infinite amount of decisions we can make, we usually only focus on a broad scale. This is very apparent when we are placed in a scary situation. If the object around us isn’t perceived as threatening, we usually fade it into the backgrounds of our minds. We focus on things out of the ordinary, then quickly use that information to access what may be happening in the general area.
For instance, if a pencil drops, our minds usually sweep to the broader solution. Either the person that is hunting us is there, or the wind moved the pencil off the table. Our thoughts can care less about the action, and more about the elements that make up that action.
What this means in terms of charting out decisions is that we also have to make them vague. When we are laying out the various charts, the challenge is more of setting up the idea of what a segment of a behavior is doing, rather than making a bunch of decisions in a row.
Another aspect we get from real life is splitting up behaviors by response. The action of a pencil or a book falling in the same scary situation invokes the same response. It is very important that similar behaviors share the same response title. The same way the human mind broadens decisions, will also help navigate on how to simplify AI charts.
In order to most properly set up idea charts, it is probably time to start looking into how people originally organized thoughts to paper. For anyone who has had to write a focused school essay, the process of writing one takes a lot of effort. Our minds are brilliant, but lack focus when consolidating huge ideas. In order to understand how best to organize AI, then it is best to look at the process used to formulate an essay.
Brainstorming is the first flurry of ideas, and literally, it is a mess. We have a bunch of things that we want to do, we have a bunch of ideas we want to say. So, we begin by writing them all down on a sheet of paper. The list is usually long, indistinct, and crazy. Some of the ideas jotted down don’t make any sense whatsoever.
What we learn from this step is easy. The first thing we need to do is create a list. Not just any list, but a list of tasks that the AI has to perform. You see, the AI has a broad goal of needing to capture an HQ or take down enemy units. However, there are many smaller goals that the AI has to do in order to reach the larger ones. Some examples of these goals are the following…
- Capturing a neutral property
- Attacking an enemy unit on a property
- Crossing a river
- Loading into a transport unit
- Protecting a hurt unit
- Moving into a repair spot
- Moving out of enemy fire range
- Etc.
Creating a complete list of these actions is exactly what we want to do. It is important not to be too specific like “Move a Unit” or “Attack”. The actions have to be as broad as possible, as each unit and building object needs to be able to relate to this behavior in order for the chart to encompass all the actions.
Every essay has a main idea, and sub-ideas that support the main idea. In the second step of our essay writing, it is just as important to figure out our main idea as it is to figure out the sub-ideas and supporting data. Nothing achieves this better than writing a Flow Chart, which helps ideas connect to one another.
In terms of AI programming, we have something very similar to flow charts called UML. Now, I’d be the first to say that when I was first introduced to UML, I thought that its application was quite shaky when applied to Computer Science. Programmers do most documenting from within the code base itself, where we use naming and comments to keep solid track of the programs flow.
Where code base documentation absolutely falters is when we delve into logic programming. We end up in many cases, frantically searching through debug breakpoints to try and understand why a number is off. It is what I coined as a logic error in the code. A logic error can’t be avoided by documentation, or proper naming of a function, class or variable. A logic error is a mistake in the developer’s flow of thought.
In this game, in order to properly document flow of thought, it is imperative that we write down our code in the same way. UML is an excellent tool for keeping the exact flow of thought steady for any Artificial Intelligence that will be made. By using UML, we can then sort each goal into a main goal, sub-goals, and supporting goals.
In school, I never found this step all too important. Literally, it is a repeat of the above step except that you write it in a list. However, the most important part about the Outline section is the order of which the ideas are presented. An essay thrives on presenting its ideas in the most organized way possible. The outline is a way to catch any disruption in the flow of ideas while producing them.
For this section, I will speak more about the types of goals, as they have a lot to do with organizing flow within AI. By using concepts from Math Logic (AND, OR, NOT), combined with prioritizing the UML goals, we should reach a more solid document.
Supporting goals are essentially the leaves of the tree. The supporting goals are the parts that we actually code the engine to do. For instance, “capturing a neutral city” or “attacking a nearby enemy indirect unit” will be leaves in the tree. The supporting goals contain the titles of the brainstorming ideas earlier, and will be the only actions with code attached to them.
Sub-goals are broader statements for supporting goals and other sub-goals. Some examples of a sub-goal would be “capturing an non-allied property” or “attacking an enemy unit”. Sub-goals are idea connectors and they can relate to one another.
Sub-goals main purpose is to access the situation and set a priority (either by best decision or randomly) for which action is best to be performed. Sub-goals therefore will collect data about the map presence directly and choose between the children options for the best possible or random outcome. Sub-goals can use AND, OR, or NOT to split up children into better decision outcomes.
Main-goals are a collection of sub-goals catered to a purpose. They are essentially a way to organize group sub-goals into groups. Some examples of main-goals can be “capturing all enemy factories” or “destroying all enemy indirect units”.
For the purpose of organization...
- A main-goal can be part of a sub-goal tree.
- Each main-goal will contain a tree no larger than 5 branches deep.
This way, main goal ideas can be shared among many different logic AI trees, and the AI can be organized in a “Table of Contents” fashion within a wiki page, or even scattered among many documents. This will also help sub-goals share behaviors easier as many of these behaviors are bound to repeat for different trees.
Now the essay is ready to be written, and we go through a series of drafts. A rough draft is an attempt to try to make sense out of our ideas. It is a chance to see if the flow of our ideas matches what we are trying to convey to the reader.
In terms of AI programming, this is the exact framework that we should follow. We should never be afraid to revise the flow of ideas in the AI flow chart. We keep on making revisions of our ideas, and making new charts of how the pieces flow together. We then set up the priorities, and attempt to revise the chart until it conveys what we want the AI to accomplish.
The final copy of our paper is done, and we are ready to present this to the professor. It isn’t perfect, but it is the best that we can do and we are ready for it to be released to the public.
It may take a few revisions, but the flow chart gives us a basis of where we can try to revise on the ideas and create a better flow for our behavior trees. We can use the ideas to figure out what data needs to be pulled from the map, and also to help make decisions based on it. Just like a final paper, it won’t be perfect. But at least we’d have a written out paper that everyone can review and make comments on how to improve.
- Resources
- Tools
- Development
- Design Documents
- Archive