JMoe: The Mastermind

This isn’t what I intended to write about, but since it’s been my work this evening, I might as well. If you click here you can get a sneak preview of the new RFC Cambridge homepage. It’s a moderate redesign of the existing, but it converts everything to PHP (no more copy and paste and edit content!), with mod_rewrite hiding the ugly URLs. There are also a handful of new photos, the new sponsor rotor, and a bunch of other little tweaks (properly sized thumbnails make a big difference) that just make the page more webbish. It’s also almost all XHTML 1.0 Transitional compliant (I haven’t tested every single page, so I can’t quite say all, but all of the pages linked in the header are!). I think it looks a lot better (even though it’s very similar), and it appears that the rest of the team is happy.

Apparently, the way to get a website changed isn’t through drastic changes, but through small changes that everyone can agree on. I have yet to activate this as the actual full homepage, but that won’t take much (putting in one mod_rewrite rule). I just want to give it a bit of time for feedback from the team, and for anyone to find any links I haven’t updated to use the .rfc page (even though .htm will work, I don’t want to leave links floating). I still need to figure out if I want to add some breadcrumbs for navigation or anything, but I don’t think the site is complex enough to warrant it just yet. Maybe when we get a bit more of a network effect going.

RFC Cambridge is a Robocup team that is a joint effort between the MIT Competitive Robotics Club, and the Harvard College Engineering Society. We’re in our second year competing, with the international deadline coming up soon. For RFC, I’ve done a variety of different things. Last year, my largest single contribution was the refbox. Robocup uses a serial connection to send referee commands to each team. I developed a drop in component for our AI system that could read the commands from a serial port asynchronously. To avoid reinventing the wheel, it was composed of two subsystems. One was the serial reader, which read from the serial port, and placed any received values into a memory mapped file used as a buffer. The serial reader was in Managed C++, and used the Microsoft .NET serial reader class. Inside the actual AI was an unmanaged C++ component which read from the same memory mapped file buffer to read the commands.

Strictly speaking, the design was non-thread safe, and avoided issues mainly by having a guarantee that the input data could not exceed the size of the buffer, to cause a wrap-around race condition, and that each thread would never be in the same area. While not the best design, it was sufficient for our needs. Since the AI was reading the buffer every 33ms (or so), and there was no way possible that more than 255 commands would arrive in that 30ms, there was never an issue.

Another major unused contribution was a new pattern recognition system that was part of the vision module. This was to have been used to detect the location and orientation of each robot, using a “butterfly” pattern, rather than the much simpler two dot pattern that our team used. However, because of time constraints (it was written about 3 days before the competition, and fully integrated the day before the team left) it was not used at the international competition.

I also developed a small control system that allowed users to drive our robots with an Xbox 360 gamepad. This was useful for non-autonomous demos, as it allowed more effective control of the robot. It was done over the course of about two days, using C#, and a third party wrapper for the XInput technology with the Xbox 360 Gamepad for PC. It worked quite well, and was rather popular with people when we were doing demos at the MIT Activities Midway, as we could allow students to drive the robots, without any real training (one thumbstick to drive, the triggers to rotate), and it was fairly intuitive.

This year, I’ve been doing bits here and there, and will probably redevelop the 360 control system for our new platform (which is quite a change, but I’m not sure I can post about it just yet). Otherwise, I’ve mostly become the web guy. This is mostly because I know how to get at the servers (I didn’t make it complicated, that was someone else), and I’m one of the few people who has a lot of web development experience (4 years, including 2 years profesionally). This is the latest page I’ve done, which uses Lightbox, a rather neat little set of Javascript to display full size images as an overlay on the current page. I also redid the HTML for the main site, to replace a mess of tables from Dreamweaver with a CSS version of the same thing. It reduced the page size by about 50%, and also makes it much easier to read. I’m planning to port the existing content into some sort of script, so that changing one link doesn’t require editing every page, but that is a bit off yet (I need to sort out what the web server actually runs).

Schedules are a wonderful thing, rather like deadlines (I do love the sound they make as they go whooshing past). After a bit of consideration, I think I’ve come to a final schedule for updating. New posts will be Monday, Wednesday, and Friday. They’ll be reasonably short (about a page of text on my browser), and cover a topic in a reasonable amount of depth. Sundays will be the day of the long post, which will be more in depth, and probably at least to start, a multi-part feature where I lay out one of the ideas I’ve had for a game design. I’m not sure how long that will last, or how much material it will cover, but it will hopefully be something interesting.

