Re: Equvialent of RoboCode and/or Terrarium for Ruby?

Would be nice to have a server to which different renderers
could connect, that way we could have international battles
with alot of spectators, does robocode allow this ?

Using drb/tcp makes sense if we’d like people to battle it
out without giving the other party their precious robot code.

It would be a little problematic to combine both of these goals - if
clients were connecting via TCP, and there was a view of the game
available to multiple clients via TCP, suddenly clients have the ability
to see the ‘spectator’ view of the gameboard. Probably wouldn’t be a
problem if the spectator view was on enough of a delay to make the
information useless (either by prerecording the whole game and playing
it out (which I guess would be nice for passing around prerecorded
games), or having the delay on the scale of over a minute).

#####################################################################################
This email has been scanned by MailMarshal, an email content filter.
#####################################################################################

Sorry,
Why would it be bad/problematic for “clients to have a spectator view of
the
board game” ?
The robot would use the information to plan it’s next move and the
renderer
would diplay
the current state, or am I missing something ?
I guess if latency is an issue then the game would perform very badly.

Presumably a spectator view would provide information that is beyond
that which the bot should be able to obtain from his “in the world”
viewpoint. Knowing the bad bot with the BFG is just round the corner
removes some of the anticipation :slight_smile:

A delay of several minutes between the game and the spectator is a
common mechanism of addressing this problem.

Reyn V. mused:

ah, ok
I only thought about the simplest case, robocode doesn’t seem to have
occluders and visibility.
Would be nifty to have a grid based level with obstacles, anything more
complex than that would probably be easier implemented as a quake mod.
Robots could set traps for each other, or use known things in the level,
eg
pull a lever when another robot is positioned over a flame.
Would more complexity be more fun ? Where is the line drawn ?

RoboCode is a simple system that includes limited robot-vision. Bots
have a
turretted weapon mounted on the vehicle, and a turretted scanner mounted
on
top of that. Scanners turn much quicker than the guns or whole vehicles,
but
still at a limited rate, so you need to make a trade-off between
scanning
all around to get the big picture and scanning specific threats (e.g.
for
targetting).

Cheers,
Dave

ah, ok
I only thought about the simplest case, robocode doesn’t seem to have
occluders and visibility.
Would be nifty to have a grid based level with obstacles, anything more
complex than that would probably be easier implemented as a quake mod.
Robots could set traps for each other, or use known things in the
level, eg
pull a lever when another robot is positioned over a flame.
Would more complexity be more fun ? Where is the line drawn ?

Yes, and while this is basic in principle is really why it’s such a
great
learning tool. You don’t really need to do all that much to get a
working
robot. As your skills in the language, you can build smarter and smarter
bots that have complex targeting and path finding systems.

Kyle H.
[email protected]

No way! Lets discuss the possibility of discussing this some more!
I move to begin discussions on the proper mechanism for future
discussions :wink:

Does someone want to get a rubyforge project set up? I think we can
have a lot of fun with this.
.adam

So, come on! Lets get a mailing list or some sort of forum set up to
start kicking round ideas.

Adam S. wrote:

No way! Lets discuss the possibility of discussing this some more!
I move to begin discussions on the proper mechanism for future
discussions :wink:

Does someone want to get a rubyforge project set up? I think we can
have a lot of fun with this.
.adam

Without a 3 day kickoff workshop, and validated reviews of the
requirement analyses process plan?

I think this project is doomed already, no?

I would say forget all the fancy stuff, no obstacles, no configuration,
just plain robots with a scanner and a big nasty cannon. (and some
superdupa special effects of course - oh… sorry)

Slow bullets and suboptimal scanners in a 2d world is realy enough to
provide fun. (and the BIIIG explosions of course - ah… again, sorry)

And for the online fun, keep it for version 2.0 or better 3.0. Until
that create a way to inject a random seed in the arena program. That way
everyone can have a replay of official matches just by providing this
random seed to his localy installed arena (and the bots of course).

just my 2 cents

cheers

Simon

SimonKroeger wrote (in part):

module Robot
#the height of the battlefield
attr_reader :battlefield_height

#the width of the battlefield
attr_reader :battlefield_width

Are you defining the “base” Robot that should be the minimal, standard,
parent of most “battle-ready” Robots?

Shouldn’t the Robot hold a reference to a battlefield object, not
battlefield_blah arbitrary individual bits of info about the
battlefield? For example, if a battlefield were to have obstacles, that
info belongs in the battlefield and not in each robot.

[snip]

class MyRobot
include Robot

What keeps
MyRobot < Robot
from being more appropriate? (I’m rather new to Ruby, and love the
mixin capability, but why not inheritance when there’s no
multiple-inheritance issue?)

Ok, i realy don’t know if it will be of any help but perhaps someone
gets inspired. (i will continue this if i have time but someone else
could think of a frontend - start with the graphics from robocode…)

Here is my first approach … very unfinished, more like an idea than
the real thing:
(for now, there is a stupid robot running in circles shooting
nonestisting bullets in every direction - there is plenty of room for
improvements :slight_smile: )

##############################################

$stdout.sync = true

class Numeric
def to_rad
self / 180.0 * Math::PI
end
end

module Battlefield
HEIGHT = 1600
WIDTH = 1600
end

module Robot
#the height of the battlefield
attr_reader :battlefield_height

#the width of the battlefield
attr_reader :battlefield_width

#your remaining energy (if this drops below 0 you are dead)
attr_reader :energy

#the heading of your gun, 0 pointing east, 90 pointing north, 180
pointing west, 270 pointing south
attr_reader :gun_heading

#your gun heat, if this is above 0 you can’t shoot
attr_reader :gun_heat

