View source for User talk:Beaming
- [View source↑]
- [History↑]
Contents
Thread title | Replies | Last modified |
---|---|---|
Smart bots competition | 6 | 14:20, 16 January 2023 |
Robocode on HiDPI displays | 2 | 13:32, 16 January 2023 |
Bots starting position randomizing is not working | 10 | 15:50, 31 July 2018 |
How to keep roborumble running forever | 2 | 03:04, 4 April 2018 |
Melee client corrupted | 3 | 18:24, 31 October 2017 |
cpuConstant | 9 | 22:38, 17 October 2017 |
First page |
Previous page |
Next page |
Last page |
Increasing Processing Time Debate
Overall, the idea of increasing the processing time per turn for bots in the robocode engine is met with mixed reactions. Some see it as an opportunity to implement more complex strategies, such as better movement algorithms or enemy simulators. Others argue that the potential gains from these slower algorithms may be outweighed by the increased time needed for testing and development. Some suggest that a "FastBots" league, with a more reliable and stable control over processing limits, may be a more viable solution. Ultimately, it seems that the community is divided on whether or not increasing processing time would lead to significant improvements in bot performance.
— ChatGPT
As we know, there is hard (bad badly controlled) maximum processing time per turn allowed per bot imposed by the robocode engine. This pushes all of us to do the best in the allocated time limit. But as result some of potentially better but slower strategies do not show up at the top of the rating.
I am looking for a way to set/control allowed calculation time per in the rumble clients, in a hope to find the best among slow and wise bots. So we can start new rumble codenamed "wise slopokes". Additionally, it may spark new wave of interest among the kings of the rating authors.
What do you all think about this idea?
I like the idea of more processing time in order to attempt more complex stats, but to be honest I've tried some pretty complex stuff (including Spectral Clustering) for KNN on recorded data and nothing has beat simple KNN with a square kernel and weighted on sample distance. Not to mention that a lot of these algorithms aren't just a constant 50x slower or whatever, they essentially become unsolvable at sizes above ~500 data points, scaling quadratically or worse.
A problem with unlimited processing time is that it becomes possible to simply keep a copy of other bots and simulate them to determine where they will shoot/move.
Does anybody have any specific techniques that they would use if there was more processing time available?
I personally was aiming to a better movement algorithm. I.e. one can do better than 1 or 2 wave surfing. That would be super critical in melee, where you can track/react/predict more than just the closest bot.
Idea of enemy simulator is also attractive. I personally do not like clustering algorithms, I would rather prefer emulate and distill a subset of physically possible and optimal tracks for a current situation.
A clustering algorithm probably would seize to work once you apply it in melee, since you have to account for a neighboring bot subset as an input.I would think this would drastically increase the problem dimensions.
Displacement vectors of Voidious would be the closest to real emulation but it is still just an approximation.
I also have a crazy idea of a fine control of the motion, i.e. something more complicated than a simple go to a point which does not change for a several ticks. I want to have a path with smaller/different rotation angles and potentially speed which does not accelerate to max or min state. This produces a lot of possibilities for the paths and takes a lot of time to properly evaluate the danger. Of course it is overkill since such paths are often only 1 pixel apart.
I think DrussGT has a trick where at every several ticks the bot rotates to left and right, so the bot moves in wave like path. This confuses a linear targeting quite a lot.
Though, my goal would be to fit in between coming bullets with a fine control of a motion and also meet a wave with bot moving.
I had some movement algorithm things in the works, and they would have been more straightforward to implement with more processing time sure, but half the fun so to speak was coming up with the right optimization strategies to make it very fast.
Honestly, overall I don't feel like higher per-tick processing time would be too helpful at this point. My reasoning is, high level Robocode tends to require a very large amount of automated testing to know if some tuning was was actually an improvement or not. If the processing time limit was increased, it would also increase how long that testing takes.
Basically, I think the potential gains from slower algorithms are outweighed by the gains of faster iterations during tuning/development.
If anything I'd be more interested in a "FastBots" league, except I think the engine's control over the processing limit is too unreliable/unstable for that to be reasonable.
Well I wouldn't mind implementing full and proper n-wave surfing, right now Nene just does 2 wave surfing in simple way. Full n-wave would be very time consuming to calculate. But I am unsure of any major improvement it would bring to movement.
Hi I am trying to use my HiDPI laptop for robocode. But everything is super small. Is there a trick to scale everything up within Java? I am running it all on Linux.
I tried '-Dsun.java2d.uiScale=2' trick but it seems to have no effect on openjdk.
You are not the first to experience this problem.
Robocode 1.9.3.0 and its predecessors produced visual glitches with DPI scaling enabled (Bug-394). Fnl's workaround for this in 1.9.3.1 was to have Robocode disable DPI scaling entirely. Unfortunately, this causes the UI to appear very small.
The ideal solution, of course, would be to have Robocode support HiDPI properly. But that would mean changing a significant amount of UI code to take DPI into account, as well as modifying the graphics system so that the battle view can be scaled up arbitrarily high without losing quality. That would take a lot of work.
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page.
Return to Thread:User talk:Beaming/Robocode on HiDPI displays/reply (2).
Guys,
Can you double check it for me. I just notice that 1on1 rounds seem to have the same bot starting location. I.e. in 35 rounds battle, every round start (at least bot positions) are identical.
I see it in robocode-1.9.2.5
I see randomized start positions working in Robocode. Watch some rounds between Tracker and SittingDuck; you will see it.
All random here also. Stupid question (but just to be safe): No fixed position set in the properties ?
Bingo! It apparently was set somehow for one of the bots.
But I cannot even find how to setup it in the GUI. I spotted it in the config after your hint.
Looks like I was right, robocode opens some secret to people with more than 10 years of experience :)
I've looked into the newest robocode source code, but couldn't find where the robot start position settings are — except for the tests used by robocode itself. Could you still remember what config it was to fix start positions?
Edit: got it, it just hides behind some direct access instead of accessors.
the config is "robocode.battle.initialPositions".
Thanks for mentioning that feature anyway!
It is good that you find it. I already forgot what it was. Strange thing I did not remember to set it up, so some bug triggered it back then.
However, it doesn't work when set in robocode.properties.
And from source code I know that this config is valid only in battle files.
And with a bug of robocode, once you open intro.battle, then the first bot's initial position will be fixed as long as another battle file is not opened. Neither "New Battle" nor "Restart" works.
So did yours appear in robocode.properties?
Thanks for running roborumble for so so many years! I tried to do the same thing with my VPSs but roborumble client kept getting killed in a few days.
What's your settings to keep roborumble running for such a long time? Did you experience similar problems running roborumble?
Funny thing that I don't do anything special. I just run the clients on my own computers. They all currently have Debian stable (stretch) linux distribution with openjdk-8 java. The robocode is installed manually in my home folder.
I run clients in the 'screen' sessions, so if I get disconnected the session survives. From time to time, I restart it manually, mostly for selfish reason of a quicker bot list upadate. But the current run is almost 100 days straight without interruption. My machines have 4 to 6 cores, so I just do normal office load (browsing, youtube, short term calculations) on them as well.
One more thing. I just checked that I client consumes about 4GB of memory (including virtual one) after that 100 days.
I would suspect that VPS shares you CPU with other virtual OSes and kills CPU consuming process forcefully.
For many years that I run robocode clients, I never had any problem with sporadic crashes. The restart happens only if my home looses power and UPS runs dry.
Hello
I think one of your meleerumble clients is corrupted, since it is continuously re-running battles against old versions of Neuromancer and Firestarter. Normally a client should get new bots once every 2 hours, but it has been a few days since the Firestarter update and yours is still running the old versions. Could you investigate?
Thanks
Weird. The client was running battles with new version of bots but also attempted to upload ratings for the old ones. I cleared caches (files) and temporary (temp) dirs. Strangely enough I see the following at start up
Iteration number 0 Could not load properties file: ./roborumble/files/codesizemelee.txt Downloading rating files ... Downloading participants list ... Downloading missing bots ... Downloaded cb.fire.Firestarter 2.0d into ./robots/cb.fire.Firestarter_2.0d.jar Removing old participants from server ... Removing entry ... cb.fire.Firestarter_2.0e from meleerumble OK. cb.fire.Firestarter 2.0e retired from meleerumble Removing entry ... eem.EvBotNG_v11.0 from meleerumble OK. eem.EvBotNG v11.0 retired from meleerumble
Note that eem.EvBotNG v11.0 is 3 version behind, cb.fire.Firestarter_2.0e is one version behind.
I cannot figure out where does it read these versions since I cleared caches. My only assumption it is coming from the literumble. Am I right?
Nevertheless, despite the reported removal at the end of the battle I see
Fighting battle 0 ... fire219.CatBot 1.0,stelo.Spread 0.3,gh.mini.Gruwel 0.9,ara.Shera 0.88,wee.Gem 1.8.4,davidalves.net.DuelistNanoMelee 1.01,pedersen.Moron 2.0,zyx.mega.YersiniaPestis 3.1,emp.Yngwie 1.11,zyx.nano.BacillusComma 1.0 RESULT = stelo.Spread 0.3 wins, gh.mini.Gruwel 0.9 is second. Fighting battle 1 ... pedersen.Ugluk 1.1.1,florent.XSeries.X2 0.12,gimp.GimpBot 0.1,yk.JahRoslav 1.1,agrach.Dalek 1.0,lrem.Spectre 0.4.4,jcs.Seth 1.8,maribo.FollowFire 1,DTF.Kludgy 1.2b,franzor.Lizt 1.3.1 RESULT = pedersen.Ugluk 1.1.1 wins, DTF.Kludgy 1.2b is second. Fighting battle 2 ... stelo.WangRobot 1.0,dsw.StaticD 1.0,kurios.DOSexe .9b,jk.melee.Neuromancer 6.9,amk.Punbot.Punbot 0.01,oog.melee.CapuletDroid 1.1,lessonz.robocode.Oz 0.5.0,cs.sheldor.Talon 1.1,eem.IWillFireNoBullet v2.8,aaa.ScaledBot 0.01d RESULT = jk.melee.Neuromancer 6.9 wins, aaa.ScaledBot 0.01d is second. ... ... Ignoring: cb.fire.Firestarter 2.0e,cb.fire.Firestarter 2.0d,SERVER Ignoring: amk.Punbot.Punbot 0.01,cb.fire.Firestarter 2.0e,SERVER
Note that Firestarter was not even fighting the battles. Where is it coming from?
It all might be related to the sometimes observed appearance of two versions of the same bot in the rumble ratings which lingers for several hours.
Interesting, maybe it isn't your client uploading these bots then. Maybe it is User:Rsalesc? I should really add some more logging to the rumble so this kind of thing is more obvious.
Hi all, I decided to work on my skipped turns and to watch my execution time. As the first step, I recalculated cpuConstant according to cpuManager code (I wish it would be available from within the robot) at the beginning of each round. Guess what. The number wildly fluctuate. By wildly, we are talkin more than FOUR times!!! On the short end of the spectrum cpuConstant is about 8mS and it can be as large as 35mS.
Any ideas what is going on? Everything is done with openjdk8. One difference from the original code: I measure time with System.nanoTime()
Yes with Turbo Boost, CPU speed is not constant ;) And I think every new CPU should have something like that.
I would expect the cpuConstant go lower as turbo kicks in. But my first run usually gives lower number (faster speed), and consequent executions typically but not always are longer/slower.
In either case it is a problem. Recall recently discussed ThreadDeath issue.
Do you relay highly on GC? I mean do you create objects in loops? If the speed gets slower, I can only guess that would be GC.
Well, I do have many HashMaps and several kdTrees but the fact that Java kicks in with GC at random times is certainly an issue. The init round should be relatively low CPU event on my bot part.
Strange part is that robocode does not report 37 mS long execution as a skipped turn while my "official" cpuConstant is about 6mS.
Robocode gives robots extra time at the beginning of a round. In addition, most of this time is probably taken away by one-time setup and initialization code, making your calculated CPU constant longer than it should be.
First page |
Previous page |
Next page |
Last page |