Monday, November 7, 2011

Close Combat AI in Armed Assault 2

Have I mentioned that I really love working with AIs?  I had so much fun working on RCBOT 2 AI.  As much as I love them, they can also be frustrating.  The default AI in Armed Assault 2, a military simulator, had flaws that really bothered me.

For those of you who don't know what Armed Assault 2 is about:  It is a military simulation game developed by Bohemia Interactive Studios.  Their game engine has been under development for over a decade now and has gathered a large fan base over the years, thanks to their high mod-ability.  Its AI, however, has been its weak point since day one.  Although BIS has been improving the AI and is now quite intelligent, one problem still remains:  the AI is poor in close combat situations.

The following video is a demonstration of the default AI at work in close combat situations:


The reaction time is not that bad as it used to be.  The developers did a good job in making the AI smoother.  However, this is still too easy for experienced players to find near challenging.  Those players want AIs that can react EVEN FASTER.  They want to be kept on the edge instead of leaning back on their chairs and shooting down slow AIs.

My journey to create such an AI began there. 

It took me a day of brainstorming and crunching out the vector math and two days of testing prototypes.

My AI, which will be referred to as CQB AI from here on, first checks for hostile targets that are nearby.  Once a hostile target has been spotted, the CQB AI will lock onto that target unless another hostile target that has been spotted poses a greater threat than its current target (this is determined using a complicated formula that involves the distance to the target and the orientation of the target in relation to the AI).  Once a target has been acquired, the AI will continuously fire an invisible bullet toward this target.  If this bullet hits the target, then the AI has a line of sight to the target and will thus fire at the target.  Now, the AI doesn't actually fire this bullet.  This bullet, called the LOSShot, is spawned at the position of the AI and the physics engine applies a velocity of great magnitude toward the target.  Armed Assault 2 engine stores different types of bullets in the form of classes.  LOSShot is a bullet class on its own that, unlike the other bullet classes, does no damage and has no visual feedback.

The method through which the CQB AI acquires its target is the same as that of the default AI.  Enemy acquisition of the default AI is good enough to simulate the reaction of a human.  The problem of the default AI lay in the fact that the process after acquiring its target was not fast enough.  Naturally, I only had to improve that portion.  The mechanism through which I make the AI fire its weapon is not conventional.  As with the LOSShot, I do not make the AI fire the weapon.  Instead, I use what is called an event handler to simulate firing.  An event handler is a conditional code that is triggered every time a certain action occurs.  In my case, I added an event handler that handles firing.  Every time the AI fires, my event handler is called.  This event handler gets the projectile that was fired from the and redirects its velocity to the target (the engine lets me obtain the projectile and changes its velocity).  This portion required an extensive use of vector math because I had to make so many adjustments to the bullet's velocity as the game engine simulates bullet drop (which is dependent on the distance) and windage (which requires me to adjust the sway of the bullet).  Fortunately, the game engine already had many math functions such as the cross multiplication of the vectors already built in, so I did not have to create new math functions.  However, I still had the daunting and tedious tasks of finding the golden adjustment constant and calling the appropriate math functions throughout the code.

Now, why did I have to simulate the AI fire instead of making him actually fire his weapon?  There are limitations to the scripting engine of Armed Assault 2.  While I can manually adjust the AI's orientation as a whole, I cannot change the orientation of his weapon.  Therefore, while I can make the unit face its target, I cannot make his weapon face the target.  As a result, the bullets have a large chance of not hitting the target.  In order to fix this problem, I had to simulate firing and redirect the bullets' velocities toward the target.  It was an additional step I shouldn't have had to take, but it was a crucial one nonetheless for my purposes.

The most difficult part of this, however, was definitely figuring out a way to check for the AI's line of sight to his target.  Many modders were unable to figure out a way to do this, so I was left on my own.  I brainstormed for two days, and finally I decided on creating a bullet class.  Programming it was not that easy either.  The bullet traveled so fast that it was really hard to detect when it came close to its target.  But I persisted, and by the end of the day, I had a very reliable line of sight checker.  Designing and brainstorming was definitely the hardest part of this whole ordeal.

After three days of working on the CQB AI, my journey came to an end.  The result is a quite skilled and fast AI that is lethal enough to keep the players on their toes.  The following video is the CQB AI at work:


Now, that is pretty fast!  Note that in both situations, the AI was facing towards me before they spotted me.  At this rate, even the experienced players should be careful when they are going into close combat situations.  There is no more need for placing a bunch of enemies when one skilled AI will do.


Thursday, November 3, 2011

MIT Zero Robotics Competition Update - We're going to the semifinals!

At first, I really didn't think we were going to be doing this well in this competition, but after the 2D competition, we came in 21st!  To make things even better, we came in 6th after the 3D competition #1!  This puts us at position 7 and Pirate Squad is safely into semifinals!

