User Input: I used SFML to control the user input.

GUI: I used SFML library to show fonts. I display player’s health, fps and boss’s health. The user can interact with the main menu through the keyboard.

Audio: Set up audio with SFML library.

Project Team:
Nicolas Bertoa (Programmer)
Guillermo Oursi (Artist)
Damian Linossi (Artist)
Mariano Bertoa (Artist)

Code Samples:
GameManager.h
GameManager.cpp

Download Link:
http://www.mediafire.com/?nhj3h5mmzdi

Screenshots and Video:

Simple Soccer

This application is based in the creation of agents capable of play soccer. You can see the default application in the following video:

Supporting attacker is always alone.

As you can see, when a player is in the SupportAttacker state, nobody pursues him. So his partner can pass the ball to him easily.

We must choose an opponent to pursue him. For that we create a new state called MarkSupportingOpponent. When a player is in this state, he will interpose between the ball and the opponent. The header file is the following:

MarkSupportingOpponent.h

In the enter function, the player activates the Interpose steering behavior.

In the exit function, the player deactivates the Interpose steering behavior.

If the player is the closest to the supporting attacker, then he updates his target, i.e, the supporting attacker’s position. Else, he changes to the ReturnHomeRegion state, i.e., he returns to his default region.

MarkSupportingOpponent.cpp

You can see the behavior in the following video (Note how the supporting attacker isn’t alone)

But an important question is: What player must we choose? We will choose the closest opponent, that isn’t chasing the ball in that moment. For that, we implemented the isClosestTeamMemberToSupportingOpponent function in the Field Player class. We didn’t implement this function at Goalkeeper class, because the goalkeeper must not pursue the supporting attacker.

The function definition is the following:

isClosestTeamMemberToSupportingOpponent and ClosestPlayerToSupportingOpponent

Keep the ball and wait the supporting player to reach his position.

When the attacker goes to the opponent goal he will make a pass to the supporting player when he reaches his position or he will shoot if he finds a hole in the defense. But what happens if the supporting player is far from his position and the attacker doesn’t find a good shot? Then the attacker will go directly to the goalkeeper or to the end of the field. We must improve this behavior!.  You can see this situation at 0:48 of the first video.

To improve this, if the attacker is closer to the end of field than the supporting player to his final position, then the attacker must protect the ball from the closest opponent player.  If the two players are face to face, then the attacker must give back. You can see the code in this link, you must understand basic algebra( vectors and dot products).

You can see the behavior in the following video. (The blue attacker player covers the ball until he can pass the ball to his partner)

Posted in Artificial Intelligence ]]> http://nicolasbertoa.wordpress.com/2009/10/28/simple-soccer/feed/ 0 nicolasbertoa http://nicolasbertoa.wordpress.com/2009/09/22/finite-state-machines/ http://nicolasbertoa.wordpress.com/2009/09/22/finite-state-machines/#comments Tue, 22 Sep 2009 02:07:35 +0000 Nicolas Bertoa http://nicolasbertoa.wordpress.com/?p=228 ]]> I will explain the Finite State Machines concept and I will give an application example. My explanation is based on Chapter 2 of Programming AI By Example book. Thanks Mat Buckland for your excellent book. You can download the source code and the executable from here.

What is a Finite State Machine (FSM)?

A finite state machine is a device, or a model of a device, which has a finite number of states it can be in at any given time and can operate on input to either make transitions from one state to another or to cause an output or action to take place. A finite state machine can only be in one state at any moment in time.

The idea behind a finite state machine, therefore, is to decompose an object’s behavior into easily manageable “chunks” or states.

Example:

The ghosts behavior in Pac-Man is implemented as a finite state machine. There is one Evade state, which is the same for all ghosts, and then each ghost has its own Chase state, the actions of which are implemented differently for each ghost. The input of the player eating one of the power pills is the condition for the transition from Chase to Evade. The input of a timer running down is the condition for the transition from Evade to Chase.

Advantages:

They are quick and simple to code: There are many ways of programming a finite state machine and almost all of them are reasonably simple to implement.

They are easy to debug: Because a game agent’s behavior is broken down into easily manageable chunks, if an agent starts acting strangely, it can be debugged by adding traced code to each state.

