//Instruction prototype
typedef void(*pFunc)(void);
struct Instruction
{
int operator() () { if(Function) { Function(); return 1; } return 0; }; //overload function call operator
void *mpMemory; //the local data for the instruction, can be anything
unsigned int mNumBytes;
pFunc Function;
};
...
#include "Processor.h"
#include <iostream>
using namespace std;
Instruction SayHi;
Instruction SayBye;
Instruction SayPoop;
void HiFunc(void)
{
cout << "Hi" << endl;
}
void ByeFunc(void)
{
cout << "Byte" << endl;
}
void PoopFunc(void)
{
cout << "poop" << endl;
}
int main(void)
{
SayHi.mNumBytes = 0; //requires no local data
SayHi.Function = &HiFunc;
SayPoop.mNumBytes = 0; //requires no local data
SayPoop.Function = &PoopFunc;
SayHi();
SayPoop();
return 0;
}
AI using instruction sets
October 16, 2005 10:30 PM
I came across the idea in one of my computer science classes. A processor knows knowthing except for values in registers and the next instruction. An instruction can be high level or low level, depending on what you want it to do.
I've read about a mechanism called OPCodes where each 'OPCode' is basically an instruction with a bunch of data.
I've tried implementing this on my own, such that you can write an AI 'program' using simple instructions. The benefit is that you could have very complex and unpredictable behavior if from any one instruction, you can jump to a wide variety of other instructions based on fuzzy logic (or a trained neural network or similar).
I've just started hacking together some code, and decided I'd just throw it out there. the code below is just very basic prototypes for handling an instruction set. I wanted to just throw this out here, and see what some other smart people think. The code is just the prototype for an instruction, and main() just makes some instructions and calls them.
Nothing terribly complicated about this, but imagine extending it such that you might have these various functions for ai:
-Calculate Pitch/Yaw
-Find new destination
-Attack
-Patrol
But, you could also make very very specific functions for even more complicated behavior, i.e, calculate pitch/yaw could be broken down into more fundamental instructions, i.e:
-Perceive target, estimate target (based on a neural network 'perception' of reality, i.e something that simulates a retina instead of using exact math...could make the results more interesting and less certain/perfect)
pros/cons of this layout?
...and do not wildly extrapolate. Just because Saddam Hussein gassed Kurds in 1990 doesn't mean he eats babies' brains.
136
October 17, 2005 07:39 AM
soudns interesting, but i dont see how your example has much todo with what you were saying :S
-www.freewebs.com/tm1rbrt -> check out my gameboy emulator ( worklog updated regularly )
October 17, 2005 09:35 AM
Well, what you seem to have (re-)invented here is basically a virtual machine for a scripting language. Although I think I get your idea, that instead of having raw machine commands like push/add/xor/.. you'd have some kind of higher-level system for randomly (fuzzy) jumping to different functions or code segments.
Basically I don't see what's the advantage from just using some other scripted AI system, but it looks like a good start.
Basically I don't see what's the advantage from just using some other scripted AI system, but it looks like a good start.
100
October 18, 2005 04:47 AM
Lisp. It is basically what you are trying to do as I see, only crappier.
"It's such a useful tool for living in the city!"
October 18, 2005 06:22 AM
uhh, what i've got above is nothing like list programming.
And to any reasonably intelligent observer it's pretty obvious what I've got above isn't supposed to be fancy.
I'm already writing a much more complicated list of instructions, and a neural network to handle the actual execution of them. Already, I can see the benefits of this system over rule-based or 'hard coded' perceptron/fuzzy logic/neuralnetwork solutions. As I said above, this makes it much easier to jump between instructions when there's not a clear connection between the two.
Also, by throttling the complexity of a single instruction, I'm starting to already find that very complicated behavior emerges from this layout (in which the 'entity' doing the instructions can jump from one instruction to any other instruction based on how it 'feels').
What I'd like to do with this is 'program' AI using a genetic algorithm I implemented for something else in which the propensity for each instruction from any other give instruction is based purely on a neural network...at first, instructions just start happening randomly...the ones that survive are more likely to have a coherent behavior. Already I'm starting to see this with basic behavior such as AIM/SHOOT/MOVE programs (if you check out my fast path finding algo thread, I'm using that engine as a test bed).
If/when I get any really intriguing results I'll make a new thread with a demo. For right now though this is more or less research.
And to any reasonably intelligent observer it's pretty obvious what I've got above isn't supposed to be fancy.
I'm already writing a much more complicated list of instructions, and a neural network to handle the actual execution of them. Already, I can see the benefits of this system over rule-based or 'hard coded' perceptron/fuzzy logic/neuralnetwork solutions. As I said above, this makes it much easier to jump between instructions when there's not a clear connection between the two.
Also, by throttling the complexity of a single instruction, I'm starting to already find that very complicated behavior emerges from this layout (in which the 'entity' doing the instructions can jump from one instruction to any other instruction based on how it 'feels').
What I'd like to do with this is 'program' AI using a genetic algorithm I implemented for something else in which the propensity for each instruction from any other give instruction is based purely on a neural network...at first, instructions just start happening randomly...the ones that survive are more likely to have a coherent behavior. Already I'm starting to see this with basic behavior such as AIM/SHOOT/MOVE programs (if you check out my fast path finding algo thread, I'm using that engine as a test bed).
If/when I get any really intriguing results I'll make a new thread with a demo. For right now though this is more or less research.
...and do not wildly extrapolate. Just because Saddam Hussein gassed Kurds in 1990 doesn't mean he eats babies' brains.
1,090
October 18, 2005 06:34 AM
He said Lisp, not list.
Also, in my opinion, it seems as if you are going to force yourself into a very narrow path. For example, how do you go about choosing which action to use? Well, if you already made that choice, why not just call the function? Why waste your time with function pointers, which will only take and return void? I can obviously see you are allowing yourself to pass in data with the void *, but how will you know the type of that data? How will you know whether its one big string or 5 32-bit integers?
To me, it seems that you are designing yourself into a hole, though I am plenty willing to listen to a practical application of this method. It just seems to me that you might as well take a more robust method than trying to get all pretty with it.
Also, in my opinion, it seems as if you are going to force yourself into a very narrow path. For example, how do you go about choosing which action to use? Well, if you already made that choice, why not just call the function? Why waste your time with function pointers, which will only take and return void? I can obviously see you are allowing yourself to pass in data with the void *, but how will you know the type of that data? How will you know whether its one big string or 5 32-bit integers?
To me, it seems that you are designing yourself into a hole, though I am plenty willing to listen to a practical application of this method. It just seems to me that you might as well take a more robust method than trying to get all pretty with it.
October 18, 2005 06:50 AM
>>He said Lisp, not list.
Lisp = ListProgramming
>>Also, in my opinion, it seems as if you are going to force yourself into a very narrow path. For example, how do you go about choosing which action to use?
Neural network/perceptron solution. In electrionics, something is 'chosen' when a voltage is applied to a particular pin somewhere. This is similar...it all comes down to 'genetics' and weights associated with a neural network. Right now, I'm not doing any training algorithms, just basic commands and hand-fed weights to see if it can even work. This is hard stuff, but I'm quite certain with the right amount of work I can get this to produce some really believable results. In parallel I'm working on instead of the AI defining everything as 'vectors' in whcih there's a mathematically perfect solution, and non-believable AI (the bots can shoot perfectly all of the time) the bots instead just have perceptions of reality...'the target isn't 5 feet away in this direction, I perceive the bot to be so far away at such and such an angle' (the way humans do it).
The void* is probably a bad idea, but any instruction needs any given amount of local data. This may seem counter intuitive, but in this case the fact that it allows you to shoot yourself more or less is how I wanted it designed (low level)...the type of data in there depends on the instruction (compute_yaw instruction will store it as 3 floats in a vector).
>>To me, it seems that you are designing yourself into a hole, though I am plenty willing to listen to a practical application of this method.
Well, I'm already fiddling with some very simple behaviors. I'm not posting anythign yet because there's nothing particularly impressive about what I've done with it, so far.
>>It just seems to me that you might as well take a more robust method than trying to get all pretty with it.
I dont' even understand what this means...what is 'pretty' about this? You have an instruction. You make a bunch fo instructions, this is the bot 'program'. You setup the memory required for each instruction, and you give it a memory address of the actual program equivalent of the instrucdtion. Then, using an external construct, which really is up to the application program, you handle the execution of these bot programs. The program never changes, but how it gets executed does.
But, I'm just glad I'm at least getting some critical responses instead of 'that looks crappy.' Again, I really just need to post when I actually come up with something. Right now, what I've tested in my testbed program, is only very very simple behaviors (the 'AI' in my fast pathfindign algo thread is hardcoded and rule based...what I've done with this instruction struct is no different than that, in terms of the complexity of its behavior).
Lisp = ListProgramming
>>Also, in my opinion, it seems as if you are going to force yourself into a very narrow path. For example, how do you go about choosing which action to use?
Neural network/perceptron solution. In electrionics, something is 'chosen' when a voltage is applied to a particular pin somewhere. This is similar...it all comes down to 'genetics' and weights associated with a neural network. Right now, I'm not doing any training algorithms, just basic commands and hand-fed weights to see if it can even work. This is hard stuff, but I'm quite certain with the right amount of work I can get this to produce some really believable results. In parallel I'm working on instead of the AI defining everything as 'vectors' in whcih there's a mathematically perfect solution, and non-believable AI (the bots can shoot perfectly all of the time) the bots instead just have perceptions of reality...'the target isn't 5 feet away in this direction, I perceive the bot to be so far away at such and such an angle' (the way humans do it).
The void* is probably a bad idea, but any instruction needs any given amount of local data. This may seem counter intuitive, but in this case the fact that it allows you to shoot yourself more or less is how I wanted it designed (low level)...the type of data in there depends on the instruction (compute_yaw instruction will store it as 3 floats in a vector).
>>To me, it seems that you are designing yourself into a hole, though I am plenty willing to listen to a practical application of this method.
Well, I'm already fiddling with some very simple behaviors. I'm not posting anythign yet because there's nothing particularly impressive about what I've done with it, so far.
>>It just seems to me that you might as well take a more robust method than trying to get all pretty with it.
I dont' even understand what this means...what is 'pretty' about this? You have an instruction. You make a bunch fo instructions, this is the bot 'program'. You setup the memory required for each instruction, and you give it a memory address of the actual program equivalent of the instrucdtion. Then, using an external construct, which really is up to the application program, you handle the execution of these bot programs. The program never changes, but how it gets executed does.
But, I'm just glad I'm at least getting some critical responses instead of 'that looks crappy.' Again, I really just need to post when I actually come up with something. Right now, what I've tested in my testbed program, is only very very simple behaviors (the 'AI' in my fast pathfindign algo thread is hardcoded and rule based...what I've done with this instruction struct is no different than that, in terms of the complexity of its behavior).
...and do not wildly extrapolate. Just because Saddam Hussein gassed Kurds in 1990 doesn't mean he eats babies' brains.
142
October 18, 2005 07:35 AM
For AI i'd go with the following approach: give a guy a list of goals, for each goal give a list of actions to achieve that goal. What you get is a simple solution, easily debugable and extendable. You can add random goal choosing, base choosing on the mood, or situation, or just set the only one true goal. The system will be deterministic and controlable, and you can add as much randomness as you want. As i understood in your example your system will mostly behave randomly... just imagine enemy sitting to poop in the middle of shooting. :-)
October 18, 2005 10:07 AM
>> If I close my eyes the world will disappear.
When visage says I'm doing something crappy he at least tells me why, and I agree with a lot of his criticisms. I'm not re-inventing lisp 'as you see' (I've done a bit of work with corman lisp, I can see where you are coming from but otherwise, no). It doesn't really matter, if you know more about lisp than I do so be it. If I'm re-inventing of it, so be it.
>>Lambda: The Ultimate OP-Code.
I will look into that, thanks
>>For AI i'd go with the following approach: give a guy a list of goals, for each goal give a list of actions to achieve that goal. What you get is a simple solution, easily debugable and extendable
This is a perfectly legit way to go. I have done some basic AI in a similar manner. Granted, a lot of what I'm fiddling with real professionals probably wouldn't have time for, but I'm trying to develop a mechanism such that instead of programming the AI to do anything specific, I just give it the basic functionality (call it a virtual machine, re-inventing lisp, or a table driven program, I just call it an instruction set) such that these complicated behaviors can just kind of emerge, instead of the computer explicitly being told what to do (when I have this goal I must perform the following actions).
Again, I really need to just find a way to make it work, and show some advantages to using this method, and I realize a lot of what i say/code isn't particularly clear :)
When visage says I'm doing something crappy he at least tells me why, and I agree with a lot of his criticisms. I'm not re-inventing lisp 'as you see' (I've done a bit of work with corman lisp, I can see where you are coming from but otherwise, no). It doesn't really matter, if you know more about lisp than I do so be it. If I'm re-inventing of it, so be it.
>>Lambda: The Ultimate OP-Code.
I will look into that, thanks
>>For AI i'd go with the following approach: give a guy a list of goals, for each goal give a list of actions to achieve that goal. What you get is a simple solution, easily debugable and extendable
This is a perfectly legit way to go. I have done some basic AI in a similar manner. Granted, a lot of what I'm fiddling with real professionals probably wouldn't have time for, but I'm trying to develop a mechanism such that instead of programming the AI to do anything specific, I just give it the basic functionality (call it a virtual machine, re-inventing lisp, or a table driven program, I just call it an instruction set) such that these complicated behaviors can just kind of emerge, instead of the computer explicitly being told what to do (when I have this goal I must perform the following actions).
Again, I really need to just find a way to make it work, and show some advantages to using this method, and I realize a lot of what i say/code isn't particularly clear :)
...and do not wildly extrapolate. Just because Saddam Hussein gassed Kurds in 1990 doesn't mean he eats babies' brains.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
