Artificial Interactions And Collisions In A Virtual Environment

1. Artificial Interactions And Collisions In A Virtual Environment Bringing it, virtually.

2. Outline • Introduction • Purpose and Motivation • Background • Related work • Project Details • Design Decisions • Demonstration • Implementation Details • Conclusion • Limitations • Future work • Q + A

3. Purpose And Motivation • Provide a framework for further development with the Lumiere Ghosting project • Easily modifiable • Artistically adaptable • Allow for interactions between AI and human users as an interface in the CompuObscura

4. Background On the Lumiere Ghosting Project • Project started in 2002 by Prof. Gillette of the English department; currently maintained and led by Prof. Gillette and Prof. Fowler of the architecture department • Designed to be curriculum for interactive media and information design courses • New Media I: Narratives & Semiotics • New Media II: Technologies & Construction • New Media Projects: Synthesis and Performance • Project encourages students to apply what they learn and engage in the development of the CompuObscura, “an interactive new media theatre”

5. Background On the Lumiere Ghosting Project

6. Related Work • Generic bots found in WoW, Counter Strike, etc. • AI exists to oppose user • Second Life with human interaction in virtual environment • No motion tracking, i.e., system reacts to user input rather than user movement • No generic bot behavior system • Search Assistant in text editors • Rudimentary algorithms for suggesting words as they’re typed—our project looks to more long term searching and goal achievement • Brainworks AI • Complete re-write of Quake 3 AI

7. Project Requirements • The environment should support multiple avatars. • The user should be able to control the avatar movements. • The user should be able to see or detect other avatars in the vicinity of his avatar. • The system will implement a set of modularized behaviors and emotions that will be associated with the avatars. • The system will handle the collision based transfer of avatar emotions and behaviors. • The artificial-intelligent behaviors of the avatar will be affected by the modularized behaviors and emotion being exchanged. • The user must be able to determine the changes that happened to the avatar after a collision. • After a collision the avatar should be able to continue to move freely in the environment. • If multiple avatars collide all will be affected. • The avatars will be designed with the capability of performing simple missions autonomously.

8. Behavioral Characteristics

9. Design Decisions‏ • Goal: System capable of simulating first-person interactions • Bots should have “personalities” • Bots should be able to exchange/mix-and-match these “personalities” • Previous implementations allowed for addition of body parts • Mixing through collision

10. Design Decisions‏ • System to base our work off • Previous systems used proprietary software • Open source? • Game engine the obvious choice • Pre-existing code for 'Bots' • Physics • User controlled characters • Common

11. Design Decisions‏ • Game Engines • Source • IOQuake3 • We Chose IOQuake3 • Free • Open Source • Runs on almost any modern system • Built in inventory system • Had all features we needed, minus custom AI • Which is what we wanted to do anyway :)‏

12. Demonstration

13. Background On ioquake3 • Server maintains state internally • Clients send it updates on what the user does (picks up items, etc)‏ • Server determines how clients interact • Server controls bots • Server can be modified for our own ends • Clients can remain the same • Easy upgrades to the system

14. Implementation Details‏ • Bot has innate and acquired behavior • IOQuake3 has bot characteristics • aggression, scaredness, ... • We modify to happiness, sadness, excitedness • IOQuake3 has inventory control • rocket launcher, BFG10K • We have shown it possible to integrate with behaviors • Combination gives us innate and acquired behavior • When bots collide, they trade 'weapons'

15. Implementation Details‏ • Server keeps a “bot state” for each bot • Bot state contains 'AINode' • Points to the appropriate AI function for each state • AINode_Afraid • AINode_Violent • … • Every 100 milliseconds, the AINode function is called • Every 2 seconds, the AINode variable is updated • Server begins in default state based on characteristic values

16. IMPLEMENTATION DETAILS‏ • Collisions transfer characteristics between the bots • The next state is then calculated by comparing the values of each characteristic • Example: • Violent=0.8, Passive=0.2 • There would be about an 80% chance that the next AINode state would be set to AINode_Violent.

17. Limitations • Almost none • Open source project allows for any modifications • Some problems may be non-trivial • Lack of documentation • We started from a blank slate, looking at the code • Lack of time • Making a complete product with time we had • Two behaviours remain unimplemented

18. Future Work • We developed the framework • Future teams can put pieces together • Need graphics team to “renovate” environment • Give human interaction more meaning • Integration with motion tracking component of CompuObscura system • Player control interaction • Full character motion in-game • Integration with inventory control system • Functional prototype shows viability of this system

19. Questions and Answers AuthorsDaniel NelsonDaniel MedinaIsrael UrquizaAlexander Sideropoulos CPE480 – Fall 2008Computer Science DepartmentCal Poly State University, San Luis Obispo