Difference between revisions of "User:AWOL"

From Robowiki
Jump to navigation Jump to search
Line 15: Line 15:
 
== Bots in progress ==
 
== Bots in progress ==
  
WS_LURE - I'm going to start on the gun soon. See above for details.
+
GT_Lure - See above for details.
  
WS_LURE checklist:
+
GT_Lure checklist:
WS:  
+
GT:  
 
Get in positions to make cornering easier [] (Ex: Move towards enemy bot, he moves back. It recognizes this and backs him into a corner, and then it dodges its bullets and subsequently pelts him)
 
Get in positions to make cornering easier [] (Ex: Move towards enemy bot, he moves back. It recognizes this and backs him into a corner, and then it dodges its bullets and subsequently pelts him)
  
LURE:  
+
Lure:  
 
Fire slightly left or right of an opponent to force them in a certain direction (lest they be hit and soon learn not to move that way, possibly making them move the other way and into the corner) []  
 
Fire slightly left or right of an opponent to force them in a certain direction (lest they be hit and soon learn not to move that way, possibly making them move the other way and into the corner) []  
 
Know when to fire and how hard to fire (Luring-fire would be <=1, attacking/harassing/chase bullets would be power 2 or so, fires only when it recognizes enemy's pattern and knows if it will move or get hit) []  
 
Know when to fire and how hard to fire (Luring-fire would be <=1, attacking/harassing/chase bullets would be power 2 or so, fires only when it recognizes enemy's pattern and knows if it will move or get hit) []  
Line 29: Line 29:
  
 
Random rambling on standard templates:  
 
Random rambling on standard templates:  
For a template, it should contain everything I'd need for a standard, fighting bot. As in, mainstream, not gimmick. In case I want a gimmick bot (ex: a dodge-only bot, rambot, things with specialty), I should make the code modular and ''not'' hard-coded and tough to root out, so that I can easily implement the gimmick. As for mainstream bots, it should have at the very least a power management algorithm placed into another algorithm that calculates the chance of hitting (I think it could be useful :<), and after that, a method that lets it avoid walls. I don't know about the movement; should I always code it from scratch? Wavesurfing is a rather common, very effective form of moving. If I implement a form of wavesurfing in the template, it could be difficult to root out, since I might want to implement a custom movement pattern, like an oscillating rambot strategy. So, I guess my solution will be to just save a few wavesurfing/generic movement variants in text documents, so that I can copy whatever I need. As for targeting, I'm not too sure what should be the standard. If I made the standard very specific I wouldn't have much variation with my mainstream bots, now would I? I guess I'll just have complicated guns saved up in more docs (Yeah, I'll just turn into a human [[SpareParts]]. Har har). And of course, all this is really theoretical. It means jack sh@% if I don't do anything, so I guess I'll work on all these things at school and when I feel like being productive >_>
+
For a template, it should contain everything I'd need for a standard, fighting bot. As in, mainstream, not gimmick. In case I want a gimmick bot (ex: a dodge-only bot, rambot, things with specialty), I should make the code modular and ''not'' hard-coded and tough to root out, so that I can easily implement the gimmick. As for mainstream (real fighting) bots, it should have at the very least a power management algorithm placed into another algorithm that calculates the chance of hitting (I think it could be useful :<), and after that, a method that lets it avoid walls. I don't know about the movement; should I always code it from scratch? I think I will; I have a lot of ideas for bots, and their movements are all going to be different. As for targeting, I'll probably base guns on other bots, but of course always have my own spin on them. Gun power management will also always be different, but for the most part power management will be mostly the same, so I'm good there.
  
 
== Random Ideas ==
 
== Random Ideas ==

Revision as of 20:41, 16 November 2010

Hi. I'm AWOL. I'm an amateur programmer (Started learning C# and Java a while ago) but this game is helping me learn Java pretty quickly. I'm a simple person, so I don't know how to do all the advanced tactics you guys use, but I damn well like thinking of new ways to mess with my enemy's head (circuits?) :P


Bots Made

OMT_HO - Named for its tactics: Orbiting Musashi Trick and Head-on targeting. More of a test bot really, to see what I can do. Uses a gravitational sort of movement to stay in a set orbit around its opponent. 1 vs 1 only, best on the 800x800 battlefield.

WS_LURE - Named after a specialized Wave surfing (Something like that) movement that will try to move any anti-gravity opponents into corners and dodge bullets efficiently; and a neat specialty pattern-matching gun I'll call the Wall/Corner Lure, which will fire at one side of a any other 'learning' bot (Dynamic Clustering/Wave surfing/Pattern matching/it'sallthesametome) to force it to move into a wall or corner, and then shoot it to death. It's going to be a really neat bot that will dodge as many bullets as it can and still trick its opponents into being rammed into walls. It will be designed to save as much of its power as it can (Firing power 1 or 2 shots constantly to harass advanced dodgers, avoiding walls while tricking others into them) while whittling down its opponent's via wall damage and constant, quick shooting.

Bots decommissioned

OMT_HO - OMT_HO is pretty good as it already is, even if it can't beat everything. I experimented with using Circular targeting on this bot, but it never worked out so well. In fact I only wanted Circular targeting just so I could beat HawkonFire, lol. I'll revert it to head-on targeting one day and release it and its source code for download.

Bots in progress

GT_Lure - See above for details.

GT_Lure checklist: GT: Get in positions to make cornering easier [] (Ex: Move towards enemy bot, he moves back. It recognizes this and backs him into a corner, and then it dodges its bullets and subsequently pelts him)

Lure: Fire slightly left or right of an opponent to force them in a certain direction (lest they be hit and soon learn not to move that way, possibly making them move the other way and into the corner) [] Know when to fire and how hard to fire (Luring-fire would be <=1, attacking/harassing/chase bullets would be power 2 or so, fires only when it recognizes enemy's pattern and knows if it will move or get hit) []

robocodeRobotTemplate: Just a template for all of my bots. Working on things that I'll use for all of my regular bots, ex. Melee/1v1 switching radar (if I feel like making an everything-bot like Shadow), firepower management, etc.

Random rambling on standard templates: For a template, it should contain everything I'd need for a standard, fighting bot. As in, mainstream, not gimmick. In case I want a gimmick bot (ex: a dodge-only bot, rambot, things with specialty), I should make the code modular and not hard-coded and tough to root out, so that I can easily implement the gimmick. As for mainstream (real fighting) bots, it should have at the very least a power management algorithm placed into another algorithm that calculates the chance of hitting (I think it could be useful :<), and after that, a method that lets it avoid walls. I don't know about the movement; should I always code it from scratch? I think I will; I have a lot of ideas for bots, and their movements are all going to be different. As for targeting, I'll probably base guns on other bots, but of course always have my own spin on them. Gun power management will also always be different, but for the most part power management will be mostly the same, so I'm good there.

Random Ideas

Automatic wavesurfing: There should be areas you really wouldn't want to be in when the enemy fires. When the enemy fires, you try and predict their line of fire that your enemy's shot would go, akin to wavesurfing. For example: When you detect a shot, the most obvious line of fire not to be in is where you last were; The head-on targeting line. Next would be circular and linear targeting lines; you don't want to be caught in those spots either if you're on the move. Once those simple spots are out of the way, you can beat bots with simple firing methods even more easily. For other not-so simple ones, I guess real wavesurfing would be good.

Melee bullet prediction: Ah, now this is interesting. You can't scan every bot in a melee, so you won't know each and every ones' shots. But, here's the catch; let's say you have a nice array of your opponents. In each of them, you store a few things: Energy since last scan, position since last scan, their last firepower (acquired from last scan and a recent scan), the amount of time passed since last scan, their average velocity from scans, and their cooldown time until next shot (updated every tick by subtracting 0.1). How would you use them? Simple: Create virtual bullets of them. But AWOL, you can't do virtual bullets in a melee! It's unpossible because there are too many bots to scan! Well, here's the solution: You make virtual bullets by simulating their cooldown rates, and by predicting that you can pretty much predict where they would have been at the time they fired so you can avoid their possible bullet. Alright, so here's an example of what the array would look like in a sorta base code:

LAST = _Enrgy-67; _pos-(45, 228); _power-3; _time-40; avgVel-5.2; _heat-15.0; // Example enemy Melee bot stats

public void onScannedRobot(ScannedRobotEvent e) {
//Stuff here, I forget

VBullet vbul = new VBullet(_power, firedPosition(e)); // VBullet would calculate and update a virtual bullet from the enemy's position,
firepower, and your own position

}

public Point2D.Double firedPosition(ScannedRobotEvent e) {
// Take the enemy's last known position and gun heat, then use his average velocity to calculate where he would have been when his
// gun heat lowered to 0. Get what I'm saying?
// Take heat, lower it to 0 while calculating his position at the time frame, and use his average velocity to find correct position.
// distance = vel*time
double _h = _heat * 10;
double enPosOffset = _h * avgVel; // Actually I'm not too sure this would work. Needs to be in proportion with the enemy's current position
// or something... Bah, I forgot what I was going to type. Har.
}

public void updateEnemy(ScannedRobotEvent e) {
if(e.getEnergy() - _Enrgy <= 3)
     _power = e.getEnergy() - _Enrgy;
_Enrgy = e.getEnergy();
if(_heat == 0)
     _heat = (_power*5)+1; // Reset their gun heat, assuming they fire at a constant variable.
else _heat -= 0.1;
_time = 0;
// Actually there should be things that update without this method, like the cooldown part should be in the main code or something.
// But you get the main idea. I might work more on this code in a big project some day. Or you can try to complete it!
// Go ahead if you want to. Just tell me if you do.
}