Eklektos

Eklektos is a life simulation full of unique characters who engage with the world and each other using utility theory. Like a real person, these characters don't follow a set plan every day; they consider their options and choose a decision by evaluating their needs, desires, and relationships, which fluctuate and evolve over time. Each unique AI can be observed and tracked; they emote, traverse their village, work, form relationships, and care for their basic survival needs. 

This project was created in a year as a Master's thesis artifact using my personal C++ engine.

 Filtered & Gaussian Randomness

• Creating an entire village of unique AI would likely be too time consuming and tedious for a designer. Random generation can assist! 
• These NPC’s desire curves for each survival need were created with filtered randomness; each progressive value had to fit certain rules (be lower than the last value, remain within a limited range of the last value, etc.) to ensure that a curve would indeed form rather than zig-zags or sharp descents. 
• Then, traits were randomly assigned using Gaussian randomness, which is a technique for creating mostly-average populations. Very high and very low scores are rare, so only a few individuals would have the traits, while the rest would score in the average range and have no trait. For example, if Berta scored a 0.13 out of 1.0 on strength, she would receive the negatively associated Weak trait. However, most AI would score close to 0.5 out of 1.0 and receive no trait.

Smart Behavior

• The village is populated with SmartObjects and SmartAreas that may offer actions, or SmartBehaviors; AI have no internal knowledge of actions. SmartBehaviors allow the AI classes to remain lightweight, and designers can easily add and test new objects, areas, and behaviors using XML data.

Query-Based, Fuzzy Utility Logic

• When an AI has a need, it create a query to populate with contexts/facts, including the type of need to be fulfilled, and sends the query out. SmartObjects and SmartAreas receive the query and check the contexts against those of its actions; if a match is found, the action is added to a result list. If no actions are found for the AI query, the AI will try a new query with a lower-scoring need, or default to an always available action.

• Potential actions are evaluated with utility; this process involves mapping the need to a desire curve and calculating a normalized score for the action's usefulness with considerations such as distance and time. One of the top scoring actions is executed.

Behavior Coordination Manager

• For social events, an AI Manager registers available AI, creates groups according to relationship, and chooses the most appropriate action between group members. A management layer is much more efficient than allowing AI to directly query its peers.
• When a group of AI completes a coordinated event, all AI involved are updated based on the event's outcomes; for example, two AI going on a date may increase Attraction & Affection relationship scores, strengthening their desire to see each other again. 

I originally wanted to make this project to explore dynamic village AI for an RPG. Typically, background characters are predictable, sticking to a hardcoded schedule and never progressing as a character.  I learned about many useful AI concepts that I never had the opportunity to try in previous projects, but I also learned that even in a dynamic village, it is boring to watch an AI's relationships and skills to progress slowly over time. For a system like mine to make RPG NPCs more interesting, the player would need to be able to influence and/or interact with the AI more directly. The project was always intended to be less of a game and more of a learning experience, but I hope to use these concepts for a truly engaging title someday!