Interested in developing a standard for "robot" combat?

Those are some good suggestions for how to deal with hit points/damage. However, I think we may be jumping too far ahead in the design process. While it's good to keep these things in mind so that we don't restrict our design too much, I think there are a lot of basic issues that we can tackle immediately. Here's the list of basic issues I think we need to address first and some sample protocols for handling them:

1. Battle Invite/Accept Commands. This commands are used to announce a battle invitation and for bots to accept the challenge.
   1. Invite.
      This should be a shout message that is performed by an agent or a script. Specifies max # of bots that can accept the invitation. Can restrict the names of bots that can accept (to prevent uninvited bots form accepting). Can also specify rules & restrictions (no weapons, max weight, type of game, etc...). Example: "Battle_Invite myBattle,2,[bot1, bot2],[no_weapons, collect_balls]" for a new battle called myBattle with max 2 bots (bot1 and bot2), no weapons allowed, and the game is collect as many balls as you can.
      
   2. Accept. Simple... "I accept your challenge." This is a response generated by all bots that want to fight in this battle. Example: "Battle_Accept myBattle"
      
   
   
2. Reset Commands. These commands specifies that a new round is about to start in a battle.
   1. Reset. Specifies the target bot and the position it should move to. Example: "Battle_Reset myBattle,bot1,<10,10,30>"
      
   
   
3. Start/Stop Commands. These commands are used to start and stop a round.
   1. Start. Specifies an optional time limit. Example: "Battle_Start myBattle,60" for a 1-minute battle. A Stop command must still be issued after a minute. The time limit is meant for the bots so that they can plan their strategy accordingly.
      
   2. Stop. Species the end of a fight. If a time limit was specified by the Start command, the Stop command should coincide with that time. Example: "Battle_Stop myBattle"
      
   
   
4. Score Commands These commands are shouted to the bots so they can keep track of how many points they've scored so far, and to announce the final winner(s)
   1. Score. Specifies the name of the bot and its score. Example: "Battle_Score myBattle,bot1,89" Scores can be announced at any time by the host of the battle.
      
   
   
5. Penalty Commands These commands can be used to disable a bot when it violates a rule.
   1. Penalty. Specifies the bot and how much time in seconds it should wait before continuing. Also, an optional position can be specified if the bot has to move to a penalty location. Example: "Battle_Penalty myBattle,bot1,30,<20,20,10>"
      
   
   

Anyway, this wasn't meant to be a formal list, but I kind of wanted to get the ball rolling on some of the more basic protocol commands that we can all agree on. It would be great if we could set a milestone for the protocol definition that would allow a very simple fight to take place (doesn't have to involve weapons). I think it would be great for morale and for building excitement for the project.

Tip, every year MIT has a robot competition where real robots try to do simple things with ping pong balls (like collect as many as possible, etc...) The cool thing about the contest is that robots actually WERE allowed to interfere with each other. Some of the best designs were really simple robots that just collected a ball or two, and then just played defense for the rest of the game. Even without weapons, it was a VERY entertaining thing to see. And these robots were actually controlled by humans, so I think having automated bots would be even cooler.

If we made a bot toolkit with wheels/arms/motors and simple AI scripts that we gave away for free or for a small price, I think we could get more people to participate.

Trouble is wherever you look on the net there is another interesting contest I'd like to have a go at. I keep looking at the vehicle sims and thinking DARPA and their Grand Challenge race ( http://www.grandchallenge.org/). Wonder if the Foundation for Rich content would sponsor an SL version.
(hmm, DARPA: Defense Advanced Research Projects Agency. SLARPA: Second Lfe Autonomous Robot Projects Association?)

Anyway, back on topic, I think your right in not restricting things to combat, there would be a variety of functions and standards that would be the same whatever the theme of the contest.

OK, In my next post I'll put up a proposal as to how we can formally agree and document the standard. Its a method I've used before based on the game Nomic (Dont worry, my version is very simple)

Section 1
'I1.' This document is called The Open Source Robot Contest System.

'I2.' This document has two sections:
		Section 1:  This section contains this introduction and the rules by which this document can be changed.
		Section 2:  This section contains information on the Open Source Robot Contest System, the standard itself

'R1' This document can only only be changed as described in these rules

'R2'  The Administrator is responsible for maintaining this document, and regularly posting it to the Forum. The Administrator is Tip Baker.

'R3'  All contributors must abide by all rules. The author of each message replying to this post is considered a contributor, unless they state that they do not wish to be.

'R4.' Any contributor may propose a change to this document by posting a reply to this post describing the change to be made. Contributors responding to a message containing a proposal are entitled to one vote each on it, until five votes have been cast on the proposal. At that point, if there are more votes in favor than against, the change is made by the Administrator; otherwise the message loses its proposal status. No contributor is entitled to more than one vote on any proposal.

Section 2
<This space intentionally left blank>

So WTF is that? Its a document header. It does nothing but describe how to change the document itself. Our task is to fill in section 2 using the rules in section 1.

R4 is the main rule. It says that to change the standard, make a suggestion. Anyone can vote on it. After 5 votes I count up and if there are more yes's than no's your suggestion goes in.


