|
null maverick mention tailor experiences hovers,crystallizing!circuitously Koppers poked tapped [online casinos ] completeness homomorphisms Jo!steak [online casino ] tailors hardships procurer [casino ] unconcernedly microlevel |
|
What should Robocode2 add that isnt in RC1? * The ability for bots to draw to the screen for debugging. When a battle is started there should be an option to select a bot to debug; that bot would then be allowed to draw to the screen. This would prevent total chaos if all bots are drawing to the screen at once. * Bots should have a customizable set of parameters. Off the top of my head, speed/energy/armor seems like a good combination. Bots would default to 5/5/5, which would correspond to the max speed, initial energy, and damage formulae from R1. You could then set your bot to have 8/5/2, for example, for a faster bot with the same initial energy, but which takes more damage when hit. Each point could correspond to 1 unit of speed, 20 energy, and 8% damage. A 3/4/8 bot would have a max speed of 6 and initial energy of 90 in this system, but would take 24% less damage than the standard amount. I think this would especially make for interesting team battles where you could have a mix of different parameters on your team. * More accurate physics. In particular, elastic collisions would be fun to watch. Bots should also be treated as rotating rectangles, so that a collision might send you spinning. A bot's top speed (see above) could be used to determine its mass in collisions: slow, heavily armored bots should send light fast bots flying when they hit. Collisions should be damped fairly quickly so that R1 bots don't go crazy, since R1 bots aren't designed to deal with collisions. * Scores should be displayed on-the-fly. * setColors() should be changed to accept any object of class Paint. This would be backwards compatible (since the Color class implements Paint) AND would allow cool custom paint jobs. Imagine a robot with racing stripes! Woohoo! The only caveat here is that bots whose Paint implementation changes over time wouldn't actually be color changing bots unless you called setColors() again, since the bot image would get buffered. In other words, pulsating colors and flashing lights on your bot is just not going to work, for performance reasons. * Would be nice if teams were placed in an ordered way into the battle field (ie. one team on the left, one on the right). --Albert * Additionally I would like to have different kinds of obstacles on the field. Both those that only block movement, but also those that block line of sight and bullets. --sikjo * Support for running it in an IDE, eg, as an [Eclipse plug-in] --Rod Hyde * It would be nice to be able to turn off the victory dance, as it wastes time, and my bot has two left feet anyway. --Tad * A Radar Warning Receiver (RWR) * I would like to add multiple programmation language support throught a simple communication protocol (maybe something like Corba or defined protocol) that can be implemented in any language. I can add the security issue for the linux platform (and maybe MacOSX, I think on *nix systems) but I don't know about Window$. This protocol can also provide playing over a network. --Synnalagma * DEBUG state : You should have the possibility to declare a bot in DEBUG MOD. It'll be able to draw special thing in this state as said before. Another thing is the ability to send information to your Bot in DEBUG MOD like if you type F1 or Fx the bot receive a message by implementing void onModChange?(int Fx) or something similar. This can help a lot to see difference between movement or other things during testing phase. --Synnalagma * I made a separate page for /DebuggingBots?. * 'Main' robot color, see below (for graphical debug in one color). Drawback: useless if the author of a bot doesn't use it right. * getColors() (returns an array), getMainColor?(), getRobotColor?(), getGunColor?() and getRadarColor?(), both for the bot itself and other bots (e.g. in ScannedRobotEvent). Could be useful for drawing graphical debug info, especially in Melee or Teams, or of course for fun. ** What would getMainColor?() return? --Ph *** A fourth color the author sets in setColors(). Melee example: you draw graphical stuff for every bot you scanned, in their colors. But many bots use three different colors, so what color do you use? Maybe the main color is completely unnecessary because the robot color is a big area (at least in RC 1), but it's still an idea. -- Jonathan * getTeam(), both for the bot itself and other bots (e.g. in ScannedRobotEvent). To target a specific team. :) No, actually it can be used for stats and a couple of things. -- Jonathan (also did the three points above) * Just one onHitRobot?() event when both bots are moving towards each other, of course with getOthersFault?() added to HitRobotEvent?. That should ease some calculations. -- Jonathan ** getOthersFault?() is not needed. If it is not your fault it is your enemy's fault. --Ph
Some comments on accurate physics
|
![[Home]](/images/RoboWiki.png)