The Coderack and Codelets

I haven’t done anything substantial over the last few weeks, so I’ll just continue with my meaningless ramblings about a system that lacks any kind of clue if it is anywhere near feasibility. Originally I started this as one big post covering several topics, but now it is sitting here for two weeks at least as a draft, every few days I add some sentences and it still keeps on growing. So I’ll split it up into several posts and this is the first section.

I already talked a bit about Copycat and how its architecture could be used in games. Let me now try to explain this a bit more. A central component of the Copycat architecture is the Coderack and its Codelets, and I believe that it can be used to efficiently manage AI rules and subsystems even without designing a sophisticated cognitive model for the “Computer Game” domain. (The point of the Copycat project was to design such a model and validate that it actually works. I will simply ignore that fact and just use the underlying software architecture for my own purposes.) I will explain later what I believe the problem of current Game AI is and how the Coderack architecture could solve it – let me first try to explain what it is and how it works.

Codelets are small pieces of code that perform a simple function. Usually a single Codelet only implements a small step of a larger process and creates another Codelet that continues where the first Codelet stopped. In the case of Copycat such a ‘larger process’ could be recognizing the group of letter ABC as a successor group.

But the way that the Codelets are executed is not just sequentially running the steps of predefined processes – we wouldn’t need some special architecture for that. Instead Codelets are put onto the Coderack, each one with a certain priority. At each step a single Codelets is randomly, but weighted by priorities, chosen from the Coderack and executed. If the Codelet generates new followup Codelets, it can decide which priority they should have, i.e. it should decide how important or promising the followup action is and how much resources the system should spend on pursuing that path.

As a more concrete example take an imaginary path finding algorithm. Each Codelet implements a specific function of the algorithm, e.g. finding all possible steps that can be made from the start position and generate followup Codelets for each of them, with a priority based on some metric how close it gets me to the end position. High priority Codelets a chosen more often from the Coderack, so if the direct path is unobstructed, mostly those Codelets will be executed that build that path and just a little bit of CPU time is spend on exploring non-direct paths. But if the initially high priority Codelets die out, because they got stuck in a dead end, the algorithm will automatically move on to explore a lower priority path, while still avoiding the even lower priorities.

It is important to understand that this is not just a priority queue, which only picks on the highest priority item, while completely ignoring the rest. Because of the randomization a small amount of CPU time is given to low priority Codelets, so it is a bit more like a process scheduler that divides the available CPU time to various processes proportional to their priorities. But then it is not a classical process scheduler, because there are no real processes in the system. A certain sequence of Codelets could be seen as a micro-process, but there is nothing that is comparable with OS processes/threads, which are very long (by Codelet’s standards) sequences of steps that are execute from the beginning to the end.

I am not sure if this explanation makes any sense to my humble readers. If not (or if it does and you want to learn more about it), I refer you to the book Fluid Concepts and Creative Analogies: Computer Models of the Fundamental Mechanisms of Thought by Douglas R. Hofstadter. For now let’s move on to the problem that I am trying to solve.