As a follow-up to my minesweeper game, I wanted to develop a pathfinding algorithm on a similar platform. At the same time, I had modeled a snowman, so I decided to use it to collaborate my modeling skills with my programming skills.
This project uses the A* (A-star) Search Algorithm to generate a path from one point to another on a grid system, finding the shortest way to the destination grid without running through walls. The grid settings are fully customizable in that you can get the maximum row and column as well as the number of walls present in the grid system.
I have to say that this project is very relevant to my field of study because pathfinding algorithms such as this relate to my interests in game development and artificial intelligence.
So how does it work? When the user clicks on a point on the grid, the program will convert the clicked position to the corresponding grid object. This grid object is then set as the destination. The grid object that the snowman is currently on will be set as the start position. Then, in an iterative loop, the program will find the grid objects adjacent to the current grid (which will be the starting grid object to begin with). We will calculate the F cost of each grid object. The F cost is the sum of the G cost and H cost. G cost, as represented by my program, is the distance from the current grid object to the adjacent grid object. H cost is the distance from this adjacent grid object to the destination grid object. The adjacent grid object that has the lowest F cost will then be new current grid. This process will repeat until either the destination grid object becomes the current grid or the entire grid system has been essentially exhausted in search.
Here are some screenshots of the program at work:
We click on the point opposite of the snowman in relation to the two walls.
The snowman calculates the shortest path to the destination and begins moving.
Seen in a different angle, we see that the snowman has made it to the destination.
This past Saturday, I went to University of South Carolina Aiken to present my research at the statewide annual South Carolina Junior Academy of Sciences. There were over 300 other student presenters. The event took the whole day. I attended many of the presentations and many of them were excellent.
The awards ceremony took place late in the afternoon, and to my pleasant surprise, my research presentation took first place in the Math / Computer Science Mentored Research branch. I was honored to receive the award. It was something I couldn't have done without the help of my research advisor, Mrs. Bunn, who has listened and advised me during hours of my practice presentations. So, thank you!
As an interesting amalgamation of game design and algorithm development, I worked on a 3D minesweeper game in the past week. It turned out pretty well, I think. It has awesome explosions (when you click on a mine) and cute little red and white cubes with numbers on them. You can also move the camera by using the W, A, S, and D keys as well as rotate and zoom in and out by using Q, E, Z, and X keys.
The code design is facilitated by the use of recursive methods, which help reduce processing time tremendously. Mines are generated randomly in a two-dimensional array that represents the grid. Because the cubes are represented in a three-dimensional way, handling the user clicks was interesting. When the user clicks on any point in the world, we perform what is called a raycast. Raycast creates a ray of predefined length from the user's point of view in the direction of the position of the mouse click. If the ray hits any cube, then we consider that cube to have been clicked.
I've tested this program up to 60 by 60 grid and it has worked beautifully with little lag. Enjoy the screenshots!
Hello, everyone! It's been a while again, but since the last post, I have some stuff to show you.
Recently, I finished a 3D model of an M16 Rifle. I have quite an interest in guns, so modeling this one was quite a fun.
It's a rough sketch of the gun. It's unskinned and lacks fine details that the gun has. Since I'm just learning how to model, I'll save those for later.
Hello, everyone! I've not been able to post anything for a few months now. I just wanted to let all know what's been going on in my life.
For the past few months, I had the privilege of having the opportunity to work with the mayor of Hartsville and create an iOS app that has the possibility to be sold to huge industries around the world. Now, I can't really tell you what it's all about for the sake of business, so let's not get into that.
Basically, since 2012 started, I was busy scuba diving, doing tons of Govie schoolwork, meeting with the mayor, and programming for my app. You know what's really cool about this app? It's all a result of my own work. I really didn't think I could do so much by myself, but I did, and I am rightfully proud of it.
I'll post screenshots of it at work once, hopefully, sales begin. But until then, it's going under the radar.
So, that's the gist of how my life's been and probably will be for a little more until I finish revising the designs. It was nice to write again!
It's time for Christmas break! The last few days have been quite hectic with all the exams, but I made it through. Although I really should be relaxing right now (or maybe freaking out because MIT early action decisions are coming out this Saturday), I found a song that I started working on this past summer, but I never had the chance to finish. Since I left all my recording equipment back at the school, I won't have the ability to finish it over the break. Bummer! Instead, I decided to upload what I have and let you guys enjoy the work in progress.
This song, called June WIP (for now), is a rock song that incorporates heavily distorted guitar, booming bass, and powerful drums. I really had fun getting this song started. I hope to get this song to where it's actually a song by finishing it up and adding vocals to it in the near future.
When you're on the road and want to go somewhere, usually you want to take the shortest route. What's better than to have a program find it for you? This week, I completed a program that does just that, given enough databases.
Coded in C++, this program uses the Djikstra algorithm to calculate the shortest distance and path from the source city to all possible destinations. All the user needs to do is input the source city and it will calculate the shortest distances to all other cities that are available in the database (input.txt in the same folder as the executable file).
The download link to the file is below. It contains a sample database that I created, and therefore the mileages are not accurate. To install it, extract the contents of the zip file anywhere as long as the exe and input.txt are in the same directory. The program should provide you with enough directions to get you started. Simply type in the name of a city that appears on the command window.
Now that we're finished with Zero Robotics, it's time for us to focus on FTC (FIRST Tech Challenge). We plan on participating in a statewide tournament in February to qualify for the national championship.
We went through a lot of design changes in the past few days to prepare for the scrimmage that took place yesterday at Aiken High School in Aiken. The scrimmage was definitely a fun and very informative experience. We learned about many technical problems that could arise during the match, and took immediate steps to fix them. We also got used to the rules of the game and as a driver, I had the chance to see how good my skills were in operating the robot. To be honest, they need work, but we still have plenty of time to play around with the bot.
Overall, however, our robot worked quite well. We went over there thinking, "We are going to get dominated by the other teams," but I am fortunate to say that we were wrong. Our strongest point was the autonomous movement. It was not reliable and the robot managed to perform what we wanted it to do for the autonomous period only half the time. However, I think I figured out how I can go about fixing that issue, so I'm glad we had to chance to figure that out before the actual tournament.
I don't think our robot is very flashy in terms of the design, but it is a very high-capability robot in terms of scoring if we can learn how to navigate the field. Focusing on the two high-scoring objects on the field, the bowling ball and the magnet balls, we can score tens of points quickly if we can efficiently harvest these objects.
The people were pleasant as well. The referees were very informative and forgiving and helped us tremendously in understanding the rules. The players were very professional. Despite the stress that built up due to technical problems, they treated one another with respect and amiability.
The event eventually came to an end, and we packed up our robot and began our three-hour drive back home. We learned a lot of things through this scrimmage. I have high hopes for this tournament. Maybe we can push ourselves to go farther than we were able to with Zero Robotics. It'll take a ton of effort, but I think we can do it.
It's been a lot of work put into programming a bot for the zero robotics competition, but it came to an end today. We placed 14th among teams from all over the world in the semifinals, and cannot advance to the finals (11th among the U.S competitors. We had to be within top 9 among the U.S. alliances to advance.) It's been fun, and although I am sorely disappointed, I'm glad we made it this far! I wish I had known about this the year before. It was hard to find time to work on this competition with rigorous schoolwork, so few of us who were able to work on it.
I'm sad, but I have to be happy with what I've earned.
So, congratulations to the finalists and best of luck to you!
So, with new shipment going to the International Space Station, the deadline for the semifinals have been moved back by a week. Instead of a final code, they decided to make an optional code due last week to see how every team is doing. 17 out of 24 alliances, including our team, participated.
The Pirate Squad (our team) came in 6th, having scored 247 points (the leader scored 266 points). Not bad, but we still have plenty of work to do before I can feel reasonably confident that we have a shot at making it to the finals.
As always, I will keep you updated as the results for the semifinals are released!
A couple days ago, my friend Mike L. (the same guy who's part of the zero robotics team with me) and I were contacted by the mayor of Hartsville, South Carolina. He asked if we could develop an iPhone app for a funeral home.
I have never developed an iPhone app before, but the mayor's going to sponsor us with the money to get us started, so we said, "Why not?"
This seems like a great opportunity. I'll be doing my best to get him the app he needs. I'll keep you updated!
Here's something interesting that I've dug up from my hard drive.
This song, humorously entitled "Pterodactyl Love Song", is a goth(?)-techno-themed song composed and put together by me on FL Studio when I was in 10th grade. I did this over two hour and half class periods at my old high school (before moving to SCGSSM). I won the best song of the class award and a $10 gift card for iTunes! The song contains an analog drum set, a wide variety of synthesizers, and a few white and pink noises for effect.
Anyways, I hope you enjoy this little piece from the past!
For the past two days, I've been working hard to get the videos up and running! I was updating all my videos from its horrible quality to a version streamed directly from YouTube. That means you should be able to see all my videos in pretty good quality!
One day during the summer vacation before my senior year, I was really bored and also felt like rocking out, so I decided hook my amp up to my computer and start jamming on my electric guitar.
On top of that, I also felt like making a video and putting it up on YouTube. I couldn't see an easier way of doing that other than putting together a video of me playing my guitar. This video was the result.
The song is Big Blue, one of great songs from the video game series, F-Zero. I really love this music and because I grew up playing F-Zero, gives me a wave of nostalgia every time I play it. It's quite lovely.
Anyways, I hope you enjoy my performance and the music! All instruments (guitar and drums) were recorded and programmed, respectively, by me.
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.
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
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.
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!
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.
