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
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
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.
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
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
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
![[Home]](/images/RoboWiki.png)