Equvialent of RoboCode and/or Terrarium for Ruby?

Just wondering if there is an equivalent to RoboCode (http://robocode.sourceforge.net/) or Terrarium (http://www.windowsforms.net/Applications/application.aspx?PageID=30&tabindex=8) currently available for Ruby.

It would seem to me that the dynamic nature of Ruby would make something like this pretty cool.

Thanks.

Kyle Heon

kheon@comcast.net wrote:

Just wondering if there is an equivalent to RoboCode
(http://robocode.sourceforge.net/) or Terrarium
(http://www.windowsforms.net/Applications/application.aspx?PageID=30&tabindex=8)
currently available for Ruby.

It would seem to me that the dynamic nature of Ruby would make something
like this pretty cool.

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

That could be really cool :slight_smile:
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 :wink:
  .adam

I've not used RoboCode (by the time I heard of it I was already happily
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).

I've not used RoboCode (by the time I heard of it I was already happily
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).

Hey, this looks like an interesting idea!

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
:slight_smile:

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 :wink:

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? :slight_smile: Is there a wiki somewhere, or an IRC channel?

Alternatively if you just wanted to make something for ruby, you could
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 :wink:
  .adam

I think the easiest way is to select a client/server architecture.

James Edward Gray II

···

On Nov 10, 2005, at 11:17 AM, Adam Sanderson wrote:

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?

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 ?

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)

···

On 11/12/05, Adam Sanderson <netghost@gmail.com> wrote:

Alternatively if you just wanted to make something for ruby, you could
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 :wink:
.adam

--
Reyn Vlietstra