CTanks

This is a programming game, inspired by Crobots by Tom Poindexter (http://www.nyx.net/~tpoindex/crob.html). Players write programs for tanks, with the intent to seek out and destroy other tanks.

Output is a JSON object, and some scripts are provided to wrap the object up in a web page.

Included programs

I tried to stick with the Unix philosophy of one program per task. I also tried to avoid doing any string processing in C. The result is a hodgepodge of C, Bourne shell, and awk, but at least each piece is fairly simple to audit.

round.sh tank1 tank2 ...

Runs a single round, awards points with rank.awk, and creates a new summary.html with summary.awk. This is the main interface that you want to run from cron or whatever.

forftanks tank1 tank2 ...

A program to run a round of tanks and output a JSON description of the game. This is what tanks.js uses to render a game graphically. The object printed contains:

[[game-width, game-height],
 [[tank1-color, 
  [[sensor1range, sensor1angle, sensor1width, sensor1turret],
   ...]],
  ...],
 [[
  [tank1x, tank1y, tank1angle, tank1sensangle, 
   tank1flags, tank1sensors],
  ...],
 ...]]

If file descriptor 3 is open for writes, it also outputs the results of the round to fd3.

rank.awk

Processes the fd3 output of forftanks to award points and output an HTML results table.

summary.awk tank1 tank2

Creates summary.html, linking to all rounds and showing overall standing.

designer.cgi

Accepts form input and writes a tank.

Building from source

You should be able to just run "make". The C is supposedly ANSI C, and might even compile on Windows. I've built it on Linux, with glibc and uClibc, big- and little-endian.

History

This is a port of the "Tanks" program written by Paul Ferrell pflarr@clanspum.net in 2009-2010. Paul created the entire game based off a brief description I provided him of Crobots and a vague desire to "make something fun for high school kids to learn some programming." We ran Paul's Tanks as part of a 100-attendee computer security contest in February of 2010 and by all accounts it was a huge success. It even made the nightly news.

Paul's version was written in Python and provided a custom language called "Bullet", which looked like this:

>addsensor(50, 0, 5, 1);        # 0
>addsensor(100, 90, 150, 1);    # 1
>addsensor(100, 270, 150, 1);   # 2
>addsensor(100, 0, 359, 0);     # 3

# Default movement if nothing is detected
            : move(70, 70) . turretccw();
random(2, 3): move(40, 70) . turretccw();
random(1, 3): move(70, 40) . turretccw();

# We found something!!
sense(3): move(0, 0);
sense(1): turretcw();
sense(2): turretccw();
sense(0): fire();

Nick Moffitt played with this original version and convinced me (Neale) that something like Forth would be a better language. I added some code to accept a scaled-down version of PostScript. The IRC channel we frequent collectively agreed to give this new language the derisive name "Forf", which should ideally be followed by punching someone after it is spoken aloud. I wrote a Python implementation of Forf, which was slow, and then Adam Glasgall wrote a C implementation, which was quick.

I decided to take Tanks to Def Con in July 2010, and just for bragging rights, to have it run on an Asus WL-500gU. This is a $50 device with a 240 MHz MIPS CPU, 16MB RAM, and a 4MB flash disk, along with an 802.11b/g radio, 4-port 10/100 switch, and an additional 10/100 "uplink" port; it's sold as a home wireless router. I had originally intended to run it off a lantern battery just for fun, but eventually thought better of it: doing so would be wasteful for no good reason.

Aaron McPhall amcphall@mcphall.org, my summer intern at the time, got OpenWRT and Python onto the box and benchmarked it at about 60 seconds for a 16-tank game, after he had profiled the code and optimized a lot of the math. That wasn't bad, it meant we could run a reasonably-sized game at one turn per minute, which we knew from past experience was about the right rate. But it required a USB thumb drive to hold Python, and when we used the Python Forf implementation, the run-time shot up to several minutes. I began this C port while Adam Glasgall, another fool on the previously-mentioned IRC channel, started work on a C version of a Forf interpreter.

This C version with Forf runs about 6 times faster than the Python version with Bullet, on the WL-500gU. A 1GHz Intel Atom runs a 16-tank game in about 0.2 seconds.

What's so great about Forf?

Nothing's great about Forf. It's a crummy language that only does integer math. For this application it's a good choice, for the following reasons:

• No library dependencies, not even malloc
• Runs in fixed size memory
• Not Turing-complete, I think (impossible to make endless loops)
• Lends itself to genetic algorithms

Author

Neale Pickett neale@woozle.org