On 14-01-09 01:24, Camden wrote:
  > Pre-script: I believe what I might have been remembering was Stéphan
Kochen's message 3122, which had the compiler running from the command
line, but it looks like the tournament utility wasn't fully functional yet.

Hmm... From what I remember, I had a working compiler and virtual
machine, with things like the turret and bullets working. I'll have to
go dig through that code now, hehe. :)

I do believe that, where I got stuck was trying to find a way to verify
my results. I was aiming for a near perfect copy of the simulation in my
version. (In fact, the thing loaded original Robowar robots stored in
MacBinary.)

-- Stéphan

If anyone can get me the source for either of these, I will sit down
with some programmers and try to do the remaining work that's needed.
I'm excited right now about this project I have going, so the sooner I
can get started on the meat of it, the better.

Stéphan, it sounds like you've done a lot of the work. if you want to
just take your code, add any vague notes pointing to what's still
unfinished in terms of the game engine, and send it my way, I'd be
happy to work with it from there.  When I've got some of my project
done (assuming it goes well), I'll be writing about it on my blog and
would love to point some readers to either RoboWar and/or the people
who helped set this up.

If anyone wants to talk to me about getting this working, feel free to
drop me a line on IRC -- I go by Randall on the irc.foonetic.net IRC
network, or xkcd163 on AIM.  (I'll be offline for a few hours now but
then back for the rest of the day.)

Best,

Randall

On Wed, Jan 14, 2009 at 2:16 AM, Stéphan Kochen <stephan@...> wrote:
> On 14-01-09 01:24, Camden wrote:
>> Pre-script: I believe what I might have been remembering was Stéphan
> Kochen's message 3122, which had the compiler running from the command
> line, but it looks like the tournament utility wasn't fully functional yet.
>
> Hmm... From what I remember, I had a working compiler and virtual
> machine, with things like the turret and bullets working. I'll have to
> go dig through that code now, hehe. :)
>
> I do believe that, where I got stuck was trying to find a way to verify
> my results. I was aiming for a near perfect copy of the simulation in my
> version. (In fact, the thing loaded original Robowar robots stored in
> MacBinary.)
>
> -- Stéphan
>
>

On 14-01-09 17:34, Randall Munroe wrote:
  > If anyone can get me the source for either of these, I will sit down
  > with some programmers and try to do the remaining work that's needed.
  > I'm excited right now about this project I have going, so the sooner I
  > can get started on the meat of it, the better.

Having more people chip in does make it exciting. :)
How are you planning to work on this? Is your sit-down an offline or
online thing? If it's an offline thing, I wouldn't want to impede on
your sprint, but I'd love to play with your work afterwards.

  > Stéphan, it sounds like you've done a lot of the work. if you want to
  > just take your code, add any vague notes pointing to what's still
  > unfinished in terms of the game engine, and send it my way, I'd be
  > happy to work with it from there. When I've got some of my project
  > done (assuming it goes well), I'll be writing about it on my blog and
  > would love to point some readers to either RoboWar and/or the people
  > who helped set this up.

Do mind that it's C# code, though intended to be portable through Mono.
It was a school project, and C# and Windows were traits that came with
the project. But my primary platform has always been an Ubuntu desktop.

I'll see about documenting the code this evening.

  > If anyone wants to talk to me about getting this working, feel free to
  > drop me a line on IRC -- I go by Randall on the irc.foonetic.net IRC
  > network, or xkcd163 on AIM. (I'll be offline for a few hours now but
  > then back for the rest of the day.)

Just logged on as stephank, and will be lurking in #xkcd. (Will try not
to break up this thread and take it off list though, seems only polite.) :)

-- Stéphan

> Having more people chip in does make it exciting. :)
> How are you planning to work on this? Is your sit-down an offline or
> online thing? If it's an offline thing, I wouldn't want to impede on
> your sprint, but I'd love to play with your work afterwards.

Well, I have a couple offline friends who might be interested in
taking a look, but I don't know how I'm doing this yet.  It sort of
depends on how much needs to be done -- my end goal is to have a
program I can call, passing it robot code files as arguments, which
will just give back the result of the ensuing battle.  So if you want
to help out with that, I'd be happy to do this 'sit-down' with you
online somehow.  I haven't worked on a project like this before so I
don't know the most efficient way of doing all this.

-- Randall

On 14-01-09 22:51, Randall Munroe wrote:
  > Well, I have a couple offline friends who might be interested in
  > taking a look, but I don't know how I'm doing this yet. It sort of
  > depends on how much needs to be done -- my end goal is to have a
  > program I can call, passing it robot code files as arguments, which
  > will just give back the result of the ensuing battle. So if you want
  > to help out with that, I'd be happy to do this 'sit-down' with you
  > online somehow. I haven't worked on a project like this before so I
  > don't know the most efficient way of doing all this.

Me neither.

I'm more casually interested; I am excited to see people jumping in on
getting the game back alive again. In reality, I have precious little
time to contribute. I'd say about 20 hours a week tops, not taking
motivation into account. :)

I uploaded a source-only tarball of what I have here:
http://stephan.kochen.nl/proj/RoboWarX.tar.gz

I littered the thing with comments and summed up some of the bigger
things I found to be still missing. I noticed I actually implemented
missiles and graphics scaling since the last code drop I made. But the
GTK+ UI seems broken somehow. (Didn't even look at the Winforms UI.)

Anyways, curiosity will keep me around here, probably forever. And I may
help out a bit. :)

-- Stéphan

> I uploaded a source-only tarball of what I have here:
> http://stephan.kochen.nl/proj/RoboWarX.tar.gz

Excellent!  I have mono, but I'm not actually sure how to go about
compiling anything that doesn't come with a neat Makefile.

> I littered the thing with comments and summed up some of the bigger
> things I found to be still missing.

