Editing revision 29 of OpeningGame

Robo Home | Changes | Preferences | AllPages

Editing old revision 29. Saving this page will replace the latest revision with this text.

When each round starts you are knowledgeless and unable to fire for the first few ticks.
These first few ticks are just movement and radar, trying to get the best start possible.  While only a few ticks dont seem to be very significant, many matches and challenges fluctuate on who has the better start, so proper opening game will help you succeed.

The first thing that all robots do is spin their radar. This is where the first question jump can take place. Instead of spinning your radar the same direction every time, it will often be better to spin in the direction where you cover the most battlefield.

If in melee, many bots utilize a corner movement strategy.  So it could be useful to start for the nearest corner immediatly at the start of battle. For OneOnOne, it may be desireable to move away from a wall or corner that you may have spawned in.

As an alternative, your radar can spin faster if your bot and or gun are spinning with it, so this may be an effective strategy if you spawn in your desired location or do not mind about your spawning location.

And of course, there is the option of doing nothing at all, spinning your radar until you have a scan and then starting your movement strategy.

From this point, One can also implement a provocative movement for the beginning of the round or match to taint their targeting systems and try to get the energy advantage.

Finally, once the initial cooling is complete, you can fire lower powered bullets at the beginning of rounds or the first rounds of a match to get as much information as possible.
-- [[Jokester]]
----
What your robot does before it detects the enemy and before the initial bullets are fired.

During [[Ender]]'s development i noticed some bots start moving immediately. Some towards the center, some towards the walls. Does it give them an edge? I would think so but i have not tried it myself yet. ---[[Vic]]

I think that it differs from where your bot gets its move instructions. Some bots do it in the run() method (thus they might not know where the enemy is before moving) and some from the scanned robot event. As long as we are talking OneOnOne I think it's best to go for the latter and start your ordinary movement directly and put code in there to correct any positions your bot doesn't like. [[Marshmallow]] takes this path and evades if the enemy is too close, no matter if it's in the opening or mid game. -- [[PEZ]]

Good differentiation! You're right that once you scan the enemy my ordinary movement should immediately take over. I was about to create a special state from the initial non-firing period but as you pointed out correctly my normal movement should take care of any distancing at that stage.

So that leaves the first 1-9 ticks before the first scanned robot event. Would it be nitpicking to start moving here already? or does it give you a slight edge? Maybe someone out there has spotted a slight improvement (or even degradation?) in a 5000+ match when adding initial movement. -- [[Vic]]

I have experimented with it '''a lot''' and always ended up degrading the performance. That doesn't mean it doesn't work though. But the guns are warm at the start so I don't think those 9 ticks matter. As long as you don't know where your enemy is the possible movement vectors that are bad outnumbers the good ones (I think). -- [[PEZ]]

The only observation I've really made on this is from the fact that the Flood bots don't move at all in the first round until a bullet is fired.  If I'm really close to my opponenet, this could potentially be bad (of course, I'll get a good shot at him more than likely).  But it can also be funny against bots that don't start firing right away.  Pit [[FloodMini]] and [[Cigaret]] together, and you'll notice that [[Cigaret]] doesn't start firing until he has enough in his pattern buffer to make an intelligent shot.  Of course, [[FloodMini]]'s movement is completely triggered by enemy fire, so he sits there and starts shooting at [[Cigaret]] (possibly even hitting him once in there), and by the time [[Cigaret]] really does fire, he knows no more about how I'm going to move than he did at the beginning of the match.  As such, whatever the outcome of the match, you'll see [[FloodMini]] win most first rounds against [[Cigaret]].  -- [[Kawigi]]

Thanks for all your feedback! Right now i'm inclined to go with being still until the scanned robot event. I think i'll run a test sometime soon. I'll post the results here. --[[Vic]]