I'm really proud of what my team managed to achieve.  We managed to make something that actually worked from a group of five ordinary high school students.  But it's not over yet, and we'll be working hard to optimize our code so that we'll be fit for the semifinals and hopefully, finals.

You can see the results of the 3D Competition #1 here and the semifinalist listing here.  You can also browse and watch simulations of our robot here.  Please note that our team name is Pirate Squad. 

Thanks for reading and I promise to keep you updated on Pirate Squad and Zero Robotics!

Pirate Squad Members:
Paul P. (The author) - Code, Physics, Team Lead
Karl S. - Code, Physics
Mike L. - Code
Josh B. - Management
Max F. - Physics
Mrs. Bunn - Mentor

Tuesday, November 1, 2011

Genome3D

Last summer, I had the pleasure of working for Dr. Jijun Tang of the department of computer science at the University of South Carolina for my summer research. The title of my research was A Viewer Model Framework for Visualizing Multi-scale Three-dimensional Genome with Online Integration.

I worked on a program called Genome3D over a six-week period. The program, coded in C#, was designed to render, in 3D, genome models that are stored in XML format.

The following are some screenshots of the program in action:


A "nucleo" segment displayed by Genome3D.


A segment of "fiber" displayed by Genome3D.


Genome3D workspace displaying a "gloop" segment.

For more details, check out the research paper here.

Somewhere Only We Know Recording

Hello! It's been a while. I have a few things I've been writing about, but they've all been put on drafts, but now that MIT deadline is here (Yay?) it's time for me to put them all on the blog!

Today, I would like to share something that's quite different from the rest. It's not computer science, nor is it a video game of some sort. Today, I would like to share a song that I've recorded on my own, my take on an excellent song, Somewhere Only We Know, by Keane.

All instruments were recorded by me. They include bass, guitar, piano, drums, and vocals. Enjoy!


Monday, October 10, 2011

RCBOT 2 for Team Fortress 2

Developing AIs for video games is one of my favorite things to do. When I found about RCBOT 2, I decided that I wanted to be a part of it. RCBOT 2 is a framework for computer-controlled players in a game. It handles and controls all computer-controlled players, making them compete against human players in a fashion that simulates other human players.

RCBOT had been in development since the Gold Source days, which constituted games that were built on the old Half-Life engine. The founding author, Cheeseh, built RCBOT to something quite universal. You could easily run it on just about any modifications for Half-Life. Then Half-Life 2 came along. He started his new project, RCBOT 2. At first, he focused on getting it to work for Half-Life 2 Deathmatch. Later, with the release of Team Fortress 2, he decided that he would focus on that instead. At this point, I joined him.

Developing RCBOT 2 for Team Fortress 2 (will be referred to as TF2 from here on) was a challenge. Although Valve (the developing company of TF2) promised to give us a bot framework, they never delivered. This meant that we had no means to directly receiving information from the game. Many tricks had be to performed to get the information we needed. This made our bots quite unresponsive, but with much refining, they got to the level where they were reasonably competent against human players. All of the code is written in C++.

Unfortunately, as Valve released their own bots and their subsequent updates that constantly broke RCBOT 2's framework, RCBOT 2 eventually became obsolete. Nevertheless, it served as the only fully-functional bot for TF2 for a while.

The code is open source, and you can find it at sourceforge.net here.

Here is the video of RCBOT 2 at work:

NOTE: There is a degree of violence present in the video, as it is the nature of the game. Please be warned.


All players in the game except for the player that took the video were RCBots.

Java Game

Last year, I made a game as a final project for my computer science class. It's an applet-based game in which you, as a tiny red box, must dodge tiny blue boxes and get to the safe zone marked by the larger green box. You simply control your red box by using the arrows keys to move in the desired direction. Every time you move a step, all the blue boxes will make their steps. If you are too close to one of the blue boxes, then you will be caught. The levels and the enemies (the blue boxes) are randomly generated every time you beat the previous level.

The storyline is that you must escape GSSM (the school I am from), but it is meant, in its entirety, to be a joke. I DO NOT support, in any way, escaping from a school. I don't even know why you have to make the effort to escape. I think they'll kindly just let you leave if you are that desperate.

Digression aside, I thought it was a neat little project that I wanted to share on my blog.



Sunday, October 2, 2011

Zero Robotics

There is an interesting competition going on at MIT called Zero Robotics.

It is a programming-oriented competition where all competitors have to strategically program their satellite probes in order to get the most points possible. The concept is interesting, especially in that it encourages cooperation with your opponents. The more you help them, the more points both of you will get.

And yep, our school is competing in it. The large load of schoolwork is draining us, but I think our codes are well on their way to being somewhat effective for the first round.