Presentation for Timeline Interactive

In Thursday 26-11-2009 we’ve met with 2 of Timeline Interactive staff to introduce our project for them. We are planning to make them our project Sponsor. Below the presentation we presented there (this one differs from first seminar)

Comments on First Seminar Presentation

• Don’t use over body language
• Try to explain any topic in very brief way. Don’t explain a lot if the audience need more explanation they’ll ask you
• Meet your audience needs
• There should be a balance in the presentation topic time. That’s try to make every topic take a specific equal slice of time
• In case of pictures existence in the presentation try to make it easy to understood
• When Drs. Are asking you a question wait until they finish and then start talking
• You are your team should agree on who will answer the questions.
  • A good way is to classify questions under their topic and each one of you is responsible for a topic
• You should make a backup of the presentation: on mail, on flash memory, on 2 laptops and hardcopy
• Always discriminate between challenges in problems in your project. Challenges are results of problems whereas the problems are the source of everything

Our First Seminar Presentation

First Seminar Minutes

The first presentation was so useful we’ve got many new points as:

• Technical Issues:
• How we’ll choose the criteria of determining that the AI-opponents now is able to adapt itself?
• How we’ll handle processing issues (# of frames per second)?
• Presentation Tips:
• Presentation pictures should be easy to understood
• Think about minimizing number of slides

Here are pictures we took with our supervisors

 

 

Introduction to Cooperative AI-Controlled Player in RTS Games

• Overview:
  
  • This document introduce the cooperative feature in computer players in RTS Games
• Technical Terms Used:
  
  • AI-Controlled Player: player in the game that is controlled by the computer not human
  • Real Time Strategy (RTS) Games: games like “Age of Empires, Red-Alert, Warcraft, Starcraft, and Generals…”
• What we mean by cooperative AI-Controlled player in RTS Games?
  
  • Cooperative AI-Controlled player is a feature that makes the AI-Controlled player able to cooperate with other players in the game (AI-Controlled or human) to max the benefit between them
  • Example:
    • Suppose that you are playing a game with an AI-Controlled computer as ally (player # 1) against another AI-Controlled player (player # 2). So when you are attacking player # 2, player # 1 should be able to recognize that and try to help you with supplies from him and synchronize attacking strategies with you
• Why to develop that project?
  
  • This feature is not implemented well in current RTS games. The computer only can sign in the place it’s going to attack not more! Also, the human player can’t talk (via chat) to the AI-Controlled ally and arrange a strategy with it
  • In 10-2008, MIT asks for researchers to provide this feature!
  • We (as Abdelrahman and Omar) have fair knowledge about this area so we’ll start work directly
  • We have a ready developed RTS Game and we are only trying to provide it with additional features. This saves time consumed in developing and testing a new RTS Game
  • After finishing this project, we could merge our work together to produce a processional AI Engine for RTS Games that is able to learn and cooperate with others!

7-11-2009 Meeting Minutes

Objective:

• Discuss Case-Based Planning in details this presentation

What we’ve learned:

• Technical Info:

  • Which module has extracted the TRUE STATES from CURRENT SITUATION?
  • Now we know conflict resolution methods
  • When storing a plan in planbase we may annotate it by plan situation: repaired, modified, failed or succeeded
  • Importance of Cut Arrow in process diagram
  • Our first presentation should contain:
    • Problem Definition
    • Motivations
    • Requirements
    • Project Phases
    • Project General Architecture
• Presentation Info:
• Adjust colors of presentation according to background color

2apl Language : A Fast Overview

2apl is a agent oriented prolog-like language which helps the programming of the interaction between different BDI ( Belief-Desire-Intention ) agents in a multi-agent system.

The Whole System is specified through a (.mas) file , the code related to each agent is put in (.2apl) files . Agents could inherit from others.

A 2APL agent may have beliefs and goals which change during the agent’s execution.

Basic Actions an agent may do

Belief Update Action

A belief update action updates the belief base of an agent when executed.

Communication Action

A communication action passes a message to another agent

External Action

An external action is supposed to change the external environment in which the agents operate.

Abstract Action (similar to a procedure)

An abstract action is an abstraction mechanism allowing the encapsulation of a plan by a single action.

Belief and Goal Test Actions

A belief test action is to test whether a belief expression is derivable from an agent’s belief base, i.e.it tests whether the agent has a certain belief.

Goal Dynamics Actions

The adopt goal and drop goal actions are used to adopt and drop a goal to and from the agent’s goal base, respectively.

Plans

In order to reach its goals, a 2APL agent adopts plans. A plan consists of basic actions composed by process operators.

Reasoning rules

The 2APL programming language provides constructs to implement practical reasoning rules that can be used to implement the generation of plans.

Planning Goal Rules (PG rules)

A planning goal rule specifies that an agent should generate a plan if it has certain goals and beliefs.

Procedural Rules (PC rules)

Procedural rules generate plans as a response to 1) the reception of messages sent by other agents, 2) events generated by the external environment, and 3) the execution of abstract actions.

Plan Repair Rules (PR rules)

The execution of an agent’s action might fail. To repair such actions 2APL provides so-called plan repair rules.

The Deliberation cycle

The beliefs, goals, plans and reasoning rules form the mental states of the 2APL agent. What the agent should do with these mental attitudes is defined by means of the deliberation cycle. The deliberation cycle states which step the agent should perform next, e.g. execute an action or apply a reasoning rule. The deliberation cycle can thus be viewed as the interpreter of the agent program, as it determines which deliberation steps should be performed in which order. 2APL provides the deliberation cycle as illustrated in this figure :

Introduction to Reinforcement Learning

A survey of common techniques used in developing CBR systems

Abstract
After reading many papers related to CBR, CBP, and their use in RTS games, I collected the common techniques used for applying CBR concepts, and sub-tasks. At first, I want to assure that online adaptation of planning in RTS games has been already implemented (in contrast to what we had thought). Thus, I will mention some of the important techniques used in Darmok system; the CBR system that implements the architecture for case-based planning in the WARGUS RTS game. In addition to these techniques, I added some ideas which we can apply in our new CBR system.
Read This Doc

Introduction to Case-Based Planning