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.

···

On 11/14/05, Daniel Sheppard <daniels@pronto.com.au> wrote:

> 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.

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

--
Reyn Vlietstra

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.

···

On 14/11/05, Reyn Vlietstra <reyn.vlietstra@gmail.com> wrote:

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.

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 ?

···

On 11/14/05, James Walker <james.rw.walker@gmail.com> wrote:

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.

On 14/11/05, Reyn Vlietstra <reyn.vlietstra@gmail.com> wrote:
> 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.
>

--
Reyn Vlietstra

Reyn Vlietstra 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

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 Heon
kheon@comcast.net

···

-----Original Message-----
From: Dave Burt [mailto:dave@burt.id.au]
Sent: Monday, November 14, 2005 10:03 AM
To: ruby-talk ML
Subject: Re: Equvialent of RoboCode and/or Terrarium for Ruby?

Reyn Vlietstra 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

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

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

Adam Sanderson 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

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

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?)

···

--
Posted via http://www.ruby-forum.com/\.

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

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 Heon
kheon@comcast.net

···

-----Original Message-----
From: Lyndon Samson [mailto:lyndon.samson@gmail.com]
Sent: Wednesday, November 23, 2005 6:44 PM
To: ruby-talk ML
Subject: Re: Equvialent of RoboCode and/or Terrarium for Ruby?

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

Kyle Heon 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 Heon
kheon@comcast.net

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.

Mickael Faivre-Macon wrote:

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.

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