Okay, so from your list, here are the things that I will be trying to
get done for my project::

  - Interrupts
  - Many weapons (just bullets and missiles implemented)
  - Still a couple of special operators and registers
    (history, channel, signal, for example)
  - Headless / command-line interface

I don't particularly need a built-in:

  - Editor
  - Debugger

but I'll want to edit robots in a text editor -- does one of the
formats make this easy?  I don't remember.

Given these goals, can you estimate what's needed to get it done?  Any
general pointers as to where I (or whoever) would start?

-- Randall

> Anyways, curiosity will keep me around here, probably forever. And I may
> help out a bit. :)
>
> -- Stéphan
>
>

> Excellent! I have mono, but I'm not actually sure how to go about
  > compiling anything that doesn't come with a neat Makefile.

There's a MonoDevelop solution included. You can either use MonoDevelop,
or if you use something else, it looks like "mdtool build" does a
complete build from the command line.

For simple stuff, like adding a source file, you might even be able to
edit the project files with a text editor.

  > Okay, so from your list, here are the things that I will be trying to
  > get done for my project::
  >
  > - Interrupts
  > - Many weapons (just bullets and missiles implemented)
  > - Still a couple of special operators and registers
  > (history, channel, signal, for example)
  > - Headless / command-line interface
  >
  > I don't particularly need a built-in:
  >
  > - Editor
  > - Debugger
  >
  > but I'll want to edit robots in a text editor -- does one of the
  > formats make this easy? I don't remember.

Not really, they both contain non-textual stuff. But it shouldn't be
hard to implement. You'll find the file formats in LibRoboWarX/FileFormats.

The RobotFile class in there is the in-memory representation of a
robot's data. (Not to confuse with LibRoboWarX/Arena/Robot, which
contains runtime state.)

The other classes simply open a file, create such a RobotFile instance
and fill it.

In fact, this might do it for reading a text file as a test:

================================================================================
using System;
using System.IO;

namespace LibRoboWarX
{
      public static class SourceTestLoader
      {
          public static RobotFile read(String filename)
          {
              RobotFile result = new RobotFile();
              StreamReader f = new StreamReader(filename);

              // Induce the robot name from the filename
              f.name = Path.GetFileNameWithoutExtension(filename);
              // Read the source
              f.code = so.ReadToEnd();
              // Immediately compile for convenience
              f.compile();

              // Default hardware is rather minimal, see
LibRoboWarX/Arena/Robot.cs
              // Perhaps set some useful values here for testing
              f.hardware.hasMissiles = true; // These already work! Woo!

              return f;
          }
      }
}
================================================================================

Come to think of it, a text only format would be nice. Maybe we can get
hardware settings from a comment block near the top of the file? In
YAML? Hmmm... :)

  > Given these goals, can you estimate what's needed to get it done? Any
  > general pointers as to where I (or whoever) would start?

Let's see.


Interrupts are stubbed out in places. Most notable is the
processInterrupts method in LibRoboWarX/VirtualMachine/Interpreter.cs.
This is called from LibRoboWarX/Arena/Robot.cs, and I believe that's the
correct position where RoboWar used to process interrupts as well.

You'll find that all (interrupt) registers subclass from the abstract
class LibRoboWarX/Arena/Register.cs and implement the
LibRoboWarX/Global/ITemplateRegister interface. (I'm not sure why I made
those separate.) The Register class has methods called fireInterrupt,
checkInterrupt and updateInterruptState.

I suppose checkInterrupt would be called from processInterrupts.

fireInterrupt would be called if checkInterrupt returned positive, but
it might be obsolete if all interrupts do is push to the stack and
change the PC.

updateInterruptState is a mystery even to me. Must've seemed like a good
idea at the time.

One thing I remember is that I didn't take into account the order in
which interrupts are fired yet.


Weapons are hopefully easy to implement. That was one of my original goals!

You'll find the Missile is probably the simplest example. Simply a
Register class that the compiler and virtual machine can use, and a
Projectile class to do your worst.


You can probably scrap the 'remaining operators' from your list. They're
things like: print, debug, snd, beep, icon and mrb(?). Things you
shouldn't care much about, especially for a headless and debuggerless
interface. For reference, they live in
LibRoboWarX/VirtualMachine/Operators.cs. There's some commented original
RoboWar C code in places that are still lacking.

The registers are more interesting. Especially the team communication
stuff like channel and signal. See LibRoboWarX/Arena/StockRegisters.cs
for those. I've included excerpts from the original RoboWar manual as
comments.


A headless interface also should not be difficult to get running
quickly. The bulk of the code in the current GUI frontends really only
touches the GUI. You should be able to figure that out.

I have not given the public interface of LibRoboWarX much thought yet.
But it works for getting a game going.


That's as much as I can ramble about without getting specific questions. ;)

-- Stéphan

Replying to self. :)

As a starting point, a Google Code project has been created. You can
find it at:
http://code.google.com/p/robowarx/

I've checked in the source there, and did a tad of additional work on it:

   * Got the GTK+ GUI in a somewhat working state again. It now uses the
GtkUIManager, though MonoDevelop doesn't seem to integrate with that
yet. (Looks like it's planned for MD 2.0.)

   * Added the very basic text-only robot format. (The example code in my
last mail was rather trashy, tbh.) Simply create a text file with the
.rtxt extension and open it.

Randall, I'll need your Google account name to add you as project owner.

-- Stéphan

On 19-01-09 17:30, Camden wrote:
  > As for a sophisticated way of verifying, I'm not sure I can think of
one.  But I think Kevin, Eric Foley, and I have a pretty intimate feel
for the mechanics since we were all reviewing the old mac source at
important points for the windows VB port.  And others likely have as
well.  I'd be happy to try to clarify any points you might have
questions about, though I'm honest enough with myself now to know I'm
not as interested in working as hands on on yet another rewrite. >.<

Most of the simulation mainloop code in the C# version has a pretty
clear resemblance to the original; I pretty much copy pasted and then
rewrote parts.

One thing I'm wondering about is the behavior of Random(). Both the
original and the C# version use whatever the system makes available, but
I doubt that's the same underlying implementation. Not sure if it should
be a focal point now, it's minor.

Maybe if I can get my hands on the C compiler used to compile the
original RoboWar, I could add some functionality to the original RoboWar
for writing a binary log of sorts to a file; take a snapshot at every
chronon. Rather like modern games record replays. Implementing the same
in the C# version would then allow me to compare the logs and pinpoint
where things don't match.

Know of a place where I can obtain that compiler? :)

