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

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
1c1e3bdfe006a22214102fcd6434a012?d=identicon&s=25 daniels (Guest)
on 2005-11-14 00:14
(Received via mailing list)
> 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.
#####################################################################################
1f644fe42aaa1c1bbddd24908aed3ddd?d=identicon&s=25 reyn.vlietstra (Guest)
on 2005-11-14 08:38
(Received via mailing list)
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.
793a1abe9d6824492dcf9aeff6a337ab?d=identicon&s=25 james.rw.walker (Guest)
on 2005-11-14 12:28
(Received via mailing list)
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 :)

A delay of several minutes between the game and the spectator is a
common mechanism of addressing this problem.
1f644fe42aaa1c1bbddd24908aed3ddd?d=identicon&s=25 reyn.vlietstra (Guest)
on 2005-11-14 14:40
(Received via mailing list)
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 ?
0b561a629b87f0bbf71b45ee5a48febb?d=identicon&s=25 dave (Guest)
on 2005-11-14 16:05
(Received via mailing list)
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
B6efa20772f1404cdd68840e95722891?d=identicon&s=25 kheon (Guest)
on 2005-11-15 00:23
(Received via mailing list)
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
2dc2228d8db84b46bdd834b0515a26a1?d=identicon&s=25 lyndon.samson (Guest)
on 2005-11-15 01:11
(Received via mailing list)
So, come on! Lets get a mailing list or some sort of forum set up to
start kicking round ideas.
65bd9e4c5aebde25ebf16d599339d570?d=identicon&s=25 netghost (Guest)
on 2005-11-15 18:42
(Received via mailing list)
No way!  Lets discuss the possibility of discussing this some more!
I move to begin discussions on the proper mechanism for future
discussions ;)

Does someone want to get a rubyforge project set up?  I think we can
have a lot of fun with this.
  .adam
A9c4658e9e475e13d790ae419acf01b6?d=identicon&s=25 SimonKroeger (Guest)
on 2005-11-15 21:13
(Received via mailing list)
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 ;)
>
> 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
A9c4658e9e475e13d790ae419acf01b6?d=identicon&s=25 SimonKroeger (Guest)
on 2005-11-16 00:29
(Received via mailing list)
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 :) )

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

$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
1d6252c8fa730e6b9989db64df35103a?d=identicon&s=25 J. Merrill (j-merrill)
on 2005-11-16 19:38
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?)
65bd9e4c5aebde25ebf16d599339d570?d=identicon&s=25 netghost (Guest)
on 2005-11-16 22:50
(Received via mailing list)
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
2dc2228d8db84b46bdd834b0515a26a1?d=identicon&s=25 lyndon.samson (Guest)
on 2005-11-24 00:47
(Received via mailing list)
Just bubbling this thread event back up to group conciousness.... :-)
B6efa20772f1404cdd68840e95722891?d=identicon&s=25 kheon (Guest)
on 2005-11-24 00:55
(Received via mailing list)
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
467c7c87ad5b36859a7644b9198b490a?d=identicon&s=25 leslie (Guest)
on 2005-11-24 13:48
(Received via mailing list)
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&...

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
2f6686bd2c6bb633a1cbf7b5a73c8491?d=identicon&s=25 Mickael Faivre-Macon (micktaiwan)
on 2005-11-24 19:44
(Received via mailing list)
> 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&...

Me too.
Maybe we should write a doc on Writely.com and our ideas there or open
a project on rubyforge or else ?
Mickael.
467c7c87ad5b36859a7644b9198b490a?d=identicon&s=25 leslie (Guest)
on 2005-11-24 20:28
(Received via mailing list)
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
This topic is locked and can not be replied to.