RRobots - ducks, armed and dangerous


#1

RRobots v0.1

First there was CRobots, followed by PRobots and many others,
recently (well also years ago) Robocode emerged and finally
this is RRobots bringing all the fun to the ruby community.

What is he talking about?

RRobots is a simulation environment for robots, these robots have
a scanner and a gun, can move forward and backwards and are entirely
controlled by ruby scripts. All robots are equal (well at the moment,
maybe this will change) except for the ai.

A simple robot script may look like this:
----------------------- code -----------------------
require ‘robot’

class NervousDuck
include Robot

def tick events
turn_radar 1 if time == 0
turn_gun 30 if time < 3
accelerate 1
turn 2
fire 3 unless events[‘robot_scanned’].empty?
end
end
----------------------- code -----------------------

all you need to implement is the tick method which should
accept a hash of events occured turing the last tick.

By including Robot you get all this methods to controll your bot:

battlefield_height #the height of the battlefield
battlefield_width #the width of the battlefield
energy #your remaining energy (if this drops
#below 0 you are dead)
gun_heading #the heading of your gun, 0 pointing east,
#90 pointing
#north, 180 pointing west, 270 pointing south
gun_heat #your gun heat, if this is above 0 you can’t
shoot
heading #your robots heading, 0 pointing east, 90
pointing
#north, 180 pointing west, 270 pointing south
size #your robots radius, if x <= size you hit
#the left wall
radar_heading #the heading of your radar, 0 pointing east,
#90 pointing north, 180 pointing west,
#270 pointing south
time #ticks since match start
velocity #your velocity (-8/8)
x #your x coordinate, 0…battlefield_width
y #your y coordinate, 0…battlefield_height
accelerate(param) #accelerate (max speed is 8,
#max accelerate is 1/-1,
#negativ speed means moving backwards)
stop #accelerates negativ if moving forward
#(and vice versa), may take 8 ticks to stop (and
#you have to call it every tick)
fire(power) #fires a bullet in the direction of your gun,
#power is 0.1 - 3, this power will heat your gun
turn(degrees) #turns the robot (and the gun and the radar),
#max 10 degrees per tick
turn_gun(degrees) #turns the gun (and the radar), max 30 degrees
#per tick
turn_radar(degrees) #turns the radar, max 60 degrees per tick
dead #true if you are dead

These methods are intentionally of very basic nature, you are free to
unleash the whole power of ruby to create higher level functions.
(e.g. move_to, fire_at and so on)

Some words of explanation: The gun is mounted on the body, if you turn
the body the gun will follow. In a simmilar way the radar is mounted on
the gun. The radar scans everything it sweeps over in a single tick (100
degrees if you turn your body, gun and radar in the same direction) but
will report only the distance of scanned robots, not the angle. If you
want more precission you have to turn your radar slower.

RRobots is implemented in pure ruby using a tk ui and should run on all
platforms that have ruby and tk. (until now it’s tested on windows only)

To start a match call e.g.

ruby rrobots.rb SittingDuck NervousDuck

the classes have to be defined in files with the same name.
(SittingDuck.rb and NervousDuck.rb for the example above)

You can download the 0.1 release from rubyforge:

http://rubyforge.org/frs/?group_id=1109

The best way to help and keep me motivated would be to post some cool
bots here (along with the bug-reports and feature requests)

cheers

Simon

(and thanks to the robocode project for the nice graphics)


#2

Simon announced:

RRobots v0.1

RRobots is a simulation environment for robots…

Looks great, Simon - I can’t wait to try it out!

Cheers,
Dave


#3

SimonKroeger wrote:

(along with the bug-reports and feature requests)

Just tried it out, and here is the first bug report. You use \ for the
images dir, this doesn’t work on unix based platforms (all except
windows?). If you replace these with / it should work on all platforms
(including windows).

After replacing these it worked fine though, and great graphics :slight_smile: I
might start building some robots :slight_smile:

Edwin


#4

Great work!


#5

Edwin van Leeuwen wrote:

After replacing these it worked fine though, and great graphics :slight_smile: I
might start building some robots :slight_smile:

