So heres the deal, every game needs some sort of script compiler. Regardless of how its designed, there will always be a time when the ability to edit the game without recompiling is key. But thats not the only reason, scripts allow us extra layers of abstraction so we can do complex things such as ‘pickup( itemid )’ with ease. But I am getting distracted.
I have been working on this component AI idea and have come to the point where I need to start defining actor actions through scripts. How I have it setup now is the npcActor’s state will slowly degrade over time (think the sims) and when it reaches a threshold they go and search for an object that can alleviate their problems. Its a pretty simple design for a simple test. As mentioned in previous posts, I want these npc’s to learn from interacting with the environment. This combined with the mbti structure and other things should produce reasonably agile AI (see previous posts for specifics).
I thought of making this post to stress a key factor in my decision making process as it pertains to this project. And that is abstraction. The abstract is key to this project. In an ideal world, nothing here should be hard coded, unfortunately that is a little hard to do, especially right from the get go. So what I decided to do was to brute force my way to a reasonable demo app and work backwards from there. Removing static code as needed to perfect the design. For instance, I have pretty much decided on a syntax for my scripting language, but I have left much of the interpretation to genetic algorithms in the compiler. Here is a sample script
using actions
using health
_actions::sit $this
$sitting = true
callback -actions::stand _stoodup
{ $health::comfort +1 / 5 } while $sitting
_stoodup:
$sitting = false
::
I am not going to explain the syntax because to any programmer the intentions should be clear. The problem I have been facing is how to keep the intentions abstract enough to allow multiple interpretations. I want Bob’s sitting to look different from Kim’s. I have currently setup a system where the compiler creates these jobs for each script and at the appropriate times sends messages to actors to handle actions. It is then completely up to the actor as to how to handle the action. For instance, when the compiler runs over ‘_actions::sit $this’ it will send a message to the host actor to sit on the target object. In this case the message will not be as simple as
msg.id = ACTION_SIT;
msg.target = 0x01234567h;
msg.brainless = 1;
Instead the message will contain a number of input to be inserted into a designate neural network, which would have been trained earlier to sit when given those inputs (exactly how they sit is up to the GA).
So then how to handle direct variable access like the ‘$health::comfort +1/5′ line above. Well some messages will have to be specially constructed to be brainless. I figure I will have a range of message id’s designated for variable access, neural network input, etc. So a msgID of 1 would be to set a variable, and 2 would send the incoming data into the NN.
This is not the final system, just what I am currently using for testing. However this is the current framework for future applications. The goal of this first program is to weed out any bugs and get a clear understanding of how I want this thing to run.
You can notice how this solution offers a direct line to the actor’s state of mind without hard coding everything, which is exactly what we want.
Tags: ai, design, Programming, Ramblings

No comments
Comments feed for this article
Trackback link: http://charlessolar.com/post/14/trackback