Saving/HowTo - Robo Wiki -= Collecting Robocode Knowledge =-

I am struggling with adding persistence to my robot. Now I don't know a good way to see when the MatchIsOver. -- PEZ

static variables

The easiest way to save data between rounds is to make your variables static. There is no need to save data to a file and retrieve it. You usually store the enemy information you collected in previous rounds (if you need it later) or information stored in files that you need to read only once. -- Albert

As far as I know static variables in a Java class is shared among all instances of that class. Robocode creates a new instance of your bot for each round (and then calls the run() method), but since static variables are shared among all instances, your bot still has access to the data that was saved in the static variables last round. I'm not sure what this means if you have multiple instances of the same bot on the field though? --Zeb

In principle, multiple instances of the bot work OK. I'm not sure why (because they are the same class, they should share the data). My guess is that it is OK because they execute in different threads. -- Albert

I've found the answer in an old posting by Mat: http://www.alphaworks.ibm.com/forum/robocode.nsf/archived/5F86B09EE7DCA3E682798BC09C4B0950?OpenDocument It says that each robot is created by separate ClassLoaders?, with the purpose being that they should not share static variables. -- PEZ

I'm still a bit confused about what Robocode does between rounds. I have a static collection of enemies, each which get an instance of my robot when they are created. How come this robot reference is still valid between rounds? Isn't it a new instance of the Robot then? Or why would you need static variables for this otherwise? -- PEZ

Pondering and discussing with my colleagues I now think I know the the answer to this question: Calls like getHeading() are accessing static variables in the robot. My static collection holds a reference to an old and dead robot, but it shares those static variables with each new and fresh instance, which make it work. It's when you try calls like ahead() that things stop to work. -- PEZ

Serialization

Serializable means that a class can be converted into an array of bytes which can then be written to disk, sent over a network, etc. For a class to be Serializable it must (a) have no member variables which hold non-serializable classes and (b) implement the Serializable interface. The only real problem you can run into is if you have an object with a lot of references to other objects: when you serialize it, you''ll also be serializing and all of those objects, any objects that they have references to, etc. In an early version of Duelist I couldn't understand why my datafiles were about 40k per bot - turned out that one of the things I was serializing had a reference to my bot in it, so I was serializing EVERY object my bot used! :-P --David Alves

You use the transient keyword to indicate that a member variables aren't part of the persistant object. As long as you know how to reconstruct an "incomplete" deserialized object you just put transient in front of the variable declaration and it won't get serialized along with the rest of the object. Beware though that if you initialize a transient variable upon declaration you won't have the initialized value on that variable after deserialization. Like:

transient double largestX = getBattleFieldHeight() - getWidth() / 2;

The variable 'largestX' will have the value of 0 (zero) after deserialization. Now this particular variable you might want to serialize anyway. =) But you get the drift I hope. -- PEZ

You can also compress the serialized files. Kawigi shows how in CompressedSerialization.

Other

If you have your data in simple, primitive type, arrays you can store and retrieve that data compressed by using a variant of the serialization thingy above: WritingArraysToFile. -- PEZ

TIP:

OK, for some reason it refuses to allow me to copy this over from SavingDataHowTo?

If you are having problems saving data under 1.4.2, look here: JRE 1.4.2 SecurityException Bug

Is there a limit to the robot jar file size? Has anyone ever thought of recompiling the saved data? For instance a bot could fight a match against every other bot, and after every match the saved data could be translated into Java and compiled into a class file. The bot could contain a class file for every enemy, and all those class files could be put into the robot jar file. Although this jar file could be very big, it would get around the saved file size limitation and the bot could contain unlimited information on all the enemies. It could even contain the code for the enemies so it could work out exactly what the enemy is going to do. -- StefW

There is no limit to jar sizes (although the repository imposes a limit on upload sizes). This is something that *could* be done for pre-learned data - I think you can read stuff in your robot's package directory, but you can only write stuff to your data directory, which will hardly give you a valid classpath, plus, it counts in your data quota, so the bottom line is you don't have unlimited saving ability on robots you haven't seen before. Also, there's no real reason for it to be a jar or class file, since it doesn't count under your quota if it's not in your data directory - you'd just have to do some manual packaging to make sure it ended up in there (aside from that, you'll probably have a heck of a time creating classes in your robot code). -- Kawigi

I have actually thought of an extends robot that "saved" data by printing it out onto the output screen and then have the user put it in a class file that the robot called up. Just an idea. -- Kinsen

Well, if you could code repackaging and uploading, you could have the bot write classes on the fly. I actually built a program doing something similar to this. You just have the program write to a .java class file... -- Jokester

Anybody know *where* on the disk Robocode saves the data between battles? I've been hunting around for it and couldn't find it, and I don't see anything on the wiki about it. -- RobertWalker

If it's from a .jar file you put in the robots dir, it will be in something like Robocode/.robotcache/jarname/package/botname.data. If it's a dev version you're working on, it will be in robots/package/botname.data. -- Voidious