Edwin

Doh!

Lazy me.

v0.1.1 is ready for download.
(and hopefully realy platform independent)

cheers

Simon


#6

On 11/24/05, Simon Kröger removed_email_address@domain.invalid wrote:

controlled by ruby scripts. All robots are equal (well at the moment,
turn_radar 1 if time == 0

heading #your robots heading, 0 pointing east, 90 pointing
accelerate(param) #accelerate (max speed is 8,
#per tick
degrees if you turn your body, gun and radar in the same direction) but
the classes have to be defined in files with the same name.

Simon

(and thanks to the robocode project for the nice graphics)

Really great work!

It runs on my Linux desktop very well by only modifying image path. :slight_smile:
However, ruby can handle unix style path separator(/) on other
platforms,
(If I am wrong, correct me.) though ‘File.join’ will be better for that
use.

— rrobots.rb.orig 2005-11-24 23:14:55.000000000 +0900
+++ rrobots.rb 2005-11-24 23:15:20.000000000 +0900
@@ -136,15 +136,15 @@
%w{red green}.each do |color|
bodies, guns, radars = [], [], []
36.times do |i|

  •           bodies << TkPhotoImage.new(:file =>
    

“images\#{color}_body#{(i*10).to_s.rjust(3, ‘0’)}.gif”)

  •           guns << TkPhotoImage.new(:file =>
    

“images\#{color}_turret#{(i*10).to_s.rjust(3, ‘0’)}.gif”)

  •           radars << TkPhotoImage.new(:file =>
    

“images\#{color}_radar#{(i*10).to_s.rjust(3, ‘0’)}.gif”)

  •           bodies << TkPhotoImage.new(:file =>
    

“images/#{color}_body#{(i*10).to_s.rjust(3, ‘0’)}.gif”)

  •           guns << TkPhotoImage.new(:file =>
    

“images/#{color}_turret#{(i*10).to_s.rjust(3, ‘0’)}.gif”)

  •           radars << TkPhotoImage.new(:file =>
    

“images/#{color}_radar#{(i*10).to_s.rjust(3, ‘0’)}.gif”)
end
colors << TkRobot.new(bodies << bodies[0], guns << guns[0],
radars << radars[0])
end

bum = (0…14).map do |i|

  • TkPhotoImage.new(:file => “images\explosion#{i.to_s.rjust(2,
    ‘0’)}.gif”)
  • TkPhotoImage.new(:file => “images/explosion#{i.to_s.rjust(2,
    ‘0’)}.gif”)
    end

robots, bullets, explosions = {}, {}, {}
@@ -177,4 +177,4 @@
end
}).start

-Tk.mainloop
\ No newline at end of file
+Tk.mainloop


#7

Gyoung-Yoon N. wrote:


http://nohmad.sub-port.net

Hehe, nice!

and thanks for the feedback.

Simon


#8

On 11/24/05, Simon Kröger removed_email_address@domain.invalid wrote:

v0.1.1 is ready for download.
(and hopefully realy platform independent)

My screenshot:
http://static.flickr.com/26/66471832_4ceaf3b81b_o.png


#9

You get a gold star on the chart for the day!

Today we can all be thankful for rrobots.rb.

Here’s the listing of my first bot, affectionately titled BotOne. He
lays a savage beat down on the aptly named NervousBot, but he is by no
means invincible.

#Begin listing

require ‘robot’

class BotOne
include Robot
def tick events
@rapid_fire = 0 if @rapid_fire.nil?
@last_seen = 0 if @last_seen.nil?
@turn_speed = 3 if @turn_speed.nil?

	if time - @last_seen > 200
		@turn_speed *= -1
		@last_seen = time
	end

	turn @turn_speed

	if( @rapid_fire > 0 )
		fire 0.84
		turn_gun -(@turn_speed / @turn_speed) *2
		@rapid_fire = @rapid_fire - 1
	else
		turn_gun @turn_speed * 1.25
	end

	if( !events['robot_scanned'].empty? )
		@turn_speed *= -1
		@last_seen = time
		@rapid_fire = 20
	end
	@last_hit = time unless events['got_hit'].empty?
	if @last_hit && time - @last_hit < 20
		accelerate(-1)
	else
		accelerate 1
	end