#your robots heading, 0 pointing east, 90 pointing north, 180
pointing west, 270 pointing south
attr_reader :heading

#your robots radius, if x <= size you hit the left wall
attr_reader :size

#the heading of your radar, 0 pointing east, 90 pointing north, 180
pointing west, 270 pointing south
attr_reader :radar_heading

#ticks since match start
attr_reader :time

#your velocity (-8/8)
attr_reader :velocity

#your x coordinate, 0…battlefield_width
attr_reader :x

#your y coordinate, 0…battlefield_height
attr_reader :y

#accelerate (max speed is 8, max accelerate is 1/-1, negativ speed
means moving backwards)
def accelerate param
@actions[:accelerate] = param
end

#accelerates negativ if moving forward (and vice versa), may take 8
ticks to stop (and you have to call it every tick)
def stop
@actions[:accelerate] = (velocity > 0) ? -1 : ((velocity < 0) ? 1
:0)
end

#fires a bullet in the direction of your gun, power is 0.1 - 3, this
power is taken from your energy
def fire power
@actions[:fire] = power
end

#turns the robot (and the gun and the radar), max 10 degrees per tick
def turn degrees
@actions[:turn] = degrees
end

#turns the gun (and the radar), max 30 degrees per tick
def turn_gun degrees
@actions[:turn_gun] = degrees
end

#turns the radar, max 60 degrees per tick
def turn_radar degrees
@actions[:turn_radar] = degrees
end

private
def initialize bf_height, bf_width
@battlefield_height = bf_height
@battlefield_width = bf_width
@x = (rand * bf_width).to_i
@y = (rand * bf_height).to_i
@gun_heat = 3
@heading = (rand * 360).to_i
@gun_heading = @heading
@radar_heading = @heading
@time = 0
@velocity = 0
@energy = 100
@events = Hash.new{[]}

 @@robots ||= []
 @@robots << self

end

def Robot.robots
@@robots
end

def internal_tick
@actions = Hash.new(0)
tick @events

 @actions[:fire] = 3 if @actions[:fire] > 3
 @actions[:fire] = 0 if @actions[:fire] < 0
 @actions[:turn] = 10 if @actions[:turn] > 10
 @actions[:turn] = -10 if @actions[:turn] < -10
 @actions[:turn_gun] = 30 if @actions[:turn_gun] > 30
 @actions[:turn_gun] = -30 if @actions[:turn_gun] < -30
 @actions[:turn_radar] = 60 if @actions[:turn_radar] > 60
 @actions[:turn_radar] = -60 if @actions[:turn_radar] < -60
 @actions[:accelerate] = 1 if @actions[:accelerate] > 1
 @actions[:accelerate] = -1 if @actions[:accelerate] > -1

 old_radar_heading = @radar_heading
 @heading += @actions[:turn]
 @gun_heading += @actions[:turn] + @actions[:turn_radar]
 @radar_heading += @actions[:turn] + @actions[:turn_radar] +

@actions[:turn_radar]
@velocity += @actions[:accelerate]
@velocity = 8 if @velocity > 8
@velocity = -8 if @velocity < -8

 @x += Math::cos(@heading.to_rad) * @velocity
 @y -= Math::sin(@heading.to_rad) * @velocity

 @@robots.each do |other|
   if other != self
     #if old_radar_heading < angle_to_other < @radar_heading
     #  @events['robot_scanned'] << [angle_to_other, 

distance_to_other]
#end
end
end
@time += 1
end
end

##############################################

robot code (will be dynamicaly required)

##############################################

class MyRobot
include Robot

def tick events
accelerate 1
turn 5
fire 3
end
end

##############################################

arena

##############################################
w, h = Battlefield::WIDTH, Battlefield::HEIGHT

robot1 = MyRobot.new w, h
#robot2 = MyRobot.new w, h

loop do
Robot.robots.each do |robot|
robot.send :internal_tick
if robot.energy < 0
puts “robot died”
break
end
puts robot.x.to_i.to_s + ', ’ + robot.y.to_i.to_s
end
sleep 0.1
end

Just bubbling this thread event back up to group conciousness… :slight_smile:

Nice to see that people are interested. I don’t know Ruby well enough to
contribute much but I definetly would be interested in helping out
anyway
that I can. I just don’t know what I could do.

Kyle H.
[email protected]

Kyle H. wrote:

Nice to see that people are interested. I don’t know Ruby well enough to
contribute much but I definetly would be interested in helping out anyway
that I can. I just don’t know what I could do.

Kyle H.
[email protected]

Reyn and I have started on a project like this. You can see our progress
here:
http://www.reyn.co.za/gautengrb/viewtopic.php?t=3&start=15

If you’re interested, please contribute! The forum has info on how to
get my current
DRb client/server code if you want to see it.

Les

Reyn and I have started on a project like this. You can see our progress
here:
http://www.reyn.co.za/gautengrb/viewtopic.php?t=3&start=15

Me too.
Maybe we should write a doc on Writely.com and our ideas there or open
a project on rubyforge or else ?
Mickael.

Looks interesting, I think you have a lot of teh right ideas here.

People might be interested in some of the old documentation from
RoboWar and RoboTalk, which I think spawned a lot of these games.

Here’s a tutorial that steps trhough a lot of the concepts from RoboWar
http://www.stanford.edu/~pch/robowar/tutorial/tut_01.html

I think it’s useful to look at the first part where is lists what a
robot can sense. May prove handy.
.adam

Mickael Faivre-Macon wrote:

With Tim Bates’ permission we have taken over his old Rubots project on
RAA and Sourceforge.
Is your project along similar lines to what we are trying to achieve?

Les