Just so this isn’t an entire fluff post, I’ll also try to list some of the topics I want to cover in the coming week (with the first “real post” Wednesday [tomorrow {must stop using parentheticals, especially nesting them}]). This week, with two days left, I’ll do a post about Robocup (and some of the things I’ve been working on for that), and something else that will hopefully come to me on Friday. I think next week will be all posts related to the C# and the .NET Framework, covering some of the interesting areas (more specifically C# itself, XNA, and LINQ). As for the game design series, that will just have to wait, as I need to come up with a decent working title for the game itself.

iFind, a project of the SENSEable City Lab is an application designed for “Friendspotting”. It uses the ubiquitous Wifi coverage around the MIT campus to allow you to locate where you are pretty much anywhere on campus (minus a few buildings that we don’t have access point information for yet). The application then allows you to share it with whatever friends you want via an encrypted peer to peer link. This means that the information is shared only with who you want it to be shared with, and we as the operators of the iFind service have no information about your location (we can use a couple properties of the MIT network to guess which building you are in, but that’s it).
There are two parts to iFind. The shiny GPL licensed Java client, and the proprietary (sorta) PHP server. I was responsible for about 98% of the server code, and that’s what I’ll focus on, right after a pretty picture….

(yes, they were taken on a Mac. No, it’s not mine, the primary client developer uses it).
The iFind server is a relatively uncomplicated piece of code (around 25 files, and 35KB as a RAR archive), but there are a few interesting aspects. The biggest is that all communication with the server is done via XML. This creates what you could call an XML-RPC (Remote Procedure Call) system, although it isn’t nearly as flexible (aka complex) as other XML-RPC implementations. It is simply a custom defined protocol with a variety of messages that use XML to transfer the data and return the result. The entire protocol documentation is a 71KB Microsoft Word document (it does compress to 14KB as a RAR file though), which we keep somewhat private (it is available on request by sending a message to senseable-ifind [at] mit [dot] edu) to gauge interest. The server code will also be available on request for private use (pending a few agreements on release and such) for research and use at other institutions.
The other interesting aspect is the handling of requests. Once the server does some basic processing, and determines that the request is valid (well-formed XML, and including the expected method field), it passes off the request to an input handler. Input handlers extend a base class using the object oriented nature of PHP, which gives access to a variety of predefined methods and fields, such as an XML class for the output functionality. The advantage to this process is that adding a new method is as simple as adding a properly named file (the method name with no spaces and a .php extension) to the proper folder, and the server will handle requests. Any invalid requests will receive a generic error (either 100 Service Unavailable, or 104 Service Unimplemented) although the behavior is technically undefined (although it has no side-effects, and should not cause any problems or malformed output).
There are probably a few other interesting bits in the server code that I will run across while preparing it for the consumption of others (have to put in some comments and document how to extend it I suppose).

It is time for another term, and registration day has passed. The courses I will be doing this term are:

• 15.301 - Management Psychology Laboratory
• 14.01 - Microeconomics
• 18.06 - Linear Algebra
• 6.041 - Probabalistic Systems Analysis

Those may or may not be the exact course titles, but they’re close enough for most purposes. I’ll also likely be continuing my work at the SENSEable City Laboratory, most likely on the iFind Project. I might also try to find some other work on another lab project, but that depends on what is available, and how much time I have during term. There is also Robocup work to deal with (a big deadline is looming), and just making sure I keep up with courses.

This is a little more personal than usual, but I just wanted to get something written for today. Coming up next will probably be something about iFIND (as I haven’t discussed that yet), followed by hopefully the final Battlecode writeup (but that depends on their release of the Final Tournament matches). I’m hoping to get going on a Monday-Friday schedule for blog posts, but I may have to thin that to something like Monday, Wednesday, Friday. We’ll see how many ideas and how much time I have to keep this updated.

This is again a rather quick note. The developers (and sponsors) of Battlecode award a variety of prizes to teams for many different things. One was a prize for the most merciless (ie the team that hunted down and killed a defenseless, move and turn only) archon the fastest, while another was for the best team name. Blooregard Q Kazoo didn’t win either of those. We did however win the best formation award. This award was for our arrow formation which we would form above our archons to defend against EMP and air attacks. We also had the ability to fire out the center of the arrow, rather like a crossbow, or bow and arrow. We disabled this for the tournament, but it was coded and working. This earned us the best formation award, which was $200 and an iPod Shuffle.

The next post about Battlecode will likely be the last, and will contain our strategy document and descriptions of our matches (it may need to be two posts to avoid being too long). I will also hopefully have our final ranking from the tournament, so we can see if we improved (somewhat unlikely), stayed the same, or fell from our ranking in the seeding tournament. I feel that it is likely that we lost some ground, but probably not a lot. I know we didn’t finish in the top 16, which doesn’t leave a large margin to have improved, but it is probably possible.