They have little computational overhead: Finite state machines use hardly any precious processor time because they essentially follow hardcoded rules. There is no real “thinking” involved beyond the if-this-then-that sort of thought process.

They are intuitive: It’s human nature to think about things as being in one state or another and we often refer to ourselves as being in such and such a state.

They are flexible: A game agent’s finite state machine can easily be adjusted and tweaked by the programmer to provide the behavior required by the game designer.

The West World Project:

As a practical example of how to create agents that utilize finite state machines, we are going to look at a game environment where agents inhabit an Old West-style gold mining town named West World.

Any state changes or output from state actions will be sent as text to the console window.

There are four locations in West World: a gold mine, a bank where Bob can deposit any nuggets he finds, a saloon in which he can quench his thirst, and home-sweet-home where he can sleep the fatigue of the day away. Exactly where he goes, and what he does when he gets there, is determined by Bob’s current state. He will change states depending on variables like thirst, fatigue, and how much gold he has found hacking away down in the gold mine.

The Miner States:

The gold miner will be able to enter one of four states:

EnterMineAndDigForNugget: If the miner is not located at the gold mine, he changes location. If already at the gold mine, he digs for nuggets of gold. When his pockets are full, Bob changes state to VisitBankAndDepositGold, and if while digging he finds himself thirsty, he will stop and change state to QuenchThirst.

VisitBankAndDepositGold: In this state the miner will walk to the bank and deposit any nuggets he is carrying. If he then considers himself wealthy enough, he will change state to GoHomeAndSleepTilRested. Otherwise he will change state to EnterMineAndDigForNugget.

GoHomeAndSleepTilRested: In this state the miner will return to his shack and sleep until his fatighe level drops below an acceptable level. He will then change state to EnterMineAndDigForNugget.

QuenchThirst: If at any time the miner feels thirsty (diggin’ for gold is thusty work,a don’t aya know), he changes to this state and visits the saloon in order to buy a whiskey. When his thirst is quenched, he changes state to EnterMineAndDigForNugget.

The Miner’s Wife States:

Elsa is the miner’s wife and her states are the following:

WifesGlobalState: This state will execute always, because is global. When Elsa needs to go to the bathroom she will change to VisitBathroom state. When the miner send her the message “Msg_HiHoneyImHome”, then she will change to CookStew state. “

DoHouseWork: The most usual work will be the house work.

VisitBathroom: Elsa will do her needs and then he will revert back t her preovious state.

CookStew: In this state she will send herself the message “Msg_StewReady” and when she receive the message, she will send the message “Msg_StewReady” to his husband and she will revert back to his previous state.

Doggy States:

In addition to this application I created Doggy, the family’s pet.  Its states are the following:

AtDogHouse: In this state, Doggy is playing and resting at the dog house. When it feels hungry, it will change to WaitingFood state.

WaitingFood: In this state Doggy will send the message “Msg_DogIsHungry” to Elsa because it needs to eat. When Elsa sends its the message “Msg_DogFoodReady”, Doggy changes to EatingFood state.

EatingFood: In this state, Doggy is eating. When it is satisfied, it will change to AtDogHouse state.

User Input: I used events to manage user input. They are integrated with the Irrlicht engine.

GUI: I used the GUI that comes with Irrlicht engine.

Audio: Set up with Audiere library.

Project Team:
Nicolas Bertoa (Programmer)

Download Link:
http://www.mediafire.com/download.php?ljwzojnnvtz

Code Samples:
GameStateLevel02.h
GameStateLevel02.cpp
GameMenuState.h
GameMenuState.cpp

Screenshots and Video:

Igor screenshot 1

Igor ScreenShot 2

User Input: I used SDL to control the user input.

GUI: I used SDL_Ttf library to show fonts. I display the player’s score and boss life. The user can interact with the main menu through the keyboard.

Audio: Set up audio with SDL_Mixer library

Project Team:
Nicolas Bertoa (Programmer)
Mariano Bertoa (Menu Designer)

Code Samples:
bullet.h
bullet.cpp

Download Link:
http://www.mediafire.com/?kydwj3mufml

Screenshots and Video:

Ace Slayer screenshot 1

Ace Slayer screenshot 2