end

end

#End listing

This bot prefers long matches, as he fires low power shots. This, on
my machine at least exposes some performance problems associated with
shooting a lot. Matching a couple of rapid firing bots brings the app
to it’s knees after only a few thousand ticks. My first idea where
maybe that the bullets were not being cleaned up properly, but looking
at the source it looks like they are being remove from the hash and
canvas, so I don’t know.

Barring that though, this is brilliant!

One thousand thanks,
-Harold


#10

In article removed_email_address@domain.invalid,
Simon Kröger removed_email_address@domain.invalid wrote:

The best way to help and keep me motivated would be to post some cool
bots here (along with the bug-reports and feature requests)

It looks cool. Now only if I could find time to write a bot or series of
bots…

Here is a tiny bug report/feature request. The first I did was:

ruby rrobots.rb SittingDuck.rb NervousDuck.rb

result:

Error loading SittingDuck.rb!
usage: rrobots.rb <FirstRobotClassName> <SecondRobotClassName>
        the names of the rb files have to match the class names of
        the robots e.g. 'ruby rrobots.rb SittingDuck NervousDuck'

This is easily corrected, but I think the code c/should be smart enough
to notice that the ‘.rb’ extensions already are there (with tab
completion, typing the ‘.rb’ is easier than not typing it)

I also have the first security breach to report. I do not think you
intend that the following should be valid inside a robot:

@battlefield.robots.each do |other|
  puts "robot #{other}: x #{other.x}, y #{other.y}"
end

If a robot can do that, the radar seems extremely limited.

Reinder


#11

Reinder V. wrote:

In article removed_email_address@domain.invalid,
Simon Kröger removed_email_address@domain.invalid wrote:

The best way to help and keep me motivated would be to post some cool
bots here (along with the bug-reports and feature requests)

It looks cool. Now only if I could find time to write a bot or series of
bots…

Would make me happy too :slight_smile:

This is easily corrected, but I think the code c/should be smart enough
to notice that the ‘.rb’ extensions already are there (with tab
completion, typing the ‘.rb’ is easier than not typing it)

Ok, will be in the next release.

I also have the first security breach to report. I do not think you
intend that the following should be valid inside a robot:

@battlefield.robots.each do |other|
  puts "robot #{other}: x #{other.x}, y #{other.y}"
end

If a robot can do that, the radar seems extremely limited.

Robots are distributed as source code (i don’t see another way anyway)
so nobody would want to compete against such a bot.
(You can search ObjectSpace and find the other robot, setting his energy
to -1, easy victory but without honour)
Maybe there is a way to protect against such strategies i didn’t thought
of, any ideas?

Reinder

cheers

Simon


#12

Harold H. wrote:

You get a gold star on the chart for the day!

Today we can all be thankful for rrobots.rb.

Here’s the listing of my first bot, affectionately titled BotOne. He
lays a savage beat down on the aptly named NervousBot, but he is by no
means invincible.

to cool.

canvas, so I don’t know.
I will dive into that (i was able to finish the match, but it slows
down considerably) maybe i have to ‘reuse’ old bullets.

Barring that though, this is brilliant!

One thousand thanks,
-Harold

I’m realy glad to see someone enjoys this little game.

cheers

Simon


#13

hhausman wrote:

You get a gold star on the chart for the day!

Today we can all be thankful for rrobots.rb.

Here’s the listing of my first bot, affectionately titled BotOne. He
lays a savage beat down on the aptly named NervousBot, but he is by no
means invincible.

After quite a bit of tweaking I’m also ready to release my aptly named
HuntingDuck. It will try to move closer to it’s prey (while shooting it
ofcourse).

It seems to be about even with BotOne, but I as its creator might be
overproud :slight_smile:

class HuntingDuck
include Robot
def initialize bf
super(bf)
@time_since=10
@direction=1
end
def rel_direction(from,to)
rel = to -from
if rel > 180
rel = -360 + rel
end
if rel < -180
rel = 360+rel
end
return rel
end
def rel_gun_heading
rel_direction(heading, gun_heading)
end
def tick events
accelerate 1
@direction = -@direction if Kernel.rand < 0.02
if !events[‘got_hit’].empty?
fire 2
turn -10*@direction
end
if !events[‘robot_scanned’].empty?
fire 3
@time_since=0
else
if @time_since < 15
if Kernel.rand < 0.5 && rel_gun_heading < 30
turn_gun 6
elsif rel_gun_heading > -30
turn_gun -6
else
turn_gun 6
end
fire 0.5
elsif @time_since < 100
turn 10*@direction
else
turn 5
end
end
@time_since += 1
end
end


#14

On

so nobody would want to compete against such a bot.
(You can search ObjectSpace and find the other robot, setting his energy
to -1, easy victory but without honour)
Maybe there is a way to protect against such strategies i didn’t thought
of, any ideas?

Judicious use of freeze?


#15

“Simon Kröger” removed_email_address@domain.invalid wrote in message
news:removed_email_address@domain.invalid…
Reinder V. wrote:

In article removed_email_address@domain.invalid,
Simon Kröger removed_email_address@domain.invalid wrote:

The best way to help and keep me motivated would be to post some cool
bots here (along with the bug-reports and feature requests)

It looks cool. Now only if I could find time to write a bot or series of
bots…

Would make me happy too :slight_smile:

This is easily corrected, but I think the code c/should be smart enough to
notice that the ‘.rb’ extensions already are there (with tab completion,
typing the ‘.rb’ is easier than not typing it)

Ok, will be in the next release.

I also have the first security breach to report. I do not think you intend
that the following should be valid inside a robot:

@battlefield.robots.each do |other|
  puts "robot #{other}: x #{other.x}, y #{other.y}"
end

If a robot can do that, the radar seems extremely limited.

Robots are distributed as source code (i don’t see another way anyway)
so nobody would want to compete against such a bot.
(You can search ObjectSpace and find the other robot, setting his energy
to -1, easy victory but without honour)
Maybe there is a way to protect against such strategies i didn’t thought
of, any ideas?

Reinder

cheers

Simon


#16

(Sorry for the blank post)

Simon Kröger wrote:

Robots are distributed as source code (i don’t see another way anyway)
so nobody would want to compete against such a bot.
(You can search ObjectSpace and find the other robot, setting his energy
to -1, easy victory but without honour)
Maybe there is a way to protect against such strategies i didn’t thought
of, any ideas?

$SAFE can stop this kind of thing. Run a thread for each robot, taint
stuff
you don’t want it to be able to mess with (e.g. the thread), untaint the
robot’s code, and eval and run it under $SAFE=4.

Cheers,
Dave


#17

After quite a bit of tweaking I’m also ready to release my aptly named
HuntingDuck. It will try to move closer to it’s prey (while shooting it
ofcourse).

It seems to be about even with BotOne, but I as its creator might be
overproud :slight_smile:

Against SittingDuck, it performed very badly :slight_smile:


#18

On Nov 24, 2005, at 8:05 AM, Simon Kröger wrote:

velocity #your velocity (-8/8)

Minor nitpick - as a scalar, this should really be called “speed”.
Velocity indicates a magnitude and direction (a vector), while speed
is a pure rate measurement.


#19

On Nov 24, 2005, at 2:51 PM, Simon Kröger wrote:

so nobody would want to compete against such a bot.
(You can search ObjectSpace and find the other robot, setting his
energy
to -1, easy victory but without honour)
Maybe there is a way to protect against such strategies i didn’t
thought
of, any ideas?

Sure, move the communication to a client server architecture so you
can control this better. You’ve got to stop them running in the same
process, to make it easier on yourself.

James Edward G. II


#20

JEGII:

Sure, move the communication to a client server architecture so you can
control this better. You’ve got to stop them running in the same
process, to make it easier on yourself.

Yes, that’s the better way - easier than $SAFE.

Cheers,
Dave