Ramblings

In a continuation of my last article, I would like to record the process I have been taking to creating and designing the component AI I described in my last post. Component AI is my term for this idea right now, I really have no idea if it has been done before so for right now its what I call it. Now, for those of you who might be familiar with component based object systems (Game Programming Gems 5), this concept will not be to hard to understand.

Basically, we want the npcs to operate off of components they learn about through their training. I know I did not mention training in my last post, but it is necessary for the npcs to not look like mindless zombies through half the game. Each npc will have to be fed through a virtual school where they will learn, through various tests and challenges, how to operate in their world. But I am getting distracted here, back to the design.

Component based objects can be summed up as imaginary containers that are filled with components that operate the object. For example, one component might be a renderer, another holds a model, and one more holds animations. These three together form a solid object that will be displayed in game. They are attached to each other solely through the object manager, but nonetheless are able to effectively communicate with each other through interfaces and a messaging system. I wish I had GPG5 around me so I could yank their example, but I think you get the general idea.

Anyway, objects communicate with themselves through messages, and each of the components that make up an object can subscribe themselves to different messages. A render component would subscribe itself to a ‘draw’ message, that way when the game sends a ‘draw’ broadcast, all objects that have the render component will draw themselves.

That is how component object systems work, when we introduce the ability to pick up new components during run time through actions, we have component AI. The npcs will be equiped with the simple components, model, render, animate, physics, ai, etc, and they will be able to pick up new components from the world to plug into their brain for future use. These types of components can subscribe themselves to messages, and even communicate with each other to achieve the best results. Some form of genetic training will have to be used to teach these components how to effectively communicate. When the npc comes across something new that it doe not know how to handle, picking up a chair for example, it will need to know things about weight, body position, what limbs to use, how to grip it, pretty much everything, and the only way he will know is if the components in his head know how to communicate effectively.

Yes I did mention body position and dynamic animation. I already mentioned the fact that objects themselves will hold data on how to handle them, generally. Then after the npc does that action he will gain a new component for handling that object. This system does not conform very well to static animations like most games keep. So animation will be dynamic and learned by the npc over time. This allows npcs to gain their own style of movement and actions.

Yes yes, I know I am going a bit over board again, running 8 or so npcs each tugging about 10,000 or so AI components will probably be a big load. That is why I need to write a demo application one of these days to see how much this will cost. For right now I am planning to go all out, screw the cpu, but most likely for slower computers we can introduce a system to merge and combine components to save processing time. However the more components you combine the more hard coded the npc becomes.

I had a thought today while walking outside about human-like ai. This is of course, in relation to the game idea I posted a few days ago, but the gist of my goal is to have npc’s that can successfully animate and control characters designed from popular animes.

The idea is pretty simple, the npc’s will derive their actions off objects, not off of themselves. In other words, they will look at the object to determine how to handle it, not depend on preprogrammed responses to objects that are a chair. The objects will store data that the npc can use to lets say, pick it up, throw it, eat it, ect. And the npc will use their MBTI to determine what should be done in the given circumstance.

Part two of the idea is that these objects will also hold ‘experience’ data that the ai will pick up and remember for certain lengths of time. This data can be pugged into their design making structure and called on during other circumstances to determine what to do or how to interact.

Heres a live example,

The npc walks up to a wooden chair
He sees that the chair can be picked up, sat on, broken, and burnt

Along with these verbs are tags that help the npc with the decision.
Example, ‘sit down’ is tagged for resting
‘burn’ is tagged for warmth

He thinks about it and determines that he needs a rest so he sits down
His fatigue goes down and the chair teaches him that sitting down makes him rested
After that he thinks again and determines that he is really cold, so he finds an object that will light the chair (oil and matches) and does so

This demonstrates another part of the idea, in which objects must interact with each other using the npc as a medium. The matches will be tagged as ‘makes fire’ the oil would be ‘spreads fire’ and the chair’s ‘burn’ tag will say that it needs something to start and spread the fire, in order to be used. Sort of like, requirements for an action. To discover the tools, the npc must be able to scan local tags.

The chair is lit and the chair teaches the npc that burning things will make him warmer
However this chair exists in a hay barn, and now that there is a giant fire in the room, all the hay ignites

This is can be accomplished by state broadcasting. In which objects changing state ( eg. Stable to ablaze ) will broadcast the change to all other objects and and objects listening to such a change will decide what to do. ( eg. burst into flames )

So now our npc is to hot and the hay teaches him that hay + fire is not good.
He leaves the barn because the environment outside is not on fire

This action causes a conflict in his code.
On one hand he learned that fire is warm and thus good when cold
On the other hand he learned that hay on fire is bad and makes him to hot
This is not exactly what should be learned here, but I never said this design was perfect

And so our npc lives to see another day, only slightly smarter then he was before. But he gained some valuable survival skills.

This design still needs some tweaking, but at least now we have a working model that I can start writing and testing.
One other thing I should mention though, as these npc’s collect environment data from these objects, certain ideas and concepts are going to collide and others will become useless. We should also account for the human’s ability to forget ideas as well. Some form of garbage collecting will have to be done to clear out bad data. Just keep that in mind.