I havnt decided if it will be a mini or a micro bot yet. Perhaps I will do two versions, who knows?
Movement is something new (for me), with the testing so far its pretty good, but needs more tweaking and some major work on the wall avoidance (Wall avoidance seems to be taking up about 50% of my code so far!). Anyone know any good wall avoidance tips?
Targeting is going to be its weak point I think, but perhaps it will develop into something better. I like to do things "my own way", trying out new things or evolved things rather than using others ideas directly.
Anyway, comments would be appreciated!
If your bot orbits (meaning that they basically circle the opponent in either direction), which is what most of mine do, I do three things to avoid hittings walls - see the out function in the kawigi.sbf.* bots to avoid slamming straight into a wall (i.e. - to change direction when you're getting close). Then I also adjust my distance - if I'm being backed up against a wall (I made a recyclable out function to handle this, too) or if I'm close to a corner, I orbit closer to my opponent. -- Kawigi
Im not releasing it yet as its codesize 790, but ive only got "shoot at targets position" targeting so its pretty uncompetative. But I have managed to get my wall avoidance working by modifying the factored wall avoidance method found on the [old] Roborumble pages. Out of interest, how do you all tune your parameters? Trial and error? Some cool class that does it for you? There is the BotOptimiser? but thats not released yet. Any ideas on this? --Wolfman
790 bytes for movement is not much! And since we're talking AntiGravityMovement here it's even slim I would say. For tuning of my movement I use RoboGrapher and performance agains DT. Gun tuning is as easy as measuring a "bullet damage / fired bullet power" ratio I think. Also the TargetingChallenge and MovementChallenge is helpful. -- PEZ
It's antigrav? I missed that. Ok, antigrav can take up a good bit of space (although it could probably be made quite small is someone tried [if they haven't already]). Does your antigrav work with a goTo method? If so, wall avoidance can be done with a simple Rectangle2D of the battle field, and a battleField.contains(NextPosition?) check. What you do with it after that will effect the curve, but at least you won't hit walls. -- Tango
He's using anti-grav to avoid the walls I think (if I remember that factored wall avoidance article correctly). 790 bytes is not much for any movement though I think. And if you're worried about your curve you shouldn't use anti-grav at all I think. -- PEZ
My movement isnt anti-grav. Most of the codesize is taken up by the wall avoidance. It adjusts the angle that you move according to how close you are to the wall. My actual code for selecting the angle that Quantum moves at is relativly small. Also dont forget that im new to reducing codesize so I wouldnt be suprised if I could reduce it by a significant margin if I put the time and effort in. Im going to work on the gun next and see how much that takes up. I might not need to do much work on reducing the movements size if the gun is small. --Wolfman
Oh, wrong article then. =) Please don't start reducment tricks. I think we have enough codesize junkies around as it is. =) DonQuijote says you should only sacrifice functionalit for size. Not code clearity. You get very far with mini's using this principle. Though I have to admit all my attempts at doing competetive micros have failed. -- PEZ
You can still put a pretty sophisticated movement (wall and corner avoidance, bullet-dodging, DynamicDistancing and a few tricks) into about 500-600 bytes from my experience. FloodMicro's and FloodMini's movement would be an example of about that size of movement, and that's generous compared to most competitive minis. FhqwhgadsMicro is an example of how much code goes into movement for a normal micro (about 200-300 bytes probably). -- Kawigi
Its amazing how discussions turn from one subject to something else.... ;)
Ok ive tweaked the movement for Quantum and it now gets about 10% for each of the MovementChallenges. But now ive had an idea for a extremly complicated but ultimatly cool movement that might or might not work. So now Ive got to give it a go. I have a feeling it wont fit in a minibot but we shall see! Of course this means the release for Quantum is being set back by a while!
Don't let the codesize constraints stop you from producing an "ultimately cool" movement man! -- PEZ
Hehe, the trouble with all my "ultimatly cool" ideas is that they tend to take ages to code and then only produce average or bad results. But we shall see! The fun is in the finding out! --Wolfman
Another trouble is that if you don't realize the idea, in a while someone else will, and you will think "Hey! I had that idea first!" but you don't say it because you know noone would really care. And that hurts quite a bit, I know from experience. =) -- PEZ
Hehe, it looks more and more like Quantum is going to be a mega bot, not mini/micro. I started working on my gun just so I could get a reasonably competative bot going. And what happens? I get hooked on targeting, and now my gun code is huge! (But good). I might start working on my new movement soon. Perhaps. :)