Equvialent of RoboCode and/or Terrarium for Ruby?
kh...@comcast.net
It would seem to me that the dynamic nature of Ruby would make something like this pretty cool.
Thanks.
Kyle Heon
Dave Burt
No, there isn't. Tim Bates started work on Rubots, and I have early-stages
code and ideas based on RoboCode, but that's the extent of it.
Are you interested in writing it?
Cheers,
Dave
kh...@comcast.net
If helping build a training tool like this helps me learn then I'm all for it.
Jim Menard
Jim
--
Jim Menard, jim.m...@gmail.com, ji...@io.com
http://www.io.com/~jimm
"Don't let what you can't do stand in the way of what you can." -- John Wooden
Reyn Vlietstra
Could be a nice feature to allow it, might even enable the user
to train a neural net or somethin.
SDL ?
--
Reyn Vlietstra
kh...@comcast.net
It's such a neat concept, there was the last time I checked a pretty large community around RoboCode with lots of users writing tutorials details different AI approaches.
-K
Jeff Wood
is, I'm a geek so I always gold plate it with user-definable weapons, etc
.. smart weapons ... etc.
But it would be cool.
And we should build a gui front end for it. Good example project for
people.
j.
--
"http://ruby-lang.org -- do you ruby?"
Jeff Wood
Kyle Heon
programming I think this would be something really fun to contribute and be
a part of.
What would we need just to start? Who's interested?
Kyle Heon
kh...@comcast.net
Ezra Zygmuntowicz
Cheers-
-Ezra
On Nov 9, 2005, at 5:02 PM, Kyle Heon wrote:
> Although I'm just starting to learn Ruby and really don't know much
> about AI
> programming I think this would be something really fun to
> contribute and be
> a part of.
>
> What would we need just to start? Who's interested?
>
> Kyle Heon
> kh...@comcast.net
>
>
> -----Original Message-----
> From: Jeff Wood [mailto:jeff.da...@gmail.com]
> Sent: Wednesday, November 09, 2005 2:51 PM
> To: ruby-talk ML
> Subject: Re: Equvialent of RoboCode and/or Terrarium for Ruby?
>
> Heh, I've thought about building stuff like that many times ... the
> problem
> is, I'm a geek so I always gold plate it with user-definable
> weapons, etc
> ... smart weapons ... etc.
> Jeff Wood
>
>
>
-Ezra Zygmuntowicz
WebMaster
Yakima Herald-Republic Newspaper
ez...@yakima-herald.com
509-577-7732
Lyndon Samson
Adam Shelly
Daniel Sheppard
If you just want a port of robocode, I'd say a good approach would be to
take the existing robocode source code and replace existing classes with
Jruby. Once you've got the majority in Jruby, refactor that around to
make it more rubyish.
I'd imagine straight porting of the majority of the code would be a
fairly simple matter - it would only be once you started porting the GUI
that you'd be into hard stuff.
I'd also imagine that instead of running the code in a sandbox, you'd
instead expose something over dRB/some other sort of connection for
clients to connect to and fight it out. This would allow you to write an
adapter than would allow an existing robocode robot to enter the fray
(which would be a great kick-start, and also a great way to test).
Alternatively, you could just eval client code with appropriate $SAFE
levels (which would probably restrict cheating more). Or you could do
both.
Otherwise, you'd need to hash out a plan for a new environment for AI's
to play in - Maybe some sort of random maze to fight in? - Maybe a
capture the flag game?
Another fun AI thing to do is to write AI's for simple board/card games
(ie Ruby Quiz #51), although watching computer players play isn't
usually that much fun, it's much easier to insert a human into the game
that is turn-based, and it's usually not that hard to play in a
text-based environ. Poke around boardgamegeek and find something you
like and build a two player version with a nice interface and then send
it out for people to write AI's for. If you go this path, write your
game rules in a server program and have all the capturing of input and
displaying of things in client programs - this will normally you a
decent interface to build an AI on. Something like Carcassone has
extremely simple rules, but can provide a real challenge to win.
Even figuring out the winning rules to solo games such as Solitaire or
Sliding Puzzles can be a challenge, but more fun is had when there
unknown is in the form of another player (rather than just figuring out
statistics, which solves most solo games).
> -----Original Message-----
> From: Lyndon Samson [mailto:lyndon...@gmail.com]
> Sent: Thursday, 10 November 2005 4:47 PM
> To: ruby-talk ML
> Subject: Re: Equvialent of RoboCode and/or Terrarium for Ruby?
>
> Somebody should register something on rubyforge...
>
>
>
#####################################################################################
This email has been scanned by MailMarshal, an email content filter.
#####################################################################################
Lyndon Samson
may or may not
be a requirement/good thing.
I think set_trace_func would be usefull in limiting timeslices for the
AI/codelets.
The safest ( and most complicated ) method would to have one OS
process per AI, with some IPC ( shared mem etc ) method for
communication. But that sounds like architecture astronauticals... :-)
Dave Burt
> Somebody should register something on rubyforge...
Tim Bates registered rubots a few years ago.
The hard parts, as I see them, are:
1) The tournament framework - the "server" that runs the "client"
user-robots.
2) The graphical sub-system
Cheers,
Dave
Adam Sanderson
Does anyone remeber Robowar for the mac?
http://www.bemuzed.com/elmorian/robowar/robowar.html
It seems to be all but gone now, it and maybe CoreWars (?) were some of
the originals of these.
One thing that was interesting about Robowar was that you had a limited
set of hardware to choose from for your bot, and you could choose
things like a faster processor that let you execute code more quickly
than other bots.
Just a thought, but how would you avoid letting people cheat and
reprogram the rules from their bots? Run each one in SAFE=1 or what
not?
Could be damn fun ;)
.adam
Belorion
>
> Otherwise, you'd need to hash out a plan for a new environment for AI's
> to play in - Maybe some sort of random maze to fight in? - Maybe a
> capture the flag game?
>
>
http://www.rubyquiz.com/quiz31.html.
Matt
Hans Fugal
Java-free), but I have done some AI agent programming in Ruby. I've
also thought about writing a game world but never got around to it.
First, another existing project to check out is realtimebattle. I think
you could write something in ruby for that.
Jacob and I wrote ruby agents for an AI class using TCP sockets to the
capture the flag game server which has probably been retired since they
now do BZFlag agents instead of the shoddy CTF server we used then. But
the premise was simple enough: you talk to the server over a tcp
socket. You get precepts and send actions. I think this is far and away
the best approach. Yes, then someone can use any language they like,
and I think this is a good thing. It certainly helps not to get in the
way of its growing popularity.
The questions then go to what precepts and what actions. It is my
opinion that most people will be coming into a game like this wanting
to do something interesting as early as possible. Otherwise it will not
be fun and there will be a lot of half-written bots and few real ones.
So simplicity is key. If it were a serious AI tool you'd probably want
to make the precepts and so on configurable, but I say let it evolve
there if driven to.
A rough description of the game world I decided would probably be the
most fun follows.
The world is a 3D sphere in space. No gravity sources of consequence
are nearby. The agents are spherical (cow-shaped) pods with yaw, roll,
and pitch thrusters, and a front-mounted laser. When you shoot another
pod, the pod is frozen (can't fire thrusters or lasers) until a
teammate unfreezes it in the same manner. Flags are magnetic and so
when you get close enough, if your magnetic field is on, you have the
flag. You win by bringing the enemy's flag back to your base (a
predefined spherical region). Two teams. Each pod has an
omnidirectional limited range radar (does such a thing exist in the
real world? I have no clue), which is the only means for observing
objects. For simplicity (maybe this would be taken out for expert mode)
you are told your precise position when asked. If you try to go out of
bounds, you just don't. (e.g. you keep your momentum in other
directions, but just stop going outwards).
The server wouldn't be too hard, the hard part would be the vector
stuff (e.g. did that laser hit anyone?) and being time-independent from
the network stuff.
The clients would be easy, but since you're dealing with 3D and limited
information it is still an interesting AI problem.
The real hard part (from my perspective, probably not from someone
else's) is the graphical part that lets us humans watch and/or
participate.
I think such a game would be a lot of fun to write bots for, and if a
good UI is made has the potential to be a fun game for humans to play
too (both against bots and other humans).
Daniel Sheppard
> which may or may not be a requirement/good thing.
That's definitely the way I would go if I was trying to port robocode or
another existing framework, as it should be easy enough to build
adapters wherein the players written in the original language still
think they're within the original framework... which means you'll have a
great big pile of players to play against from day one.
Adam Sanderson
probably just use drb, might make things a lot easier.
Good concept for a game. I think with a simple concept, more
interesting mechanics can arise.
As far as the gui and such, it shouldn't really be that hard I think.
Pretty easy to do in OpenGL, at least a primitive implementation,
someone could make a fancier one later ;)
.adam
Reyn Vlietstra
that way we could have international battles with alot of spectators, does
robocode allow this ?
I'm also for an opengl implementation, guess using sdl for the first
renderer
would make sense so that things are cross platform.
Using drb/tcp makes sense if we'd like people to battle it out without
giving the other party their precious robot code.
So my call would be for a cross platform opengl/sdl implementation
connected to a seperate server which uses drb (porting other robots
should be easy enough)
--
Reyn Vlietstra
James Edward Gray II
> Sounds like a good Ruby Quiz to me.
I feel that recreating RoboCode, is a bit much for a Ruby Quiz. (If
you disagree, I welcome you to send me a complete solution showing
how easy it was.)
However, I'm very interested in a quiz to right the robots if someone
gets an engine together...
James Edward Gray II
James Edward Gray II
> Just a thought, but how would you avoid letting people cheat and
> reprogram the rules from their bots? Run each one in SAFE=1 or what
> not?
I think the easiest way is to select a client/server architecture.
James Edward Gray II
Daniel Sheppard
> 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 ?
>
> 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).
Reyn Vlietstra
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
James Walker
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.
Reyn Vlietstra
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 ?
--
Reyn Vlietstra
Dave Burt
> 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
Kyle Heon
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
kh...@comcast.net
-----Original Message-----
From: Dave Burt [mailto:da...@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?
Lyndon Samson
start kicking round ideas.
Adam Sanderson
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
Simon Kröger
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
Simon Kröger
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
J. Merrill
> 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/.
Adam Sanderson
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
Lyndon Samson
Kyle Heon
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
kh...@comcast.net
-----Original Message-----
From: Lyndon Samson [mailto:lyndon...@gmail.com]
Sent: Wednesday, November 23, 2005 6:44 PM
To: ruby-talk ML
Subject: Re: Equvialent of RoboCode and/or Terrarium for Ruby?
Leslie Viljoen
>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
>kh...@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
Mickael Faivre-Macon
> 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.
Leslie Viljoen
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
slow...@gmail.com
I would be more interested in seeing the strategical side of bots, so
the rules of the world should be as simple as possible to lessen the
amount of calculations needed to do anything that looks remotely smart
:)
A simple discrete (2D grid) space dimension with the Manhattan distance
metric and a discrete time dimension would be a good start. Bots would
always occupy a certain square, and movement would only be in the
N/S/E/W directions, no diagonals or other angles. Time would proceed in
ticks. You could even make the space dimension use the integers modulo
some n so that space would wrap around ;)
Extending this to be more complex (like diagonal movements) would
require a full, continuous 2D Euclidean space (and all the problems a
continuous world model brings). A mixed model would have
inconsistencies like multiple shortest paths from point A to point B,
though visually you would reason that there's only one (not necessarily
a bad thing, could try that out some day).
Speed can in most cases be expressed with integers, as ticks per
square, not squares per tick as one would normally expect. I haven't
studied this formally, but I assume that with this simple model the
arithmetic would stay in the rational domain, without complex
operations such as square roots and trigonometric functions.
On the other hand, the idea of having a library that would perform all
the complex calculations for you is good, but someone would have to
write it in the first place and at some point you would need to
understand it anyway to program more complex bots. Therefore, my vote
is for simplicity.
As for security - the process-per-bot model is probably the best, on
*nix systems it would be safe enough even with lower $SAFE levels than
4. The bot controller would start the bot process, pass it the
communication pipes/sockets/FIFOs, set resource limits (memory and CPU
usage), drop certain capabilities, chroot to a safe directory, set the
$SAFE level to 3 just in case, and then load the bot code.
drb is fine for prototyping, but I am not sure it can be restricted
enough to completely isolate the controller from ill effects of the bot
process. Passing simple messages serialized as YAML/JSON through
pipes/sockets seems like a good idea, this way the "brain" would be
completely isolated from the world. You could even write the bots in
languages other than Ruby.
A centralized server to submit bot code to and run matches/tournaments
makes finding decent opponents easier and removes the security risk
from the user side, since no foreign code runs on his computer. The
server could have a command-line, GUI and/or web front-end to submit
code, challenge other bots, view recorded matches etc. I could host the
server if necessary. (any of you folks on IRC? My nick isSlowByte on
freenode #ruby-lang)
Hmm, long post, and not even a mention of any rules. I guess a bot
could consist of various components such as motors, scanners (radars),
lasers, shields, machineguns, batteries, solar batteries, GPS systems,
all of which would use some sort of resource like energy or bullets.
The solar battery could slowly recharge the energy in any case, as not
to leave the bot dead in the water in case the energy runs out. The
bots would have a finite number of health points, the depletion of
those would be their demise.
The playing field could contain plain obstacles such as walls or
recharging/ammo/repair stations, creating points of contention that can
be exploited strategically. You could have teams and multiple bots
cooperating.
The program itself can use the energy, even - you can roughly measure
the amount of computation done by either CPU instruction cycles (not
portable across architectures) or using set_trace_func and the number
of method calls done (probably the best option).
So, here comes the main question - anyone interested in these ideas?
enough to discuss them? enough to write bots for them? enough to
implement them? :) Is there a wiki somewhere, or an IRC channel?