And in the second year the word of the Lord came to Ether, that he should go and prophesy unto Coriantumr that, if he would repent, and all his household, the Lord would give unto him his kingdom and spare the people—Otherwise they should be destroyed, and all his household save it were himself. And he should only live to see the fulfilling of the prophecies which had been spoken concerning another people receiving the land for their inheritance; and Coriantumr should receive a burial by them; and every soul should be destroyed save it were Coriantumr.
And it came to pass that Coriantumr repented not, neither his household, neither the people; and the wars ceased not; and they sought to kill Ether, but he fled from before them and hid again in the cavity of the rock. ([Ether 13:20-22])
And so it happened, Coriantumr was the last survivor of this war. This robot was built with the same idea in mind - be the only one alive when the dust clears. I've long thought that if I could make a great melee bot, I would name it Coriantumr (in fact, I've probably started bots called "Coriantumr" three or four times before this, but none embodied the name). I'd like to think that this is that bot.
Kawigi - I was liberal, however, in researching ideas through the wiki and repository and in the code of a few reasonably good melee bots.
You haven't robocoded until you've tried to make a melee strategy that works.
https://www.robocoderepository.com/BotDetail.jsp?id=1988
I think it might be a candidate for #6 or so on the general melee rumble, #2 for minibots. Time will tell, though.
With a couple days of time, it has shown. Version 1.0 is currently:
It uses MinimumRiskMovement. Conceptually, it's not a whole lot different from FloodHT, but the implementation is completely different. The thing I like about the implementation is that it has some coherence and consistency, but is able to change its mind in mid-move, too. I'd have to post the entire findRisk method to really elaborate how it evaluates movement vectors, but if you're interested, read it yourself. It's fairly documented. Basically, every tick it looks at around 60 points at a uniform distance around it, and if any of those points are better than the point it's currently driving to, it will switch to go toward that one. This way it is able to react to changes in its environment quickly, but it is tweaked to still mostly continue in the same direction for most of the distance to its destination.
It uses a guess factor gun that is segmented differently between melee and one-on-one battles.
Dodge bullets?? Coriantumr is mostly trying not to get shot at in the first place. When being shot at is inevitable, though, it just sort of moves perpendicular, usually avoids head-on aim fairly well, and stays away from its opponent as much as possible without risking being targeted by others.
There are a few movement tweaks to improve its OneOnOne performance, but most of the movement code in this robot is centered around avoiding confrontation in melee. Its targeting is also different between the two - it's first segmentation axis is whether or not it's in a melee battle. Its third is bullet flight time. The middle one is acceleration in one-on-one, or lateral direction in melee. By lateral direction, I mean whether the opponent is moving toward, away from, or laterally from me.
It usually attacks the closest enemy to it, but it tries not to change targets in the middle of aiming. It tries to avoid everyone, if possible - Coriantumr is only happy when it is in a position where every other robot has a better target than Coriantumr.
Saves stat buffers for each opponent between rounds, nothing between matches. I tried to add data saving and loading, but it was too big, so I used the space I had elsewhere.
See the top. He's an interesting warrior from the Book of Mormon ( https://scriptures.lds.org/bm/contents ). Look in the Book of Ether, starting at the end of chapter 11.
The code is released under the KawigiPublicLicense. You are welcome to use it, but not to make an even better bot with it and beat me. I know, it's a strange license agreement. I release the source because I think it will help people understand what MinimumRiskMovement is all about, since there doesn't appear to be a large number of open-source bots who use it. Coriantumr's evaluation of whether it will become a likely target for other robots embodies MinimumRiskMovement in such a way that it is no longer just an implementation decision for AntiGravityMovement.
Find some space for either better one-on-one movement or a cool victory dance.
Not really sure. My bots have usually had trouble with shinh.Entangled in melee, but I'd say the goal I had with this robot was to reach the level of Nimrod and HawkOnFire.
FloodHT, HawkOnFire / GlowBlowMelee, little code ideas from Troodon and Nimrod, little hints David Alves wouldn't give me about DuelistMiniMelee.
nice bot, nice name, and a really remarkable OneOnOne result!!! -- rozu
Lol, thanks - I'm a little surprised about the OneOnOne result, actually, but its LRP graph tells the story. It has an outstanding gun, on the level of FloodMini, that it uses for one-on-one, and crappy movement that mostly stays off of GF 0. But where it seems to do better against the lower bots one-on-one, it seems to do better against the better bots in melee. -- Kawigi
Just found your page on MinimumRiskMovement... DuelistMiniMelee 1.1 and 1.2 both use a flavor of that. Looking wayyyy back, that's what was responsible for this: https://tobe.homelinux.net/robocode/MiniBots/m20030112.html At the time, nobody else was doing anything like it, at least not in the minis. :-) --David Alves
LoL?, you owned the field at that point in time I guess. Be on the look-out for Shiz (the micro-version) and a new version of Coriantumr soon - I think I came up with a way for it to avoid a little better, and even leave some extra room for better one-on-one movement. -- Kawigi
"And it came to pass that Moron did overthrow him..." - my new favorite religious passage, from right before the bit about Coriantumr. :-) --David Alves
Here's what melee testing can be like:
And so great and lasting had been the war, and so long had been the scene of bloodshed and carnage, that the whole face of the land was covered with the bodies of the dead.-- KawigiAnd so swift and speedy was the war that there was none left to bury the dead, but they did march forth from the shedding of blood to the shedding of blood, leaving the bodies of both men, women, and children strewed upon the face of the land, to become a prey to the worms of the flesh.
And the scent thereof went forth upon the face of the land, even upon all the face of the land; wherefore the people became troubled by day and by night, because of the scent thereof. ([Ether 14:21-23])
This bot is beginning to get on my nerves. For some reason it keeps getting about 10% better accuracy (speaking about absolute numbers!) than Spectre. I tried to change my sanity check (the thing about checking whether enemy can realy get to the predicted GF) to your way and it got even worse. And the thing that made me fall of my chair is that when I plugged segmentation out of Coriantumr, it got even 3% better accuracy! This must be some black magic, or I have to change the testbed... --lRem
Sounds like you might have a bug, but also - do you use Coriantumr's radar lock (i.e. lock on your target for some number of ticks before you fire)? Accuracy isn't only about your gun. And Coriantumr's segmentations aren't bad, in either melee or one-on-one. -- Kawigi
I think I've read every single line of the code about ten times, so it could be some problem with concept, probably radar. Still I like my radar, it spins more than Coriantumr's and still delivers me a scan before every shot. But I'll check whether 6 scans help, thanks for the suggestion. --lRem
Also, if you want to shave off a byte or two, I think in the line where you set myLocation to your location, instead of:
myLocation = new Point2D.Double(getX(), getY());you might want to do
myLocation.setLocation(getX(),getY());I'm not sure if it reduces codesize though. --Starrynte
I will also suggest changing your findRisk() function slightly. Right now, when determining which bots are closer to a certain bot (to find out who is probably shooting at you) you are not checking if the current bot you "iterated to" is the certain bot! I hope you understand what i mean --Starrynte
I have so many thoughts for Coriantumr today! Anyways, if a bot is dead you will still act like it's there... --Starrynte
![[Home]](/images/RoboWiki.png)