-- Stéphan

I can ask Prfnoff about this tonight.  I'll relay the answer here.

I don't feel confident enough to do much with the current code, such
as fill in the code for stunners or implement interrupts, but I may
poke around and see if I can implement command-line mode somehow.

-- Randall

On Mon, Jan 19, 2009 at 2:48 PM, Stéphan Kochen <stephan@...> wrote:
> On 19-01-09 17:30, Camden wrote:
>> As for a sophisticated way of verifying, I'm not sure I can think of
> one. But I think Kevin, Eric Foley, and I have a pretty intimate feel
> for the mechanics since we were all reviewing the old mac source at
> important points for the windows VB port. And others likely have as
> well. I'd be happy to try to clarify any points you might have
> questions about, though I'm honest enough with myself now to know I'm
> not as interested in working as hands on on yet another rewrite. >.<
>
> Most of the simulation mainloop code in the C# version has a pretty
> clear resemblance to the original; I pretty much copy pasted and then
> rewrote parts.
>
> One thing I'm wondering about is the behavior of Random(). Both the
> original and the C# version use whatever the system makes available, but
> I doubt that's the same underlying implementation. Not sure if it should
> be a focal point now, it's minor.
>
> Maybe if I can get my hands on the C compiler used to compile the
> original RoboWar, I could add some functionality to the original RoboWar
> for writing a binary log of sorts to a file; take a snapshot at every
> chronon. Rather like modern games record replays. Implementing the same
> in the C# version would then allow me to compare the logs and pinpoint
> where things don't match.
>
> Know of a place where I can obtain that compiler? :)
>
> -- Stéphan
>

It looks like, to get a headless mode working, I should just skip the
RoboWarX.GTK and instead make a new program that just instantiates an
arena object using LibRoboWar.  A friend and I are playing with this
-- if you're around, Stéphan, feel free to drop me a line on IRC to
offer any advice :)

-- Randall

On Wed, Jan 21, 2009 at 10:39 AM, Randall Munroe <randall@...> wrote:
> I can ask Prfnoff about this tonight.  I'll relay the answer here.
>
> I don't feel confident enough to do much with the current code, such
> as fill in the code for stunners or implement interrupts, but I may
> poke around and see if I can implement command-line mode somehow.
>
> -- Randall
>
> On Mon, Jan 19, 2009 at 2:48 PM, Stéphan Kochen <stephan@...> wrote:
>> On 19-01-09 17:30, Camden wrote:
>>> As for a sophisticated way of verifying, I'm not sure I can think of
>> one. But I think Kevin, Eric Foley, and I have a pretty intimate feel
>> for the mechanics since we were all reviewing the old mac source at
>> important points for the windows VB port. And others likely have as
>> well. I'd be happy to try to clarify any points you might have
>> questions about, though I'm honest enough with myself now to know I'm
>> not as interested in working as hands on on yet another rewrite. >.<
>>
>> Most of the simulation mainloop code in the C# version has a pretty
>> clear resemblance to the original; I pretty much copy pasted and then
>> rewrote parts.
>>
>> One thing I'm wondering about is the behavior of Random(). Both the
>> original and the C# version use whatever the system makes available, but
>> I doubt that's the same underlying implementation. Not sure if it should
>> be a focal point now, it's minor.
>>
>> Maybe if I can get my hands on the C compiler used to compile the
>> original RoboWar, I could add some functionality to the original RoboWar
>> for writing a binary log of sorts to a file; take a snapshot at every
>> chronon. Rather like modern games record replays. Implementing the same
>> in the C# version would then allow me to compare the logs and pinpoint
>> where things don't match.
>>
>> Know of a place where I can obtain that compiler? :)
>>
>> -- Stéphan
>>
>

On Oct 2, 2006, mark.wagner17@... wrote:

I'm still here but haven't done any coding for quite some time. Still
got ideas though but as Camden says there isn’t much glory in fighting
yourself. But then again if anything would happen I guess I would
reactivate myself.


Randall may one ask about that robowar-related project or is it secret?


Camden skrev:
>
>
> There is still a group. Not much activity to be seen though.
> I strangely still think about bot ideas from time to time, but am
> usually content to let them remain theoretical. There isn't much glory
> in a graveyard (unless there are zombies). Maybe when/if the old
> coders start showing it to their kids there can be a resurgance.
> That's right, the impetus is on You.
> Camden
>
> ------------------------------------------------------------------------
> *From:* Randall Munroe <randall@...>
> *To:* robowar@yahoogroups.com
> *Sent:* Friday, July 3, 2009 6:23:11 PM
> *Subject:* Re: [robowar] Is this groups still active
>
> I'm here. I did some work on a cool Robowar-related project later last
> year, and will probably do the rest of it soon. It might get the game
> some press.
>
> -- Randall
>
> On Fri, Jul 3, 2009 at 2:56 PM, paul olson <paul_olson@go. com
> <mailto:paul_olson@...>> wrote:
>
>
>
>
>     I was just rumaging around in my mailbox and found my old RoboWar
>     folder. Is this group still active?
>
>     Paul Olson
>
>
>     On Oct 2, 2006, *mark.wagner17@ gte.net
>     <mailto:mark.wagner17@...>* wrote:
>
>         On Saturday 30 September 2006 11:42, erik aas wrote:
>         > Hi,
>         > When I ran the program last spring (when it was in a very
>         unprofessional
>         > form) I got the impression that it was faster than RW5. By
>         then, all
>         > registers that should be regarded as significantly
>         time-consuming were
>         > implemented and the graphics were inefficient (I cleared the
>         entire screen
>         > between each rendering) and it ran in Windows. I do believe
>         that 1000-cpu
>         > robots and satisfactorily fast execution could be a
>         possibility with the
>         > new version.
>
>         Based on my experience with RoboWar II, the limiting factor in
>         execution speed
>         is graphics, not robot processing. Robots at 1000 or even 10,000
>         instructions per chronon would be no problem.
>
>         --
>         Mark
>
>
>
>         Yahoo! Groups Links
>
>
>         (Yahoo! ID required)
>
>         mailto:robowar-fullfeature d@yahoogroups. com
>         <mailto:robowar-fullfeatured@yahoogroups.com>
>
>
>
>
>
>
>
>
>