Interesting... I've thought a lot about the OpeningGame the past few weeks. I think the best way that would seem to work for me is to not move at all until a recently fired enemy bullet is within range of hitting you. In other words, it will not move right through the initial gun heat, will not move even when the enemy starts firing, and will not move until the first enemy fired bullet is within about distance/bulletspeed-10 ticks from it (perhaps this could be made to go as far as calculating with the tank width to wait the exact number of ticks before it is necessary to move). Turning the tank perpendicular to the enemy is the only action it will take before it is in danger of being hit. When starting at long distances this may give it a bit of an advantage, possibly tricking the enemy into wasting several high-powered bullets at the stationary target before starting it's movement. This of course would only apply to OneOnOne.

Also, it's interesting that your bots take action in onScannedRobot; my new bot, as SineSweep was programmed and as Cake is programmed (iirc), take no action whatsoever in onScannedRobot. The onScannedRobot events are simply collected by an event handler class, and dumped into the data arrays for those robots. All of the robot's systems are entirely independent of scans; this allows the robot to collect scans from teammates, or iterating the enemy position manually and simulating a scan, and dumping all this data into the arrays without the robot having to differentiate between a normal scan, a team scan, and a simulated scan. The same will go for all of my new bot's events, including hitting walls and robots, all bullet events, etc. I've always disliked event-driven programming; all my real bots are designed to simply collect the data through events, and then poll for it within the normal loop. -- [[Vuen]]

That's actually much how the events are intended to be used. [[Marshmallow]] also mainly updates state fro mthe events and do calculation and such from the main loop. Though, I have recently made the  actual movement action calls (like setAhead) be called from the scan event, simply because it makes my robot behave much better. Unlike you, Vuen, I like event driven programming and I often find myself creating new event classes. Again, inside the event handlers of those classes it's about changing state. But the classes are a neat way to create something like closures. -- [[PEZ]]

I personally feel that, since guns are hot, this doesn't matter at all. However, if you feel the need, or if there comes a competition with an extremely high cooling rate, spinning your gun along with your radar would increase your radar turn per tick to 65 degrees, if I understand this correctly. This could reduce your time to scan the battlefield to 5.5 ticks (roughly), meaning by the sixth tick you've found everyone, putting you three ticks ahead. Of course, again, in my opinion this is foolish, just something that came to mind. -- [[Kuuran]]

Something I have been thinking about in the opening game is using ProvocativeMovement to gain and an energy advantage on your opponent and then slipping back into your normal movement pattern. Having watched about a zillion battles recently trying to improve [[Jekyl]]'s near wall performance, I have noticed that with top bots the winner seems to most often be the bot that gets the first hit. If a bot gets the first two, it is pretty much over. I think that in the opening game a ProvocativeMovement system could be used to induce your enemy to miss giving you a critical edge to get over the 2 hit hump. I am not sure where the point of switching back is, and you would still need a relatively effective movement system to switch back to. I would probably switch back if I got a 30% energy advantage for starters and see if that could be dynamically shrinked to as small a number as possible to delay/cloud learning the ProvocativeMovement segment. Thoughts? --[[Sparafucil3|jim]]

I have no immediate comment on whether this is worth the while or not. But it's interesting to see that you, like me, observe many battles and try to figure from it. -- [[PEZ]]

I don't have a ton of experience yet, but one obvious strategy is to start by spinning your robot, its turret, and
the radar clockwise (for example.)  This will increase the radar's scan rate from 45 degrees per tick to 45 + 20 + 10
= 75 degrees per tick, meaning you can scan 300 degrees in 4 ticks and a complete scan in 5.  This is a 2-3 tick improvement on just sitting still and spinning the dish.  While you won't be able to *shoot* anybody any faster, you
should be a little faster out of the blocks.  Also, you'll be able to move about 60 pixels before you'll be able to
fire, so perhaps you should try to ram somebody, particularly in a melee.

ramming in melee doesn't sound like a very good idea to me. --[[andrew]]