Universe at War is a new RTS title being developed by Petroglyph Games. Petroglyph is composed of a fair number of the members of the former Westwood Studios, responsible for the Command and Conquer series, Dune, and various other games. I’ve been working fairly closely with them lately on developing their Community Site, which has involved things like setting up the forums, and building the website from an image concept. It’s been a lot of fun, and hopefully will continue to be an interesting relationship (I’m gearing up now to revamp the site with Universe at War content, and add a bunch of new features). If you’re interested in more about Universe at War, I recommend checking out the official site, or one of the many fansites.

I feel compelled to at least write a quick post noting that I am not in fact dead, but have been busy with Battlecode (see a couple posts down) for the past several days. Although the final seedings aren’t out yet, my team did reasonably well in the qualifying tournament, losing to two quality teams. We managed to win our first match against team General RAAM (after a bye), lose our second match against team Battletoads (the top ranked scrimmage team, seeded 9th), win our third match against team Global Warming, and lose our fourth match against team Little (to the third ranked scrimmage team, seeded 8th, beat us in seeding tournament). Battletoads was also one of the teams that finished in the top 8, so I don’t feel too bad about losing to them at all. After the final tournament (on Saturday) I will post our teams strategy writeup, and also hopefully go through our four matches, with some commentary on why we lost, and why the other team deserved to win.

Defense of the Ancients (All Stars) (or DotA for short) has been a recent hobby of mine.  DotA is a modified map for Warcraft III: Frozen Throne, which changes the character of the game fairly dramatically.  It is a map designed for 10 player games, with each player controlling a hero.  Each of these heroes is unique, and has a set of unique abilities.  The map is divided into 3 “lanes” each leading to an entrance to a fairly heavily fortified base.  Each lane receives waves of “creeps” which are AI controlled units.  These creeps are given the goal of breaking into the enemy base area, and destroying the enemy Ancient.  The goal of each sides heroes is, obviously, to prevent this from happening.  You purchase items and gain experience based on kills (of both creeps and other heroes). For more information, I recommend the DotA wiki article, and the DotA Allstars wiki article.

The uniqueness of DotA comes from it being an RPG in an RTS package. It is a very short, fast paced RPG, that is a modification of an RTS game. The core gameplay mechanics are very much RPG based (leveling up, earning gold, buying items), but it is much more fast paced than a traditional RPG (such as Diablo 2). This makes it an excellent LAN party game, and an excellent game for experimentation. With the wide variety (82 as of version 6.40) of heroes available, no two games are ever alike. The RPG mechanics are quite simple, but surprisingly addictive. You always want to try just one more round to see if you can get more kills, or find a better way to build up your hero (or just play another hero with -random).

The gameplay idea of a fast paced RPG is quite interesting, and something that could be fleshed out further. Games such as Dungeons and Dragons (or D&D) are a pencil and paper (and or tabletop) version of this type of game, but often take much longer, and are much more involved. However, the idea of a fast paced RPG with player designed characters (heroes in the DotA parlance) could be very interesting. The challenge is to find a way to balance the various hero skills so that one particular combination is not overpowering. This is something I hope to expand on in the future, and will maybe try to do some basic design work on a game based on this idea. Stay tuned.

With the basics out of the way, it’s time to delve a little bit deeper into some strategies for Battlecode. These are a few that have all been used by multiple teams, so I’m not giving away anything top secret here (especially after the seeding tournament).

• The Scout Tanker: With a low upkeep cost, scouts can be used to provide Energon to other units with a higher upkeep (EMP’s especially) to keep them alive longer. This can help to greatly extend the range of EMP’s. One of the most interesting applications of this could be called the Scout Railroad. It was a line of 10 scouts with one end anchored over the archons to pass up energon, who would feed any EMP that traveled along the rail to keep it alive. It wasn’t terribly effective, but looked impressive.
• The Archon Trap: Archons are a very difficult unit to destroy. Their health regeneration is able to match the damage output of a soldier with no problem, and can even survive two attackers with no difficulty if it is moving. The trick is to trap an Archon so that at least two, preferrably 3 soldiers are able to attack it. This can be done in corners, or with a large group of scouts along a wall.
• The EMP Wave: EMP’s are a dangerous offensive unit, and some teams simply used them as their only major unit. They would use Scout Tankers to keep the EMP’s alive, and send wave after wave of them at the enemy, hoping to cripple their energon production, and win that way.
• The Tank Assault: Tanks are a powerful ground unit, dealing major damage, plus splash damage. A pair of them can take down even Archons with little difficulty if they have a spotter. Teams that can move their archons, and locate the enemy without taking too much damage, and can get in range of a tank strike can be deadly.

There are of course many other tactics and strategies, but I don’t want to give away everything (as I do have a few ideas that I didn’t see implemented at the seeding tournament). Our team did quite well, being seeded 24th out of 137 teams. Hopefully that number can be improved in the final tournament.