My son Robert Hogg was very into RoboWar at one time. He is now a robotics
engineer at NASA's Jet Propulsion Lab. He and I and three others have an iPhone
software business on the side called Toy Kite Software and we just released our
first game called iSamurai: Two-Player Sword Fight.

Lately I have been thinking that it would be awesome to have a
commercially-viable successor to RoboWar, perhaps running on the iPhone. Among
other things, it would provide a vehicle for teaching programming in schools and
clubs. We have an intern at our company learning C and I know that he would go
faster if he could program some robots.

:-)

Doug Hogg
http://toykite.com

Heh... I remember some of those old days.  Robert had a flair for coming up with different ideas that seemed very simple and yet held a broad effectiveness.  In a lot of ways that's the style that I came to miss when the game's doppler register and high speed CPUs started to force everybody to use tracking algorithms and be prepared to kill or die as soon as the starting gun went off.

For what it's worth, I've finished my second degree at the Art Institute of Portland and have been working for Backbone Entertainment in Emeryville, California the last three-plus years as a game programmer and sometimes-designer.  On the other hand, I never quite forgot RoboWar even besides just getting the occasional note on the group.

Putting a successor RoboWar on the iPhone might be kind of neat, although I think it would probably have to be much-simplified from the original, because I'd tend to think that the iPhone wouldn't be a very good platform for coding bots in anything that resembles the meta-assembly language that they were written in 20 years ago.  (Yeek... it's really been almost 20 years now.  I feel old.)

Good to hear from you all...

-----Original Message-----
From: Doug Hogg
Sent: Jul 5, 2009 3:17 AM
To: robowar@yahoogroups.com
Subject: [robowar] Re: Robowar Group

My son Robert Hogg was very into RoboWar at one time. He is now a robotics engineer at NASA's Jet Propulsion Lab. He and I and three others have an iPhone software business on the side called Toy Kite Software and we just released our first game called iSamurai: Two-Player Sword Fight.

Lately I have been thinking that it would be awesome to have a commercially-viable successor to RoboWar, perhaps running on the iPhone. Among other things, it would provide a vehicle for teaching programming in schools and clubs. We have an intern at our company learning C and I know that he would go faster if he could program some robots.

:-)

Doug Hogg
http://toykite.com

I have a continuing but dormant interest in at some point more or less rewriting
Robowar with Qt or something like that.  I'm not under any illusions that it'll
bring users to the game or anything like that; it's more that I just think it
would be fun if my Real Job wasn't already just piles of C++ most of the time.


