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.
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.
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.
One of our projects that I have worked on for my Advanced Computer Science class at the Governor's School is a simple machine language assembler and compiler.
For the first part of my project, I coded an assembler that takes in four digit numeric commands and executes them. It can store up to a hundred lines of code, variables, and constants.
There is a set of instructions available for the assembler. They are very simple commands, hence the name of the project. The instructions are as follows:
10 Read – reads a word from the keyboard into the specified location in memory
11 Write – writes a word from the specified location in memory to the monitor screen
20 Load – loads a word from the specified location in memory to the accumulator
21 Store – stores a word from the accumulator into the specified location in memory
30 Add – adds a word from the specified location in memory to the accumulator
31 Subtract – subtracts a word from the specified location in memory from the accumulator
32 Divide – divides a word from the specified location in memory into the accumulator
33 Multiply – multiplies a word from the specified location in memory by the accumulator
40 Branch – sets the instruction pointer to go to the specified location in memory. ( branches or jumps)
41 BranchNegative – branches to the specified location in memory if the accumulator is negative
42 BranchZero - branches to the specified location in memory if the accumulator is zero.
43 HALT - the program execution is stopped.
For example, 1090 instruction orders the machine to get input from the keyboard and store it into address 90.
Once this was coded, my next task was to create a compiler that would take human language and covert it into machine-level language that make up the instructions that are passed into the assembler.
The compiler has several instructions that can be passed:
rem: Basically a comment function
input: Reads input from the keyboard. Serves the same purpose as the machine-level instruction 10.
print: Prints a variable onto the screen so that the user can read. Serves the same purpose as the machine-level instruction 11.
let: Computes a mathematical expression and makes it equal to the specified variable.
goto: Branches to a specific line denoted by its number.
if: Mandates a specific condition to be met in order to branch to the specified line.
end: Ends the program.
Bug testing and showing appropriate error messages were painful to accomplish. The let function of the compiler was also very difficult to manage, but it worked out in the end.
Here is the link that takes you to the code for the compiler, if any of you are interested in taking a look: CLICK HERE!
In case it wasn't clear as to what this program actually does: The Simple Language Compiler is something like BlueJ (java), Microsoft Visual Studio compiler (C), and even basic command prompt compiler batches. You can type commands in a text file and put that into the compiler. The compiler will then parse through your code and write it out in a language that the machine, or the computer, can read and execute.
Guild of Mercenaries was a two-week project that I worked on with a friend of mine during the Interim period in January.
My friend worked on level and model design as well as the storyline.
I was responsible for the programming, animating, and gameplay design.
We were quite satisfied with our results. The game itself is really simple, but still provides about 4-5 hours of fun.
The game features two computer-controlled teammates
who will assist you all the way to the end. As of current version, they
do not die, so you can use them as human shields if you need to. The
game features four levels of armor, three weapons, and a shield that can
be purchased at the shop. There are four towns, with three quests in
each, as well as an overworld area that serves as a pathway from one
town to another.
Your goal is to defeat the final boss. You will be
able to take on the quest that requires you to defeat him as soon as
you've finished all other quests. There are two types of enemies:
Melee and Ranged. Some quest-specific enemies exist as well, and they
tend to be more challenging than the regular enemies. Boss enemies
appear for final quests in each town.
On a side note, all sounds were obtained from Oblivion and Mount and Blade.
SPOILER:
The final boss music is from Call of Duty: Modern Warfare 2.
On September 3rd, the video game development club that I founded for my school has officially begun a project.
It's going to be a real-time tactics game with emphasis on unit micromanagement. As the designer, I wanted to take features from games like Frozen Synapse and merge them together with games like Company of Heroes.
I'll post more details to come as we continue to develop the project. For now, our goal is to have a playable version by the end of the year. Stay tuned!
Whew! It wasn't that hard to get this running. This blog will be dedicated to showcase my programs, games, and anything tech-related that I've worked on in the past few years. Although this was created with college applications in mind, others are always welcome to see what I've been doing!