I'll leave you all to mull that over and come back with any questions. If everyone's happy with the idea as a way forward, we can give it a go.

Excellent! My only question is whether proposals can be made to change the rules in Section I if the need ever arises. Also, what happens in the case when a long period of time goes by and there still aren't enough voters?

Otherwise, I like it! I'd like to put in a vote for "Yes, let's move forward with this."

Yes, the rules allow changes to the rules


As the rules stand, its a problem. If that happens, we can just agree to tweak the rules. To start with I suggest we leave them as they are, but accept or dismiss a proposal as soon as there are a majority of votes cast. That way you only need three yes votes to move forward with the things that everyone agree's with.



Good stuff.

Later on I'll put up an example proposal or two to start to flesh things out. We need to get some headings in for instance.

The trick to these is to do things in small bites and get the basic concepts agreed first.

OK,

Lets see if we can agree on what we mean by a robot

I proposal that the line in section 2 that says

<This space intentionally left blank>

Is replaced with:
2.1 Introduction

2.1.1 This document provides a standard to allow players to create autonomous robots, in whatever form, which can then compete against other player's creations.

2.1.2 A Robot that meets the requirements defined in this document is said to be Compliant

2.1.3 A Compliant Robot must:
Be constructed within the limits dictated by Second Life's physics engine. EG no more than 32 linked prims.
Be capable of operating autonomously, that is, without player control or input during the contest.
Receive, react to and transmit the various standard messages as appropriate


I vote yes to proposal TP001

It is possible for crafts to fly with over 31 prims and non-physical movement is becoming more and more smooth. I think standardizing rules for how robots should interact is fine as long as it does not hinder the forward thinking and creations of others.

As I know that there are some quite amazing new robots being built along the lines you are looking for, I think I would have to wonder as to the essential need for a proposal?

Calix,

I think the proposal serves two purposes:

1. To define a set of rules that makes a robot battle "fair". That way when a 5 prim, physics bot is battling a 63 prim physics-disabled bot, and it hits a bump and falls over, it won't get its ass kicked.
2. Define a messaging protocol so that anyone that writes a compliant bot will be able to participate automonously in the battle.

Having said that, I'd like to make a small change to TP001 that addresses Calix's concerns about limiting forward thinking (changes in bold):

----------

2.1 Introduction

2.1.1 This document provides a standard to allow players to create autonomous robots, in whatever form, which can then compete against other player's creations.

2.1.2 A Robot that meets the requirements defined in this document is said to be Compliant

2.1.3 A Compliant Robot must meet the requirements of one of the following classes:

2.1.3.a Class A

Class A robots must be constructed within the limits dictated by Second Life's physics engine. EG no more than 32 linked prims. They must be capable of operating autonomously, that is, without player control or input during the contest. They must be able to receive, react to and transmit the various standard messages defined in section 2.2(?).

-------
This is proposal VP001. This will allow us to add more classes down the road (higher prim-count bots, no physics, non-automonous, etc...).

So, I vote no on TP001, and yes on VP001.

Calix,

OK, as the rules stand, thats a no to the whole proposal. But thats not a problem, demonstrates the need to keep your proposals short.

I've got no objection to allowing non physics based in, but I do think a robot must , in part, be defined as being a single linked object. If its two objects, isnt it two robots?

If the proposal is passed, you can then propose that 2.1.3 is changed and I'll vote for it.
If it isnt passed, then whatever replaces it will have to not mention physics to get your vote.

So thats one vote for and one against.

Hi Vince,

Nice suggestion. I'll vote for it. But call it VP001, so we can see who made each proposal.

Done!

Hmmm,

Lots of readers, but no contributors.

Vince, What do you want to do, soldier on or call this one a dead horse?

How can you tell if a design is allowed and not loaded with scripts to cheat the system? How about the size of these things? Like an AV with custom robot armor compaired to a 'Mech, compaired to Super Dimensional Fortress Macross with shoulder-mounted fleet destroyers?

- Jolan

You could use a trusted third party such as a notray if you were worried about that.

How about the size of these things? Like an AV with custom robot armor compaired to a 'Mech, compaired to Super Dimensional Fortress Macross with shoulder-mounted fleet destroyers?

- Jolan[/QUOTE]
In terms of what? In terms of 'hit points' that could be covered by using the mass. Remember we are not talking just combat.

Tip,

I wouldn't mind shelving this for a while... I'm kind of tight on free time myself right now.

Tip, Vince,

I'm only on day two in SL, but after running into a few robot shops and having a fairly successfull hobby in robot scripting with another game that I'll mention later, I'm interested in reviving this endeavor. But I must say now, that my intentions are to make a business out of it for L$ profit.

I have ideas, and best of all, I have scriptors that may very likely be interested.

I think a team of 5 scriptors, including you two, me and two other scriptors, I think we can build our own combat robot business.

I'll need to mull over the LSL, but it won't take long for me to pick it up. It's just another language to me. From what I've read already, LSL isn't too difficult.

I own a small piece of land 512sqm that I was going to use to build and sell elevator models, and I still may do just that, but we can also use it for what I have in mind.

Tell me this isn't dead, and I'm in...