Well, there are two good reasons not to ram in melee (unless of course, you're down to the last two bots, maybe) - first, it's not as energy-efficient as firing, and second - bullets not even directed at you, but at the robot you're ramming, may hit you (aside from the bullets actually aimed at you). -- [[Kawigi]]

Are there any bots yet that determine the probability of geting a bullet hit based on arena size, current number of bots, and positions of bot and gun direction?

For example: My bot is in lower left corner with gun aimed at upper right corner. If the number of bots is high enough and the arena size is small enough then a power 3 bullet will always hit enough times to give me some pionts, even if I don't scan at all, based on probability. -- [[RobocoderDan]]

I do not know if anyone has tried this specifically but I would not be suprised to find out that someone has done something similiar in the past. Usually in melee battles people tend to be busy defending their "turf" or trying to stay out of trouble as there are lots of points to be earned by survival. Having said that, I think your idea has some merit if you can figure a way to implement it. one possible solution would ne to draw an arc from your position out to the edge. The arc defines the firing area you could could cover without a bot moving out of the way (you would in theory shoot dead down the middle). You could then consider how many bots are in the area, weighted for those that are moving out of the area and those that are moving into the area. Once you have the largest ammount of bots in the area, you know your vector and take your shot. It would be intersting to see how this would work. -- [[jim]]

DroidPoet always shoots against the center of the field. Since it extends Robot it only fires when it hits something. Which usually is a corner. Thus it ends up shooting against the opposite corner most of the time. DroidPoet is alone in it's class though, so there's no telling if it is any good. -- [[PEZ]]

Just curious, does anyone use a robot with a guess factor gun that doesn't fire unless it has more than, say 30%, chance of hitting? (I'm too lazy to go through all the bot pages and read the stuff) -Mike

I've tried it with some of my bots. Never sorted out if really payed though. Maybe I could try a BeeRRGC with this. Would that be interesting? -- [[PEZ]]

I am not sure where I read it, but I seem to recall that firing 3 power bullets 8% is the break even point at bullet power 3.0. That rate goes up as shot power goes up. I forgot where I read it though. Against TheArtOfWar in the TargetingChallenge, arguably one of the easiest bots to hit, my bot DarkHallow nevers manages a 30% hit rate. I think I acheive something in the vicinity of 28% or so. -- [[jim]]
* I read something similar, i think it was [[Tobe]] who wrote it, but he said that you had to hit with 1 out of 8 bullets fired. which actually agrees with what [[Kawigi]] says below... --[[Brainfade]]

I believe you need to get at least 12%, at least from a survivalist standpoint.  If you hit 11% of the time, then the expected return on your shot is -3(expended shooting) + .12*9 (gained when you hit)  + .12*16(lost by enemy if you hit) = 0.  Of course, that is only the hitrate you need to make shooting keep you alive longer than your opponent.  Scoring makes it so you should fire with a somewhat smaller hit rate. -- [[Kawigi]]

What [[Starrynte/Smash|Smash]] does in the beginning is:
*Spin the radar towards the center to cover the most battleField
*Turn and turn gun at the same time to increase radar speed
(Smash only scans two ticks because it assumes by then it has enough info to move away from dangerous enemies)
<pre>
int direction=sign(Utils.normalRelativeAngle(calcAngle(new Point2D.Double(getX(),getY()),new Point2D.Double(getBattleFieldWidth()/2,getBattleFieldHeight()/2))-myRadarHeading));
setTurnRadarRightRadians(direction * Double.POSITIVE_INFINITY);
radarDir=direction;

setTurnRightRadians(0.3*direction);
setTurnGunRightRadians(0.68*direction);
waitFor(new GunTurnCompleteCondition(this));
setAdjustGunForRobotTurn(true);
setAdjustRadarForGunTurn(true);
</pre>

Also, if you start moving from the scan event, it's ok on smaller battlefields, but on 2000x2000 fields or larger, you might need to implement some sort of "search and wander" mode. Otherwise, you will just sit there, and possibly tie with everyone if no one has a "search and wander" mode (unless they kill each other first, or you happen to be near an enemy)
--[[Starrynte]]

Summary:
Consciousness check: 4 * 10 =
This change is a minor edit. Send email notification that OpeningGame has been changed.
(Visit Preferences to set your user name.)

View other revisions
Robo Home | Changes | Preferences | AllPages