I periodically introduce Robowar to people who really would have fit the Robowar
mold fifteen years ago, usually along with a pile of incomprehensible
nostalgia-babble about Titans and "giants in the field" and that sort of thing
(if JF Lechat knew how much I revere him he'd fall out of his chair laughing). 
What tends to happen when I show it around is that it just looks too dated to be
interesting, and I have to admit that even as a guy who writes snappy code with
crappy interfaces all the time, I would not look at it and expect to find depth
and difficulty under the hood.  It still looks like 1990.


Aside from questions about rules evolution and whether there's any unexplored
creative space for new robots, what seems sorta busted about Robowar to me right
now is that the, uh, "toolchain" is completely idiosyncratic.  It doesn't act
like a modern IDE, and there isn't an alternative command-line "toolchain" that
will feel somehow familiar to CLI people.  I think it'd be a lot more appealing
to play around with if it seemed like a nerd game again instead of a legacy
game.


Nerds aren't gone from the world, but Robowar looks more dorky than nerdy at
this point.  (Uhh, amirite?)


It seems a shame as well that Robowar had so many hard-coded limits in it.  It
would be lots of fun to see bigger arenas, more robots, more interesting
environs, but *none* of the old robots could function in that environment
because of all the magic numbers (300, 30, anything you vstored, etc.).  The
only thing Moore's Law has brought to Robowar is the capacity to run more and
more tournament rounds.  Although... well, actually it would probably not be too
much work on a robot-by-robot basis to tweak the codes to make use of such
constants.  A few people could retrofit all the robots from past tournaments to
work with variable arena size and number of robots in pretty short order, I
suspect.  If we look at the tournament entrants as the "canon" it would be a
pretty entertaining project to convert it upwards to something that could be run
with bigger arenas etc.


Oh, and hi everybody!  Fun to hear from you Doug; I distinctly remember matching
up my creations against Robert Hogg's when I started learning Robowar.

Paul

ps -- i had nice paragraph spacing when i wrote this but the preview keeps
scuttling them.  here's hoping it looks nice anyway when I post it...

--- In robowar@yahoogroups.com, "Paul" <plisdku04@...> wrote:
>
> I have a continuing but dormant interest in at some point more or less
rewriting Robowar with Qt or something like that.  I'm not under any illusions
that it'll bring users to the game or anything like that; it's more that I just
think it would be fun if my Real Job wasn't already just piles of C++ most of
the time.

> It seems a shame as well that Robowar had so many hard-coded limits in it.  It
would be lots of fun to see bigger arenas, more robots, more interesting
environs, but *none* of the old robots could function in that environment
because of all the magic numbers (300, 30, anything you vstored, etc.).  The
only thing Moore's Law has brought to Robowar is the capacity to run more and
more tournament rounds.  Although... well, actually it would probably not be too
much work on a robot-by-robot basis to tweak the codes to make use of such
constants.  A few people could retrofit all the robots from past tournaments to
work with variable arena size and number of robots in pretty short order, I
suspect.  If we look at the tournament entrants as the "canon" it would be a
pretty entertaining project to convert it upwards to something that could be run
with bigger arenas etc.

Actually, I think RoboWar could perhaps be done quite nicely in HTML5 using
<canvas>. Would be interesting to try that.

Responding here to Paul, the other possibility is to take what's great and make
a new game based somewhat on RoboWar. The downside of course is it isn't
RoboWar.

I guess my take on the whole idea is... RoboWar as we knew it and loved it was a wonderful game, but as it was I think it was very much "played out".  People were coming up with new nuances but for the most part it was quickly coming down to either (a) finding cuter ways to juke and jive while you're stunning people to death, or (b) passive defending bruisers.  Titans could afford to be both, mortals had to get a bit more elaborate with their group modes to avoid getting hurt.

At some point, I think some of the limitations of the game were, the robots were a little too intelligent, a little too capable of finding one another, tracking one another, and quickly killing one another.  I still find myself missing the old days of limited-intelligence robots whose search techniques were as much or more a function of their movement as they were the facing of their turrets.  While Excelsior was a beautiful machine, it also was kind of the beginning of the end of that day when limited vision kept robot variety very distinct.  I mean... let's be real here.  Except for the aberration of T13, pretty much every robot even in the mortal ranks, and literally every robot in the titan ranks, after the invention of doppler and interrupts was based upon an algorithm of constant search-and-track.  The only variety lay in what the robots did with the information and in how they attempted to manage the group rounds until they got to a point of being able to engage their tracking algorithms against a lone survivor.

I think that a new RoboWar would be a blast, but I think that a clear redesign is definitely in order.  I think that the weapons should be less deadly, the robots' intelligence about their surroundings should be both more limited in terms of being able to find the enemy perfectly but perhaps be less limited in being able to maneuver around obstacles -- i.e. perhaps robots could fight in a random maze and traversing the maze becomes part of the game instead of tracking one another directly through an empty arena.  I don't know... at some point, the game got a little less interesting for me to want to put much energy into innovating completely new tactics when utlimately every fight between competently constructed bots was going to end at the first good hit.

E

-----Original Message-----
From: themaskedphantom
Sent: Aug 14, 2009 9:49 PM
To: robowar@yahoogroups.com
Subject: [robowar] Re: Robowar Group

 

--- In robowar@yahoogroups.com, "Paul" <plisdku04@...> wrote:
>
> I have a continuing but dormant interest in at some point more or less rewriting Robowar with Qt or something like that. I'm not under any illusions that it'll bring users to the game or anything like that; it's more that I just think it would be fun if my Real Job wasn't already just piles of C++ most of the time.

> It seems a shame as well that Robowar had so many hard-coded limits in it. It would be lots of fun to see bigger arenas, more robots, more interesting environs, but *none* of the old robots could function in that environment because of all the magic numbers (300, 30, anything you vstored, etc.). The only thing Moore's Law has brought to Robowar is the capacity to run more and more tournament rounds. Although... well, actually it would probably not be too much work on a robot-by-robot basis to tweak the codes to make use of such constants. A few people could retrofit all the robots from past tournaments to work with variable arena size and number of robots in pretty short order, I suspect. If we look at the tournament entrants as the "canon" it would be a pretty entertaining project to convert it upwards to something that could be run with bigger arenas etc.

Actually, I think RoboWar could perhaps be done quite nicely in HTML5 using <canvas>. Would be interesting to try that.

Responding here to Paul, the other possibility is to take what's great and make a new game based somewhat on RoboWar. The downside of course is it isn't RoboWar.

http://code.google.com/p/robodrome/

There's still a lot of work to do (features, UI, code cleanup), but you can
build robots, and they fight! There are instructions in the wiki for building
the source, it should all work fine in Ubuntu 9.04, ymmv with other distros. The
project is written in C++ using gtkmm, cairo, and google protocol buffers for
save files.

Progress is on hold for the moment, but I'll pick it up again at some point.
Right now I have little capacity for activities at home.. Work soaks up all my
energy.

Hello, RoboWarriors and Masters! Thanks to the list operator for letting me in;
the mailing list doesn't seem to get much activity these days, and it was very
prompt on his part.

While I consider RoboWar to be one of my preferred games, my history with it is
largely as a spectator. I did participate in T23 and T24, but my bots were
ineffectual, at best; they mostly relied on a hodgepodge of open-source code,
and even then weren't particularly good. Whenever I chose to make something of
my own, it was even worse. See Clavius/Kronos in T24 for examples of the former,
and 'Nonmagic Sword' in T23 for an example of the latter. I've been working on
making something a bit better; it can reach the corners nicely, but I still
haven't gotten it to crawl along the walls yet.

Most of my experience with the game comes through time spent watching bots fight
it out. I admit that most of this time, the attention I gave it was rather
mindless and focused more on the explosions than the code or the data, but
nevertheless, I've seen a large variety of bots in action, from tournament I to
XXV.

It seems that things've slumped a bit in the past few years; while I haven't
been here with you to discuss all the details, I believe that there's been a
fair amount of discontent expressed, over the continued existence of the
move-shoot rule, and with the state of bots in general. It's been said that most
of them are 50-processor bots; while the success of Erika has diminished this a
little, it is still true that all effective bots released nowadays use 30 or
more processor speed. There have been new features that people strove to
implement, such as the nearest' register, but for various reasons, it didn't pan
out.

In one of the more recent postings (I believe it still shows up on the front
page), Eric Foley, the Lord of the Darkbringers, suggested that perhaps RoboWar
has been played out. This could very well be true; I don't pretend to know for
sure whether or not this is the case.

But, for better or for worse, what we have is what we have, and even if RoboWar
is to finally meet its end, it would be nice to give it a great sendoff. If
these changes happen to keep it alive and well, then that, of course, is a great
success.

I would like to run a tournament that imposes some extra hardware costs for some
registers and other data. The new hardware store would be as follows (everything
that isn't mentioned is assumed to be as before):

Other weapons:
Laser (1)
Drones (1)

CPU Size:
5000 (2)
1500 (1)
500 (0)

The new CPU size change would put more restrictions on more complex bots; I feel
that this could be a good idea mostly because I feel that robots shouldn't
necessarily always be built as ends in themselves; there should be room for the
programmers to guess their opponent's intents pre-tourney, and work on
specialized bots designed to counter those foes. Look at the Lug, for instance,
from Tournament V; it goes to the center of the screen and periodically shoots
missiles off at the corners. It would get demolished by practically any
self-respecting bot ever made in solo combat. But because the author understood
the dynamics of group combat so well, and additionally designed it to take
advantage of some weaknesses in the prior tournament's bots, it still managed to
slide into a second-place win. Back in the day, 'defending champions' almost
never successfully protected their crown; I believe the first recurring number-1
bot was Jade. Having, on average, more bots that rely on surprise to win a
one-time victory, would be a good thing, I think. At the same time, this still
allows for more complex bots to be devised; they just have to make better use of
their equipment.

Doppler (1)

The reason for putting cost on doppler is largely the same as the previous one;
bots without it would be either more complex code-wise (and more likely to bump
up against hypothetical limits), or simpler, custom-built one-shot warriors,
built to win the tourney or die, since their logic'll be countered by the time
of the next tournament.

Interrupts (1)

The reason for putting a price on this fits largely in with the previous two.
Another cause, though, for why I chose this is because all of these features
have been added in, for free, with the passing of tournaments; new hardware had
a price, but these features were simply taken for granted. The average bot
became much more complex. This does put a price on those new features, but at
the same time, rewards more advanced programmers, who are able to (in a system
where people've long gone without the use of the hard-developed aiming
mechanisms) take full advantage of their limited development space.

Negative Energy Allowed (1)

This assumes that the default is No Negative Energy, and that the right of going
into negative energy must be bought.

This is the concept I feel the most strongly about; NNE is chronically
underused, and we can see why. Negative energy allows for killshots, large move
commands, and all sorts of things, even for bots with very limited energy tanks.
With negative energy, even 40 energy is enough to produce a shot that'll kill
any other bot in the arena.

NNE as default brings this era to an end. You have to focus more on making all
of your bot's shots count, and bots without negative energy rely more on their
existing batteries, making there be more of a focus on higher-energy bots, in
general. Bots that are equipped with negative energy capability have less room
for other hardware. I would even not necessarily be against banning negative
energy outright, except that I feel this could make for a more interesting game,
to have the chance for choice.

In the wake of all these changes, none of which explicitly require changes to
the game, I would like to run a tournament with the following categories:

Miniature (6)
Individual (9)
Heroic (13)
Colossal (19)
Team (18 into 2)

All of the above should be familiar, or recognizable, except perhaps the team
section.

I've given teams a fair amount of thought, and, in this tournament, would do two
things to change them up. The category, historically, has experienced a lot of
trouble; after viewing the T25 team bots, I'm inclined to say that the change
was, fundamentally, a failure. It doesn't resolve the real problems with the
category.

Instead of the two-teams-of-three bots arrangement, this team arrangement would
be similar to the old, except with two significant changes.

1. You have 18 hardware points, to allot into two bots. You can outfit either
one of the bots as you choose -- you can give one bot all 18 points, and leave
the other as a 0-point paperweight, you can split it evenly, or you can allocate
it any other way you want.
2. Team group battles. You might wonder how I intend to do this; after all, the
capability doesn't exist in either the most recent version of Mac RoboWar, or in
the Windows edition either, for that sort of contest. The solution to this
problem is simple; I'd do it manually.

I've already run the teams from Tournament 13 in a mock tournament, with group
battles, to get a handle for how the system will play out. While I need to do
more research on the exact working of individual group battles, the basic idea
is to start with the first team, in alphabetic order, and go all the way down
through the list; in the example of the T13 bots, we'd start out with Mr.
Segruet's bots in first slot, and have the next teams arrayed in second and
third slot, in alphabetical order. After six (or however many) battles are run
from that particular bout, we change team 3, until all the possible third teams
that the first two teams could fight are exhausted. Then we change team 2 to be
the next team after that, and so on. Every team plays every other possible
combination of two teams in a bout.

Afterwards, based on a combination of the duel and group scores, the top three
teams go on to the Finals; they engage in three bouts, to cover all the possible
two-team fights, then all three teams are put in and play through a
proportionately higher number of group fights, enough to cover all the
hypothetical alignments of teams into slots (WC 1/WC 2/WC 3, WC 1/WC 2/WC 3,
etc.)

I feel this has a good chance of bringing some extra interest into the team
mode; even if it is basically just a larger-scale individual tournament, it's
better to have the whole tourney than just the solo rounds.

Please let me know what you think of all of these ideas. I would like to open up
this 'hypothetical' tournament, which I've tenatively titled "Legacy", for
entries relatively soon, but it's important that I have some feedback on the
concepts it'll be based off of before I commit to a hard set of rules.

Sorry for the wall of text, though I reckon it'll be a nice change of pace for a
lot of you, given the inactivity of the list lately. Thanks for reading this
far.

Yours,
  James Gryphon

On Friday 20 November 2009 10:07:07 am james.gryphon wrote:
> Interrupts (1)
>
> The reason for putting a price on this fits largely in with the previous
> two. Another cause, though, for why I chose this is because all of these
> features have been added in, for free, with the passing of tournaments; new
> hardware had a price, but these features were simply taken for granted. The
> average bot became much more complex. This does put a price on those new
> features, but at the same time, rewards more advanced programmers, who are
> able to (in a system where people've long gone without the use of the
> hard-developed aiming mechanisms) take full advantage of their limited
> development space.

I think you're seriously underestimating the value of interrupts here.  I've
written bots with and without interrupts, and I've looked at the performance
of other bots both with and without.  I'd estimate that activating interrupts
is equivalent to a four-fold increase in CPU speed: a bot that polls
registers rather than setting up interrupts needs to make two reads (range
and radar) for every adjustment of the turret, plus a check for shield level
every chronon.  A no-interrupts bot would need movement patterns carefully
designed to avoid periodic reads of the x and y registers, where an
interrupt-enabled bot can move freely.

> Negative Energy Allowed (1)
>
> This assumes that the default is No Negative Energy, and that the right of
> going into negative energy must be bought.
>
> This is the concept I feel the most strongly about; NNE is chronically
> underused, and we can see why. Negative energy allows for killshots, large
> move commands, and all sorts of things, even for bots with very limited
> energy tanks. With negative energy, even 40 energy is enough to produce a
> shot that'll kill any other bot in the arena.

You're missing the other major use of negative energy here: the "hesitator"
tactic.  A hesitator periodically drops slightly into negative energy to
throw off tracking bots: doing so provides a free speed change.  Done right,
the doppler register will alternate between full speed and 0, while the
actual speed is half or a third that, or even irregular.

Given the tactical value of these two options, I'd expect every bot except
maybe some of the miniature-class bots to take them: two hardware points will
give a speed-120 or speed-200 CPU, and a massive increase in survivability.
If I wanted to encourage alternatives, I'd value interrupts at 3 or 4
hardware points, and negative energy at 2.

The tournament idea looks interesting, and if I can find a RoboWar that works
on my computer, I'll have a few bots to enter.

--
Mark

If I had it in my hands to redesign the game, I'd have all sorts of thoughts, some of which I'd like to see, some of which I'm not as sure of.

The nearest register was sort of my idea in the beginning, and the idea of it was to try to reduce the gap between the high proceesor speed bots and the lower ones by allowing them to always be able to instantly lock on the nearest enemy (or, in a duel, your opponent), which was always the biggest advantage of the higher processor speeds.  The main worry I have out of that is that it would pretty much laminate the idea of opposing tracking algorithms into the game forever.  To some degree, I've always had a nagging feeling that the game was more interesting when you _weren't_ able to effectively track your opponent all the time, so I don't know if I'm as big of a believer in this any more.

Whatever the case, I think that high speed CPUs are clearly underpriced.  And to some degree I also think that the effect of interrupts, as Mark observes, has been underestimated as well, giving the higher speed CPUs a lot more power than was anticipated.  From this point, it was no longer a question of whether tracking algorithms performed by sheer number crunching and optimization were going to rule the game, but by how much.  I don't think any official tournament since interrupts were brought into the game has been won by anything _but_ a 50-CPU bot except for the admitted aberration of T13, when a couple of bruisers using unmaintained shielding at the beginning of the round managed to do just enough damage in the group rounds that they were able to tie for first narrowly ahead of their higher tech competition even though all the high tech stuff utterly demolished them in solo mode.  Even though I was one of the bruisers in question I'm freely willing to admit that that was kind of a fluke that isn't likely to get repeated.

I personally would not mind seeing one of two things.  One is to have high speed CPUs made so expensive that a bot that has it is going to be forced to overcome disadvantages across the board elsewhere.  The other is to let high speed CPUs be about as expensive as they are now, but to make them cost extra if you want to use interrupts also, which would have much the same effect.  I suspect it's probably an accurate statement to say that a 15 or 30 speed CPU (one or the other) with interrupts is probably worth about as much as a 50 speed with.  If we split the speed from the interrupt capability and priced it accordingly we might accomplish either one.

I also think that, in some ways, the game would probably benefit from being made just a little less simple environmentally.  At this point there's no barriers in the arena at all, which means that a number crunching bot can basically just immediately find their opponent and go kill them.  If there were a few obstacles that could either obstruct a bot's view or even endanger them, it might open the game up a bit more, and random potshots and hit-and-run tactics could be more effective.

Missiles and explosives should not do 2x damage.  The damage gap is so vast here that you effectively _have_ to have one of these two weapons to compete.  They should be put back at 1.5x.

My other thought is pretty simple:  put a hard cap on how far in the hole each bot is allowed to go on energy, based on what they have to start with, and if they go further negative than their maximum energy then the overload happens there instead of at -200 for every bot, i.e. a 40 energy overloads at -40, 60 at -60, 100 at -100, 150 at -150.  Between that and the lowered potency of missiles and explosive bullets, a bot can't skimp on energy or go completely nuts on movement with the idea that they'll always have the energy for that massive last shot anyway.  This does have the potential to make 150 energy the most important thing in the game, so maybe the overload limit should be scaled somehow in another way, or simply reduced to -100 or even -75.

I do think that the game, as it sits, is still largely played out.  I have fond memories of it but barring a major redesign I don't know what else there is for it.  I do enough game programming in my work that I haven't had the motivation to try coding bots any more as a result, and I haven't worked up the motivation to try to program a new version of the game either.  But I'd be interested in any discussions that arose.

E

-----Original Message-----
From: Mark Wagner
Sent: Nov 21, 2009 2:54 AM
To: robowar@yahoogroups.com
Subject: Re: [robowar] Hypothetical Rule Changes & Tournament

 

On Friday 20 November 2009 10:07:07 am james.gryphon wrote:
> Interrupts (1)
>
> The reason for putting a price on this fits largely in with the previous
> two. Another cause, though, for why I chose this is because all of these
> features have been added in, for free, with the passing of tournaments; new
> hardware had a price, but these features were simply taken for granted. The
> average bot became much more complex. This does put a price on those new
> features, but at the same time, rewards more advanced programmers, who are
> able to (in a system where people've long gone without the use of the
> hard-developed aiming mechanisms) take full advantage of their limited
> development space.

I think you're seriously underestimating the value of interrupts here. I've
written bots with and without interrupts, and I've looked at the performance
of other bots both with and without. I'd estimate that activating interrupts
is equivalent to a four-fold increase in CPU speed: a bot that polls
registers rather than setting up interrupts needs to make two reads (range
and radar) for every adjustment of the turret, plus a check for shield level
every chronon. A no-interrupts bot would need movement patterns carefully
designed to avoid periodic reads of the x and y registers, where an
interrupt-enabled bot can move freely.

> Negative Energy Allowed (1)
>
> This assumes that the default is No Negative Energy, and that the right of
> going into negative energy must be bought.
>
> This is the concept I feel the most strongly about; NNE is chronically
> underused, and we can see why. Negative energy allows for killshots, large
> move commands, and all sorts of things, even for bots with very limited
> energy tanks. With negative energy, even 40 energy is enough to produce a
> shot that'll kill any other bot in the arena.

You're missing the other major use of negative energy here: the "hesitator"
tactic. A hesitator periodically drops slightly into negative energy to
throw off tracking bots: doing so provides a free speed change. Done right,
the doppler register will alternate between full speed and 0, while the
actual speed is half or a third that, or even irregular.

Given the tactical value of these two options, I'd expect every bot except
maybe some of the miniature-class bots to take them: two hardware points will
give a speed-120 or speed-200 CPU, and a massive increase in survivability.
If I wanted to encourage alternatives, I'd value interrupts at 3 or 4
hardware points, and negative energy at 2.

The tournament idea looks interesting, and if I can find a RoboWar that works
on my computer, I'll have a few bots to enter.

--
Mark

It's a pleasure to finally make contact with you, Mr. Foley -- I've enjoyed
looking over your bots, and their accompanying stories, for a long time. I don't
suppose you still have Dark Lord, the drone version, lying around somewhere?
Nightshade's one of my favorites, and it'd be very cool to have a more dangerous
version of him.

I'm not picky over the exact price of processor speed, or interrupts. I'd be
more inclined to say, maybe, three points than four, for the latter, but it
isn't such a big deal to me, and I'm not very qualified to say anyhow. If you
think it's worth four, then I'm willing to agree with that as a going cost. I do
agree that, in retrospect, they're surely worth more than 1, considering all
their value (even when it just comes down to simplifying the coding process).

Negative Energy is probably worth more than 1, and as I've said, I'm not sure
that I wouldn't like to just get rid of it completely. Eric Foley's idea of
changing the negative energy to match the existing energy tank is something that
occurred to me a very short while ago, and I'd like to see it in action myself;
something like that would make negative energy viable again, or at least make it
worth just one point. As it is, raising it to 2 points sounds like a fair
proposal.

I don't know whether missiles or explosives should be 1.5x, but if you think
that that'd be a good change, then it's worth doing. The only problem with this,
and the negative energy proposal is that I can't work on either the Windows or
Macintosh version; I don't have the ability to compile anything, and so I can't
change it. The only stuff we have available to work with, from this perspective,
are hardware costs and bans. Of course, if Mr. Hertzberg chooses to return and
make some small changes, then that would take care of at least the Windows
crowd.

I suspect the changes to interrupts and doppler will make tacnukes, and maybe
mines, instantly more valuable, if maybe not by much -- just because, if the
designer can't come up with an accurate bot to save his life, maybe sheer chance
and extra coverage of the arena will give him the chance to do some damage.

Do you think doppler is really worth just one point?

As far as its potential in being played out, maybe RoboWar is like Checkers. For
all intent and purposes, the game has been solved; the computer can defeat
anyone who dares play it. There aren't going to be any new developments in
Checker strategy that'll change anything; the only way it's getting somewhere
new is if someone changes the rules.

Unlike Checkers, I don't think RoboWar has been solved, but it is probably true
that many, most, or perhaps even all possible effective paradigms have been
covered by now.

Even if that's so, though, it's the last generation that covered those
paradigms, not the current, or the next. The newer, younger people ought to have
their try at the game; for them, it's new, even if it's old hat and beaten for
others, and they deserve a chance to play at it, and see what they can devise.

At any rate, just let me know what y'all, with more experience than me (not that
that's hard), think, as far as these prices go, and I can let it be so.

Thanks for reading through this convoluted, poorly organized response; hope to
get more feedback from you soon.

~ James G.

The ruleset for the Legacy tournament is coming along very nicely, and I think I
have a workable release draft, but it's important to resolve the issue of
doppler cost.

Is it really worth only one point? Erika successfully used missiles in stead of
doppler (which it completely left out, for its targeting routines), but it's
very practical for most bots. While it is practical to write good aiming
routines for bots without doppler, as shown by Excelsior, most authors either
lack the time and coding space for them, or lack the skill necessary to come up
with such routines by themselves.

In the current draft of the ruleset, I have it priced at 2, the same as negative
energy and one point less than interrupts. While doppler changed a lot, is it
worth that much? Is it more on par with interrupts, and deserving of a cost
increase, or more like a probe-level increase, worthy of just a one-point cost?

Please let me know your thoughts on this.

- James G.