I am very gradually piecing together the process for creating a very modifiable and easy to implement, smart, AI system.

A while ago I posted not he concept:

http://www.gamedev.net/topic/651885-programming-the-5-senses/

I had the idea for the complete system (not all mentioned in that post), long before I even knew how to program. I figured there was a buzzword for it already, but I hadn't come across it. Not long ago I came across Entity Component System and I am currently trying to figure out what that is about.

Then i came across Data Oriented Design.

Modular, Good on performance, easy to implement. Few dependencies:

http://gamesfromwithin.com/data-oriented-design

When it comes to intelligence I do think it is mainly about gathering, processing, and using data, so OOP wasn't quite a perfect fit (neither was it the same as my original idea). ECS sounds better.

OOP became more of a handicap when things got long:

http://forum.maratis3d.com/viewtopic.php?id=744

In short, the Senses System uses sensory mechanisms (like collision detection) for one object (or entity) to sense another entity.

If a man object collides with another object, it has touched that object. However, if that same man object collides with a particle from a particle system, it has smelled that particle system. Hearing is a result of volume and proximity etc.

Add a few conditionals based on these events and you can have autonomous movement (a bit of fuzzy logic to make it feel nice).

It just seems like DOD will work, because there will be all sorts of flags going up as an entity detects its environment. It suddenly becomes aware, and of course this might cause memory issues.

Is Data Oriented Design common in AI systems? If not, what style/orientation is more common?

What are some pitfalls?

First of all this is a very nice compilation of sources! Awesome!

Secondly, it just comes down to how you design it like any normal system. I've been working on a DOD based multiagent fuzzy logic sdk for a while now. While my system is more oriented around prediction modeling than the average AI engine for a game, DOD is a near perfect match for most things.

However, there are still times that I can't use Data Oriented Design in my system. While I'd love to have everything based around it, look up tables for entity attributes, as well as gradients for the NNs are stored hiearchly.

I have a nice wiki page for my engine summing this up quite well:

https://github.com/MatrixCompSci/DOT/wiki/Basics-to-DOT%27s--AI

(Don't bother looking through the source. This is all pre-alpha and was mostly a proof of concept for the editor. The alpha releases sometime in January)

The hiearchies are just for specifing template objects that the instances of entities are copied from. Tagging on the other hand is nearly 100% DOD, and the performance increase for caching is highly evident.

After an entity is instanced, there is no further need in the system for OOP. Everything gets handled through the tag system. Updates, LOD shifts, blackboards. Even machine learning and scheduling get handled through tags.

One other thing. Pre-DOD the memory requirement of an Entity was 117 bytes. I just took a remesure 15min ago, and its now down to about 30 bytes. From DOD alone, we dropped from 117 bytes to 44 bytes.

DOD is awesome for AI, if your entire system is not done with DODs. Sometimes you'll actually end up using less memory, and be generally more efficient, when sticking to OOP.

Just read the first few parts of your GitHub post, and I am liking it (going to finish it now...).

I see the fuzzy system and I had made a function myself. I have since changed it a bit.

value = float(83)

def fuzzify(min,max,condition):
	membership = (value-min)/(max-min)
	percentage = membership*100
	if value > min and value < max:
		state = str(percentage) + '% ' + condition
		return state

print fuzzify(75,85,"warm")
print fuzzify(0,30,"freezing")
	

Glad that worked out for you! :D