XPRobotWars

An idea for a new XP hands-on tutorial, brainstormed at the end of XtC20011009, after several pints of the foaming stuff. We are planning to write user stories for XP Robot Wars at XtC20011023.

http://pefirst.narod.ru/sovtank.jpg

Participants program robots to achieve some goal in a shared virtual space. The space is displayed on a screen so that all participants can see the current state of play. Participants use XP programming practices to develop robot behaviour, including pair programming, test first and small iterations.

The ability of a team's robot to achieve the goal in competition with other robots acts as a "customer' with changing business requirements. Participants therefore get to experience what it is like on both sides of an XP project -- technical and business.

Further Thoughts

Because participants are continuously developing their robots, the game will have to be adapted from the simple gladiatorial combat of Robocode. There needs to be an incentive get the first robot finished as quickly as possible and then frequently release updates. E.g. the game needs to be "steady state" rather than organised as a series of rounds.

As the session progresses, we could add complexity to the environment. One obvious one is multiple robots for the same team, this would require communication so that robots don't attack/consume their own.

Some possibilities off the top of my head:

King of the Hill:Teams are ranked by how long their robot manages to stay within a certain area (the hill). This encourages the quick development of a first release that runs to the top of the hill and just stays there. Perhaps the whole arena could be the hill, in which case teams are ranked by how long their robot stays undefeated. This would encourage a quick first release of a robot that did nothing at all.

Ecosystem:Think of the classic "rabbits and foxes" simulation. Teams can create multiple robots. Teams are ranked by the proportion of the population is made up of their robots. The space also includes "plants" which grow slowly. Robots' actions expend energy, so robots must eat plants or defeated robots to survive. This encourages the quick release of an initial herbivorous robot that eats as many plants as possible, but would then require changing tactics to a carnivorous diet as plants became scarce and competition increases, and perhaps eventually to a cannibalistic diet (!) if most competition is eliminated. :~I'd prefer this because it would allow greater flexibility in the graphical theme -- e.g. replacing robot warfare with animals or a purely abstract setting. This would let the system be used teaching programming in schools, help it appeal to all genders, and help avoid potentially sensitive topics (such as warfare at this moment in time) --NatPryce

Links

Robocode Project:The homepage of the Robocode project on IBM's Alphaworks site. :~http://robocode.alphaworks.ibm.com/home/home.html Robocode community:A community site run by/for players of the game. You can download robot code from here. :~http://www.robocode.net/ Programming Games category in the Open Directory:There are a lot of programming games out there, but none seem to be real-time multiplayer games where participants can evolve their code during the game. :~http://dmoz.org/Games/Video_Games/Genres/Simulation/Programming_Games/ Q2Java:A Java API for extending Quake II. A possible display engine? :~http://www.planetquake.com/q2java/ The Tao of Soccer:AIs play soccer rather than kill each other. :~http://soccer.sourceforge.net/soccer/soccer.html Mind Rover:A commercial robot programming game with 3D graphics and a graphical programming language. :~http://www.mindrover.com/ Mini Mind Rover:Program a racing car on-line in this Java applet from the makers of Mind Rover. Demonstrates Mind Rover's graphical programming language. Cool! I'm in the Internet-wide top 10! --NatPryce :~http://www.cognitoy.com/minimindrover/index.html

The first version is likely to be based on Robocode. We have some other ideas too. We could retarget it at a Quake server (apparently, there's a Java API somewhere), and introduce increasingly complex worlds to play in. Personally, I would like to see us develop a little language to level the playing field and avoid some of the more time-consuming aspects of working in Java. We weren't particularly keen on visual languages.

We want to put a strong emphasis on achieving quality by writing test-first -- as against just pushing any old stuff out of the door -- so code failures should be fatal for a round, i.e. a null pointer exception will stop your robot. This should be a nice way of making explicit how quality and speed relate to each other.

We will also need some release tools -- within teams and to the game field. We could do this with scripts to start with, although I know OliBye would like to write an extension to Eclipse ;-) --SteveF

Java has the advantage that it is easy to write robots that communicate. If one robot has a reference to another it can try to cast that reference to an interface defined by one team. Java's class loading mechanism will make it impossible to cast to interfaces defined by other teams. Java security can be used to stop reflection and other cheats, such as opening network connections for interactive control. --NatPryce

Sure we should work on the JavaVM?, it's just that we might not write the code in Java

For release tools, we can use RMI to send objects to the central server, and let the server load the robots classes over the network on the fly. Or just share a file system and load dynamically like Tomcat In either case, we have to be careful to avoid race conditions where the dynamic loader pulls inconsistent class versions off the participants' machine while they are changing classes.

I get really scared when people suggest a new programming language for non-programmers that will be simpler. Those non-technical friends probably didn't understand the behaviours immediately - they probably just saw some shapes that they felt made sense in the context of the tank and agreed with each other. Maybe I was naiive, but I'm dismayed that UML has turned out like K&R C and Perl. There are lots of different people using different dialects for different applications. It works when people use as little of it as possible, exercising huge restraint. It's become far to big, splintered, messy, historical and political to be a really sharp tool. --DafyddRees