[Home]Robocode2/Additions

Robo Home | Robocode2 | Changes | Preferences | AllPages

Difference (from prior major revision) (no other diffs)

Changed: 1,2c1,60
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


I was scratching my head thinking about how to simulate elastic collisions, when I realised that there are a lot of resources out there that deal with this sort of thing. For example, if you like a bit of bedtime reading then there's a book called Physics for Game Developers. Also, searching on Google for phrases such as "collision detection physics" turns up all sorts of things.

Here's a link to a site which has [4 physics articles] and some sample applications. The articles were originally published as articles in Game Developer magazine a few years ago. It's definitely worth reading the first three of them.

I've already started porting his C++ physics code to Java... :-) --David Alves

That's good. I look forward to seeing it. --Rod Hyde


After some more exploring, I found the [Fast Car] page. This is a commercial C++ library (2.5D not 2D - also free for evaluation) but it also contains freeware in the form of full source code for rigid body dynamics. I think it is worth taking a look at the code and the documentation as it is more complete than Chris Hecker's code. There are a few downloadable demos (Windows/OpenGL?): watching the collisions in the one with the cars and the blocks is very interesting as it gives a flavour of what RC2 could look like if extended to 2.5D. However, I am inclined to suggest that we should keep the physics in 2D as I'm not sure if I'm prepared to write code to handle the case of my robot being toppled over completely :-) --Rod Hyde

What exactly does "Each point could correspond to ....8% damage" mean, anyways? --Insectoid

I created a page at which eneryone can spread their toughts, knowledge and URL's about more accurate physics: /Accurate Physics. --Daniël Pelsmaeker

I think RoboCode2 robots should be able to be controlled through socket communication, that way, you could code the robots in virtually ANY other programming language besides Java. --Acid06

I belive you can do that with RoboCode1?, there a bot, HCBot i think, that has a separate program that takes human input and uses that the control the robot. I see no reason why that program couldn't be written in any language you like, and control the bot automatically. -- Tango

I think that bot depended on File I/O, so it would be a challenge to make a bot that measures up to normal performance in another language. -- Kawigi

It was files, rather than sockets, was it? OK. How about DeathMatch? That uses sockets to communicate with the server, is it possible for the server to control the robot? -- Tango

Could be done by adding a new robot class into the robocode package. -- Kawigi

Comment about Oriented bounding box

I wrote a class for oriented bounding box in another project, it make collision and all calculation quite hard and so I don't thing it's a good thing (like you can hit something by rotating). I mean Robocode is cool because of it's simplicity. --Synnalagma

A circle might be a good substitute. Checking for collisions would be pretty straightforward too:
if(xDistance * xDistance + yDistance * yDistance) < 4 * robotRadius * robotRadius){ ...
Using a circle would guarantee that SittingDuck is equally easy to hit from every angle, which is not the case right now. It would also be simple to program and run almost as fast as the current system. --David Alves

Would it still be worthwhile to check a line's intersection with a circle rather than a point's lying within the circle? (especially for fast-moving bullets?) -- Kawigi


What should Robocode2 add that isnt in RC1?


Some comments on accurate physics

I was scratching my head thinking about how to simulate elastic collisions, when I realised that there are a lot of resources out there that deal with this sort of thing. For example, if you like a bit of bedtime reading then there's a book called Physics for Game Developers. Also, searching on Google for phrases such as "collision detection physics" turns up all sorts of things.

Here's a link to a site which has [4 physics articles] and some sample applications. The articles were originally published as articles in Game Developer magazine a few years ago. It's definitely worth reading the first three of them.

I've already started porting his C++ physics code to Java... :-) --David Alves

That's good. I look forward to seeing it. --Rod Hyde

After some more exploring, I found the [Fast Car] page. This is a commercial C++ library (2.5D not 2D - also free for evaluation) but it also contains freeware in the form of full source code for rigid body dynamics. I think it is worth taking a look at the code and the documentation as it is more complete than Chris Hecker's code. There are a few downloadable demos (Windows/OpenGL?): watching the collisions in the one with the cars and the blocks is very interesting as it gives a flavour of what RC2 could look like if extended to 2.5D. However, I am inclined to suggest that we should keep the physics in 2D as I'm not sure if I'm prepared to write code to handle the case of my robot being toppled over completely :-) --Rod Hyde

What exactly does "Each point could correspond to ....8% damage" mean, anyways? --Insectoid

I created a page at which eneryone can spread their toughts, knowledge and URL's about more accurate physics: /Accurate Physics. --Daniël Pelsmaeker

I think RoboCode2 robots should be able to be controlled through socket communication, that way, you could code the robots in virtually ANY other programming language besides Java. --Acid06

I belive you can do that with RoboCode1?, there a bot, HCBot i think, that has a separate program that takes human input and uses that the control the robot. I see no reason why that program couldn't be written in any language you like, and control the bot automatically. -- Tango

I think that bot depended on File I/O, so it would be a challenge to make a bot that measures up to normal performance in another language. -- Kawigi

It was files, rather than sockets, was it? OK. How about DeathMatch? That uses sockets to communicate with the server, is it possible for the server to control the robot? -- Tango

Could be done by adding a new robot class into the robocode package. -- Kawigi

Comment about Oriented bounding box

I wrote a class for oriented bounding box in another project, it make collision and all calculation quite hard and so I don't thing it's a good thing (like you can hit something by rotating). I mean Robocode is cool because of it's simplicity. --Synnalagma

A circle might be a good substitute. Checking for collisions would be pretty straightforward too:

 if(xDistance * xDistance + yDistance * yDistance) < 4 * robotRadius * robotRadius){ ...
Using a circle would guarantee that SittingDuck is equally easy to hit from every angle, which is not the case right now. It would also be simple to program and run almost as fast as the current system. --David Alves

Would it still be worthwhile to check a line's intersection with a circle rather than a point's lying within the circle? (especially for fast-moving bullets?) -- Kawigi


Robo Home | Robocode2 | Changes | Preferences | AllPages
Edit text of this page | View other revisions
Last edited May 7, 2006 6:53 EST by Voidious (diff)
Search: